Hbase 集群的常见维护问题 - Iawen's Blog - 我喜欢这样自由的随手涂鸦, 因为我喜欢风......

首页 > 数据库 Hbase 集群的常见维护问题 2024-04-28 17:13:42

1. Hadoop 常见问题

1.1 Got too many exceptions to achieve quorum 异常解决办法

1、首先需要备份namenode元数据和journalnode元数据
2、在namenode节点执行

hdfs namenode -initializeSharedEdits
# 中间会提示是否格式journalnode 回复 Y

Re-format filesystem in QJM to [10.1.5.102:8485, 10.1.5.103:8485, 10.1.5.104:8485] ? (Y or N) y

3、重启hadoop集群问题解决。

1.2 报错There appears to be a gap in the edit log. We expected txid 6, but got txid xxxx.

原因: namenode元数据被破坏, 需要修复
解决: 恢复一下namenode

/usr/local/hadoop-3.1.3/bin/hdfs namenode -recover
# 一路选择c 进行元数据的恢复.这是重点
# 重新启动。到这里问题真正的结束了, 好舒服。

网上有一种解决方法, 说是把active namenode上的name文件夹拷贝到standby namenode上。我试了, 而且拷贝过来的name目录中也有176531929这条Edits数据, 但启动namenode时还是报同样的错, 说找不到176531929这条edit数据。说明这个方法不可行！因为Edits是要在启动时去journalnode上读取的。这个问题的根本原因是你的journalnode上存在Edits数据丢失的情况。这一句看懂就基本上找到原因了, 也有方向了, 在HA的解读中就有说明,

所以我去查看我的journalnode目录, 果然发现journalnode/yarncluster/current下面没有176531929这一条Edits数据。所以, 这就是这个错误出现的根本原因。然后解决办法很简单, 从active namenode上拷贝这条Edits数据到所有journalnode中。重新启动, 问题解决, 没有数据丢失, 也不需要recovery。

hdfs dfsadmin -safemode leave

1.3 查看损坏文件、当前hdfs的副本数

hdfs fsck /     # 或者
hadoop fsck -locations

# Under replicated blocks　 　　   副本数少于指定副本数的block数量
# Blocks with corrupt replicas　　 存在损坏副本的block的数据
# Missing blocks　　　　　　　　    丢失block数量

1.4 更改已经上传文件的副本数, 修复Missing blocks

hadoop fs -setrep -R 3 /
# 通过该命令, 对于存在副本缺失问题(Under replicated blocks)的662个block, 可以从剩下的1-2个副本, 重新生成3个副本, 从而找回了丢失的副本。

1.5 删除损坏文件

hdfs fsck -delete
# 通过多次运行该命令, 对于副本全部丢失(Missing blocks)或损坏的block, 可以从namenode节点删除元信息和损坏文件。

2. Hbase 常见问题

2.1 查看hbase中损坏的block

hbase hbck

2.2 修复hbase

# 关闭balance,防止在停掉服务后, 原先节点上的分片会迁移到其他节点上, 到时候在移回来, 浪费时间。
hbase(main):001:0> balance_switch false
hbase hbck -repair
hbase(main):001:0> balance_switch true

2.3 其他修复

# .META表
hbase hbck -fixMeta

# 当出现漏洞
hbase hbck -fixHdfsHoles

# 缺少regioninfo
hbase hbck -fixHdfsOrphans

# hbase region 引用文件出错
# Found lingering reference file hdfs: 
hbase hbck -fixReferenceFiles

# 修复assignments问题
hbase hbck -fixAssignments

# 手动移动table region
move 'bee0c225ec0c69ecc5872dfe67cec5f0', 'xiaoma05,16020,1607668276810'

# 手动拆分table region
split '5a3af2b7bcffdc93a1433bd80fe1ce04', '42'
split 'aaab390dd96dc8a6cfaf7b045d925738', 'a2'

region自动拆分默认选择Region当中最大Store下的最大Storefile文件中的midkey, 而midkey其实只是在通过HFile获取了这个文件之前记录好的数据。在自动触发Split操作的前提下, 大部分的Split操作都伴随在Compaction操作之后进行的原因, 在于可以对于Region中的文件进行合并, 生成较大的StoreFile文件, 以方便选择更好的SplitPoint。

2.4 Hbase的region合并与拆分

2.4.1 region 拆分机制

region中存储的是大量的rowkey数据 ,当region中的数据条数过多的时候,直接影响查询效率.当region过大的时候.hbase会拆分region , 这也是Hbase的一个优点 .
HBase的region split策略一共有以下几种:

1、ConstantSizeRegionSplitPolicy (0.94版本前默认切分策略)
当region大小大于某个阈值(hbase.hregion.max.filesize=10G)之后就会触发切分, 一个region等分为2个region。
但是在生产线上这种切分策略却有相当大的弊端: 切分策略对于大表和小表没有明显的区分。阈值(hbase.hregion.max.filesize)设置较大对大表比较友好, 但是小表就有可能不会触发分裂, 极端情况下可能就1个, 这对业务来说并不是什么好事。如果设置较小则对小表友好, 但一个大表就会在整个集群产生大量的region, 这对于集群的管理、资源使用、failover来说都不是一件好事。
2、IncreasingToUpperBoundRegionSplitPolicy (0.94版本~2.0版本默认切分策略)
切分策略稍微有点复杂, 总体看和ConstantSizeRegionSplitPolicy思路相同, 一个region大小大于设置阈值就会触发切分。但是这个阈值并不像ConstantSizeRegionSplitPolicy是一个固定的值, 而是会在一定条件下不断调整, 调整规则和region所属表在当前regionserver上的region个数有关系.
region split的计算公式是: regioncount^3 * 128M * 2, 当region达到该size的时候进行split 例如: 第一次split: 1^3 * 256 = 256MB 第二次split: 2^3 * 256 = 2048MB 第三次split: 3^3 * 256 = 6912MB 第四次split: 4^3 * 256 = 16384MB > 10GB, 因此取较小的值10GB 后面每次split的size都是10GB了
3、SteppingSplitPolicy (2.0版本默认切分策略)
这种切分策略的切分阈值又发生了变化, 相比 IncreasingToUpperBoundRegionSplitPolicy 简单了一些, 依然和待分裂region所属表在当前regionserver上的region个数有关系, 如果region个数等于1, 切分阈值为flush size * 2, 否则为MaxRegionFileSize。这种切分策略对于大集群中的大表、小表会比 IncreasingToUpperBoundRegionSplitPolicy 更加友好, 小表不会再产生大量的小region, 而是适可而止。
4、KeyPrefixRegionSplitPolicy
根据rowKey的前缀对数据进行分组, 这里是指定rowKey的前多少位作为前缀, 比如rowKey都是16位的, 指定前5位是前缀, 那么前5位相同的rowKey在进行region split的时候会分到相同的region中。
5、DelimitedKeyPrefixRegionSplitPolicy
保证相同前缀的数据在同一个region中, 例如rowKey的格式为: userid_eventtype_eventid, 指定的delimiter为 _ , 则split的的时候会确保userid相同的数据在同一个region中。
6、DisabledRegionSplitPolicy: 不启用自动拆分, 需要指定手动拆分

2.4.2 region合并机制

1.1 region合并说明
Region的合并不是为了性能, 而是出于维护的目的 .
比如删除了大量的数据 ,这个时候每个Region都变得很小 ,存储多个Region就浪费了 ,这个时候可以把Region合并起来, 进而可以减少一些Region服务器节点
1.2 如何进行region合并
1.2.1 通过Merge类冷合并Region

# 执行合并前, ==需要先关闭hbase集群==
hbase org.apache.hadoop.hbase.util.Merge test test,,1565940912661.62d28d7d20f18debd2e7dac093bc09d8. test,1000,1565940912661.5b6f9e8dad3880bcc825826d12e81436.

1.2.2 通过online_merge热合并Region

# ==不需要关闭hbase集群==, 在线进行合并
# 与冷合并不同的是, online_merge的传参是Region的hash值, 而Region的hash值就是Region名称的最后那段在两个.之间的字符串部分。
# 需要进入hbase shell: 
ruby merge_region 'c2212a3956b814a6f0d57a90983a8515','553dd4db667814cf2f050561167ca030'

2.5 hbase snapshot 和数据迁移

2.5.1 创建hbase snapshot

hbase(main):002:0> create_namespace "test"
hbase(main):004:0> create 'test:snapshot', {NAME=>'CF1',BLOCKCACHE=>'false',BLOOMFILTER=>'ROW'}
hbase(main):006:0> put 'test:snapshot', '123', 'CF1', 'value 01'
hbase(main):007:0> put 'test:snapshot', '256', 'CF1', 'value 01'
hbase(main):008:0> put 'test:snapshot', '345', 'CF1', 'value 01'
hbase(main):009:0> put 'test:snapshot', '348', 'CF1', 'value 02'
hbase(main):010:0> scan 'test:snapshot'
ROW                                             COLUMN+CELL
 123                                            column=CF1:, timestamp=1609396656263, value=value 01
 256                                            column=CF1:, timestamp=1609396664602, value=value 01
 345                                            column=CF1:, timestamp=1609396669585, value=value 01
 348                                            column=CF1:, timestamp=1609396677496, value=value 02
4 row(s)
Took 0.0420 seconds
hbase(main):011:0> snapshot 'test:snapshot', 'test_snapshot_count4'
hbase(main):012:0> put 'test:snapshot', '348', 'CF1', 'update 348 value this'
hbase(main):013:0> scan 'test:snapshot'
ROW                                             COLUMN+CELL
 123                                            column=CF1:, timestamp=1609396656263, value=value 01
 256                                            column=CF1:, timestamp=1609396664602, value=value 01
 345                                            column=CF1:, timestamp=1609396669585, value=value 01
 348                                            column=CF1:, timestamp=1609396759008, value=update 348 value this

hbase(main):014:0> disable 'test:snapshot'
hbase(main):015:0> restore_snapshot 'test_snapshot_count4'
hbase(main):016:0> enable 'test:snapshot'
hbase(main):017:0> scan 'test:snapshot'
ROW                                             COLUMN+CELL
 123                                            column=CF1:, timestamp=1609396656263, value=value 01
 256                                            column=CF1:, timestamp=1609396664602, value=value 01
 345                                            column=CF1:, timestamp=1609396669585, value=value 01
 348                                            column=CF1:, timestamp=1609396677496, value=value 02

2.5.2 数据迁移

在上面创建好快照后, 使用ExportSnapshot命令进行数据迁移, ExportSnapshot也是HDFS层的操作, 本质还是利用MR进行迁移,
这个过程主要涉及IO操作并消耗网络带宽, 在迁移时要指定下map数和带宽, 不然容易造成机房其它业务问题,
如果是单独的MR集群, 可以在MR集群上使用如下命令:

hbase org.apache.hadoop.hbase.snapshot.ExportSnapshot \
-snapshot SNAPSHOT_ZAT_TRACE_20200904093200 \
-copy-from hdfs://172.16.120.199:9000/hbase \
-copy-to hdfs://172.16.120.213:9000/hbase \
-mappers 16 -bandwidth 1024

# 根据快照恢复出一个新表, 恢复过程不涉及数据移动, 可以在秒级完成。
hbase> clone_snapshot 'SNAPSHOT_ZAT_TRACE_20200904093200','ZAT_TRACE_NEW'

2.5.3 验证数据

# 通过HBase自带的VerifyReplication工具, 验证两个集群的数据是否一致: 
hbase org.apache.hadoop.hbase.mapreduce.replication.VerifyReplication -mappers 10 -bandwidth 1024 1 ZAT_TRACE

参考: https://www.cnblogs.com/caoweixiong/p/13607657.html

2.6 Thrift server 参数选择

TServer的选择。这是Thrift框架server端处理模型的选择。有三种, TNonblockingServer, THsHaServer, TThreadPoolServer。可以通过启动命令参数指定, 具体运行./bin/hbase thrift可以看到命令帮助(or ./bin/hbase thrift2)。默认是用TThreadPoolServer, 建议就不用改了, 除非你特别了解你的场景。

hbase.regionserver.thrift.compact 是否使用Thrift TCompactProtocol, 默认false。如果你每列数据比较大, 可以试着开启, 减少带宽。
hbase.thrift.connection.cleanup-interval server清理与HBase连接的周期, 与HBase的是一个长连接, 默认10秒
hbase.thrift.connection.max-idletime 如果与HBase的长连接超过这个时间没有被使用, 则会被清理, 默认10分钟
hbase.thrift.minWorkerThreads TThreadPoolServer的线程池中的corePoolSize, 也就是即便空闲时候保持的线程数, 默认16。
hbase.thrift.maxWorkerThreads TThreadPoolServer的线程池中的maximumPoolSize, 默认1000。这个会影响server最大处理能力, 需要根据硬件衡量。
hbase.thrift.maxQueuedRequests TThreadPoolServer的线程池队列长度上限, 超过这个值时会去创建一个新的线程处理请求(前提是没有达到maxWorkerThreads, 否则拒绝请求)

注: 上述最后三个值对thrift2无效。1.3之前的版本中, thrift2无法设定这些值。2.0版本中在thrift2启动命令里通过指定’w’选项来设置maxWorkerThreads。具体可以运行上文中提到的命令, 查看是否支持’w’选项, 如果不支持, 默认max=int最大值。

3. Hadoop元数据备份与恢复方案

3.1 Namenode

周期性备份namenode、standby namenode的dfs.namenode.name.dir
因为主从切换可能导致edits log分散在两台机器上, 需要两台机器共同提供完整的edits log
恢复步骤:

1,删除journalnode数据文件, 启动服务(所有jn均执行)
2,登陆namenode
3,下载最新的备份文件
4,解压, 移至dfs.namenode.name.dir
5,执行hdfs namenode –initializeSharedEdits(hdfs namenode -initializeSharedEdits will initialize the shared edits directory with the edits data from the local NameNode edits directories)
6,启动zkfc
7,启动namenode
8,登陆standby namenode
9,执行hdfs namenode -bootstrapStandby(The bootstrapStandby command will download the most recent fsimage from the active NameNode into the $dfs.name.dir directory of the standby NameNode.)
10,启动zkfc
11,启动namenode

适用场景:
namenode、standby namenode全部故障
如果只是一台namenode故障, 可以清空name文件夹, 执行hdfs namenode -bootstrapStandby

3.2 Journalnode

恢复方法:
从正常的jn节点拷贝数据, 启动, 即可。
无需停止正常节点再拷贝, 直接拷贝即可。这样拷贝会有部分缺失数据, 故障节点启动后, 不会补齐这些缺失数据, 但不影响新数据的写入。对于缺失的edits, 只要有一台机器上有, namenode就可以启动。

适用场景:
单个节点故障

3.3 Zookeeper

周期性备份

<dataDir>/version-2/acceptedEpoch
<dataDir>/version-2/currentEpoch
<dataDir>/version-2/snapshot.
<dataLogDir>/version-2/log.

其中snapshot、log备份最近的几份就行
恢复步骤:

1,登陆一台zookeeper服务器
2,下载最新的备份文件
3,解压, 将data、datalog移至< dataDir>, 并创建data/myid文件(与配置文件一致)
4,启动服务(其余节点配置data/myid文件, 启动即可)

适用场景:
部分或全部数据丢失
如果只是单个节点故障, 清空故障节点的data、datalog文件夹, 启动后会自动从正常节点复制数据, 无需人工恢复

http://hbasefly.com/2016/06/18/hbase-practise-ram/
https://blog.csdn.net/ddxygq/article/details/86418081

3.4 内存配置

目前hbase内存主要如下几个配置项:
1)HBASE_HEAPSIZE HBase RegionServer是内存贪婪性的, 按照经验判断至少8~16G内存, 但也不宜过大, 更多内存应该分配给HBASE_OFFHEAPSIZE
2)HBASE_OFFHEAPSIZE Hbase offheap内存为非堆内存, 主要在hbase缓存数据时使用, 需要配合如下配置项使用,其中hbase.bucketcache.size的配置经验值为: HBASE_OFFHEAPSIZE10240.8 MB

<property>
    <name>hbase.bucketcache.ioengine</name>
    <value>offheap</value>
</property>
<property>
    <name>hbase.bucketcache.size</name>
    <value>HBASE_OFFHEAPSIZE*1024*0.8</value>
</property>

4. Phoenix

phoenix是一个客户端的库, 它在HBase基础上提供SQL功能层, 让我们可以使用标准的JDBC接口操作HBase。
全部支持的特性可以浏览官方最新版本支持的SQL语法, 下面列举一些phoenix 4.6版本不支持的特性及与普通MySQL SQL用法有差异的地方:

CHAR类型只能保存单字节的字符, 不能保存中文字符, 中文需要使用VARCHAR。
非主键字段不能指定为NOT NULL, 不支持指定字段默认值(4.9版本以上支持)。
UPDATE table SET col=val WHERE: 不支持该语法, phoenix更新和插入使用同样的UPSERT INTO语法, 如果主键存在则更新, 不存在则插入。但可以使用UPSERT INTO table SELECT语句来实现条件更新, 需要把主键按条件选出来, 如:

UPSERT INTO table(id, col1) SELECT id, 'val1' FROM table WHERE col2 = val2

DATE/TIME字段类型: 这两个字段类型对应java.sql.Date类型, 其JDBC驱动不会对java.util.Date类型进行转换, 所以在PreparedStatement中setObject(int, java.util.Date)会报下面的错误。如果使用jfinal ActiveRecord保存实体, 当实体字段是java.util.Date类型时要注意。
java.util.Date cannot be cast to org.apache.phoenix.schema.types.PhoenixArray
LIMIT OFFSET分页: phoenix 4.6不支持使用OFFSET分页, 在4.8以上版本才支持。
ALTER不支持改变表名、字段名与字段类型, 只能增加与删除字段。在设计的时候要注意使用合适的字段类型。
大小写: phoenix默认不区分大小写, 所有表名、列名都是大写。
不支持的函数: IFNULL, ISNULL等; IFNULL有对等的COALESCE()函数
连接池: phoenix不推荐使用连接池, 因为其基于HBase的连接的创建成本很低, 并且用过的HBase连接不能共享使用, 因此用过的Connection需要关闭。
Phoenix’s Connection objects are different from most other JDBC Connections due to the underlying HBase connection. The Phoenix Connection object is designed to be a thin object that is inexpensive to create. If Phoenix Connections are reused, it is possible that the underlying HBase connection is not always left in a healthy state by the previous user. It is better to create new Phoenix Connections to ensure that you avoid any potential issues.
JDBC Connection: AutoCommit默认为false, 其他JDBC Driver一般默认是true, 需要手动条用connnection.commit()或者在连接url后面加上";autocommit=true"
索引使用: 使用CREATE INDEX idx创建的是全局索引(GLOBAL INDEX), 还有一种本地索引(LOCAL INDEX), 相对于本地索引, 全局索引可以让读的性能更佳, 但写入的时候成本会高一点; 而本地索引在写入的时候成本较低, 但读的时候成本较高。使用全局索引的时候, 如果SELECT字段含有非索引的字段, 则索引不会被使用, 大多数情况下我们SELECT都会有索引之外的字段, 这时候需要考虑建立覆盖索引(CREATE INDEX INCLUDING …)或使用hint来让phoenix使用索引: SELECT /*+ INDEX(table idx) */ col FROM table WHERE …。
PreparedStatement不支持Statement.RETURN_GENERATED_KEYS, getGeneratedKeys()。
日期类型保存为UTC时间, 在shell/squirrel查询的时候要用CONVERT_TZ做转换, CONVERT_TZ(col, ‘UTC’, ‘Asia/Shanghai’), 但有个bug, 如果col字段是timestamp的话, 会报Type mismatch. expected: [DATE]。实在需要转换的话先转成Date类型: CONVERT_TZ(TO_DATE(TO_CHAR(col,‘yyyy-MM-dd HH:mm:ss’),‘yyyy-MM-dd HH:mm:ss’),‘UTC’,‘Asia/Shanghai’)

4.1 安装phoenix

安装 python2.7: apt-get install python2.7
下载phoenix
复制 phoenix 目录下的 phoenix-5.0.0-HBase-2.0-server.jar, phoenix-5.0.0-HBase-2.0-client.jar, phoenix-core-5.0.0-HBase-2.0.jar 到hbase的lib目录下

4.2 配置 phoenix

修改 hbase-site.xml (hbase用2.0.5)

<property>
    <name>hbase.regionserver.wal.codec</name>
    <value>org.apache.hadoop.hbase.regionserver.wal.IndexedWALEditCodec</value>
    <description>支持可变索引</description>
</property>

<property>
    <name>phoenix.transactions.enabled</name>
    <value>true</value>
</property>
<property>
    <name>data.tx.snapshot.dir</name>
    <value>/tmp/tephra/snapshots</value>
</property>

<!-- Phoenix4.8以上版本需要配置在Region Server配置hbase-site.xml, 不用再配置Master的hbase-site.xml。配置如下 -->
<property>
    <name>hbase.regionserver.wal.codec</name>
    <value>org.apache.hadoop.hbase.regionserver.wal.IndexedWALEditCodec</value>
</property>
<property>
    <name>hbase.region.server.rpc.scheduler.factory.class</name>
    <value>org.apache.hadoop.hbase.ipc.PhoenixRpcSchedulerFactory</value>
    <description>Factory to create the Phoenix RPC Scheduler that uses separate queues for index and metadata updates</description>
</property>
<property>
    <name>hbase.rpc.controllerfactory.class</name>
    <value>org.apache.hadoop.hbase.ipc.controller.ServerRpcControllerFactory</value>
    <description>Factory to create the Phoenix RPC Scheduler that uses separate queues for index and metadata updates</description>
</property>

复制 hbase-site.xml 到 phoenix/bin 目录下
复制 hadoop目录下的core-site.xml hdfs-site.xml到 phoenix/bin 目录下
补丁 hbase-common-2.0.5.jar

for i in `seq 2 5`; do \
    scp phoenix-5.0.0-HBase-2.0-server.jar phoenix-5.0.0-HBase-2.0-client.jar phoenix-core-5.0.0-HBase-2.0.jar hbase-common-2.0.5.jar xiaoma0$i:/usr/local/hbase-2.0.5/lib/; \
done

for i in `seq 2 5`; do scp hbase-site.xml xiaoma0$i:/usr/local/hbase-2.0.5/conf/; done

4.3 Go 客户端

Go 依赖 https://calcite.apache.org/avatica/docs/go_client_reference.html

4.4 启动 phoenix

export PHOENIX_HOME=/usr/local/phoenix
# 测试运行
$PHOENIX_HOME/bin/sqlline.py xiaoma01,xiaoma02,xiaoma03:2181

# 查询服务
$PHOENIX_HOME/bin/queryserver.py start|stop

4.5 二级索引和oracle 的索引不一样。

SELECT v2 FROM my_table WHERE v1 = 'foo'
-- 这样查询, 要用上索引, 需要v1, v2一起建索引。如果查询结果中字段有多的, 将用不上索引。查询结果是rowkey的话, 可以不要INCLUDE。
CREATE INDEX my_index ON my_table (v1) INCLUDE (v2)

4.6 一些针对phoenix的优化措施

由于phoenix本质上在HBase读写数据, 所以HBase集群的性能影响是最大的, 一般使用多节点(一般hadoop集群节点要大于等于5个)、SSD、更大的内存与缓存和对phoenix/hbase/hadoop配置参数进行调优能获得更大性能的提升。

主键: 主键对应HBase的row key, HBase会把相近的row key放到相同的region里, 如果选择的主键是单调递增的, 那么某个region就会变成热点, 写入的性能会变差, 这种情况需要在建表的使用SALT_BUCKETS=N来自动对数据分片。
优化读: 使用全局索引, 这会对写入的速度有一定影响。查询时注意使用exlain来看执行计划是否使用了索引。
优化写: 使用本地索引, 建表时预先指定好分区方案(pre-split)。
数据是否可变: 如果数据只是写入, 以后不会变更, 可以在建表的时候指定IMMUTABLE_ROWS=true, 这样可以提高写入的性能。
适当使用查询hint来优化执行计划: 用explain查看执行计划, 用hint来优化。支持的语法见hinting。

4.7 异步创建索引

一般我们可以使用CREATE INDEX来创建一个索引, 这是一种同步的方法。但是有时候我们创建索引的表非常大, 我们需要等很长时间。Phoenix 4.5以后有一个异步创建索引的方式, 使用关键字ASYNC来创建索引:

CREATE INDEX index1_c ON hao1 (age) INCLUDE(name) ASYNC;

这时候创建的索引表中不会有数据。你还必须要单独的使用命令行工具来执行数据的创建。当语句给执行的时候, 后端会启动一个map reduce任务, 只有等到这个任务结束, 数据都被生成在索引表中后, 这个索引才能被使用。启动工具的方法:

${HBASE_HOME}/bin/hbase org.apache.phoenix.mapreduce.index.IndexTool --schema MY_SCHEMA --data-table MY_TABLE --index-table ASYNC_IDX
# 这个任务不会因为客户端给关闭而结束, 是在后台运行。你可以在指定的文件ASYNC_IDX_HFILES中找到最终实行的结果。

5. 其他

5.1 对于数据库应用, 不推荐使用透明大页

cat /sys/kernel/mm/transparent_hugepage/enabled
# 如果返回 [always] madvise never 则表示处于启用状态
# 如果输出 always madvise [never] 表示透明大页处于禁用状态。

# 如果不希望重启机器, 也可以修改当前的内核配置来立即生效
echo never > /sys/kernel/mm/transparent_hugepage/enabled
echo never > /sys/kernel/mm/transparent_hugepage/defrag

5.2 常见错误提示

regionserver.HRegionServer: Failed construction RegionServer
hbase Master not initialized after 200000 ms
master.HMasterCommandLine: Master exiting

Iawen's Blog

我喜欢这样自由的随手涂鸦, 因为我喜欢风......

笔记导航

最新笔记