Hbase运维手册.docx

Hbase运维手册.docx

《Hbase运维手册.docx》由会员分享，可在线阅读，更多相关《Hbase运维手册.docx（14页珍藏版）》请在冰豆网上搜索。

Hbase运维手册

Hbase运维手册

D

注意，其中InMemory队列用于保存HBaseMeta表元数据信息，因此如果将数据量很大的用户表设置为InMemory的话，可能会导致Meta表缓存失效，进而对整个集群的性能产生影响。

3. 读写请求数

通过读写请求数可以大概看出每台regionServer的压力，如果压力分布不均匀，应该检查regionServer上的region以及其它指标

4. 压缩队列

压缩队列存放的是正在压缩的storefile，compact操作对hbase的读写影响较大

通过cdh的hbase图表库可以看到集群总的压缩队列大小：

可以通过CDH的hbase主页查询compact日志：

点击“压缩”进入：

5. 刷新队列

单个region的memstore写满（128M）或regionServer上所有region的memstore大小总合达到门限时会进行flush操作,flush操作会产生新的storeFile

同样可以通过CDH的hbase前台查看flush日志：

6. rpc调用队列

没有及时处理的rpc操作会放入rpc操作队列，从rpc队列可以看出服务器处理请求的情况

7. 文件块保存在本地的百分比

datanode和regionserver一般都部署在同一台机器上，所以regionserver管理的region会优先存储在本地，以节省网络开销。

如果blocklocality较低有可能是刚做过balance或刚重启，经过compact之后region的数据都会写到当前机器的datanode，blocklocality也会慢慢达到接近100：

8. 内存使用情况

内存使用情况,主要可以看usedHeap和memstore的大小，如果usedHeadp一直超过80-85%以上是比较危险的

memstore很小或很大也不正常

从regionServer的前台可以看到：

9.  检查数据一致性以及修复方法

数据一致性是指：

1.     每个region都被正确的分配到一台regionserver上，并且region的位置信息及状态都是正确的。

2.     每个table都是完整的，每一个可能的rowkey 都可以对应到唯一的一个region

hbasehbck

注：

有时集群正在启动或region正在做split操作，会造成数据不一致

hbasehbck-details

加上–details会列出更详细的检查信息，包括所以正在进行的split任务

hbasehbckTable1Table2

如果只想检查指定的表，可以在命令后面加上表名，这样可以节省操作时间

CDH

通过CDH提供的检查报告也可以看到hbck的结果，日常只需要看CDHhbck的报告即可：

    选择“最近的Hbck结果”：

  1） 局部的修复

  如果出现数据不一致，修复时要最大限度的降低可能出现的风险，使用以下命令对region进行修复风险较低：

           hbasehbck-fixAssignments

               修复region没有分配（unassigned），错误分配（incorrectlyassigned）以及多次分配（multiplyassigned）的问题

   hbasehbck-fixMeta

               删除META表里有记录但HDFS里没有数据记录的region

添加HDFS里有数据但是META表里没有记录的region到META表

   hbasehbck-repairHoles

等价于：

hbasehbck-fixAssignments-fixMeta-fixHdfsHoles

-

fixHdfsHoles的作用：

        如果rowkey出现空洞，即相邻的两个region的rowkey不连续，则使用这个参数会在HDFS里面创建一个新的region。

创建新的region之后要使用-fixMeta和-fixAssignments参数来使用挂载这个region，所以一般和前两个参数一起使用

  2） Region重叠修复

  进行以下操作非常危险，因为这些操作会修改文件系统，需要谨慎操作！

  进行以下操作前先使用hbck–details查看详细问题，如果需要进行修复先停掉应用，如果执行以下命令时同时有数据操作可能会造成不可期的异常。

        hbasehbck-fixHdfsOrphans

     将文件系统中的没有metadata文件（.regioninfo）的region目录加入到hbase中，即创建.regioninfo目录并将region分配到regionser

       hbasehbck-fixHdfsOverlaps

     通过两种方式可以将rowkey有重叠的region合并：

       1.merge:

将重叠的region合并成一个大的region

       2.sideline:

将region重叠的部分去掉，并将重叠的数据先写入到临时文件，然后再导入进来。

    如果重叠的数据很大，直接合并成一个大的region会产生大量的split和compact操作，可以通过以下参数控制region过大：

       -maxMerge合并重叠region的最大数量

      -sidelineBigOverlaps假如有大于maxMerge个数的 region重叠, 则采用sideline方式处理与其它region的重叠.

      -maxOverlapsToSideline如果用sideline方式处理重叠region,最多sidelinen个region.

     hbasehbck-repair

以下命令的缩写：

hbahbasehbck-fixAssignments-fixMeta-fixHdfsHoles-fixHdfsOrphans-fixHdfsOverlaps-fixVersionFile–sidelineBigOverlaps

    可以指定表名：

hba         hbasehbck-repairTable1Table2

         hbasehbck-fixMetaOnly–fixAssignments

     如果只有META表的region不一致，则可以使用这个命令修复

          hbasehbck–fixVersionFile

          Hbase的数据文件启动时需要一个versionfile，如果这个文件丢失，可以用这个命令来新建一个，但是要保证hbck的版本和Hbase集群的版本是一样的

         hbaseorg.apache.hadoop.hbase.util.hbck.OfflineMetaRepair

      如果ROOT表和META表都出问题了Hbase无法启动，可以用这个命令来创建新的ROOT和META表。

      这个命令的前提是Hbase已经关闭，执行时它会从hbase的home目录加载hbase的相关信息（.regioninfo），如果表的信息是完整的就会创建新的root和meta目录及数据

         hbasehbck–fixSplitParents

       当region做split操作的时候，父region会被自动清除掉。

但是有时候子region在父region被清除之前又做了split。

造成有些延迟离线的父region存在于META表和HDFS中，但是没有部署，HBASE又不能清除他们。

这种情况下可以          使用此命令重置这些在META表中的region为在线状态并且没有split。

然后就可以使用之前的修复命令把这个region修复

  10.  手动mergeregion

进行操作前先将balancer关闭，操作完成后再打开balancer

经过一段时间的运行之后有可能会产生一些很小的region，需要定期检查这些region并将它们和相邻的region合并以减少系统的总region数，减少管理开销

    合并方法：

1.找到需要合并的region的encodedname

2.进入hbaseshell

3.执行merge_region‘region1’,’region2’

    手动分配region

如果发现台regionServer资源占用特别高，可以检查这台regionserver上的region是否存在过多比较大的region,通过hbaseshell将部分比较大的region分配给其他不是很忙的regionsserver：

move'encodeRegionName','ServerName'

         # encodeRegionName指的regioName后面的编码，ServerName指的是master-status的RegionServers列表

例：

move'24d9eef6ba5616b1a60180503e62bae7','DN1,60020,1429840460046'

   手动major_compact

进行操作前先将balancer关闭，操作完成后再打开balancer

选择一个系统比较空闲的时间手工major_compact，如果hbase更新不是太频繁，可以一个星期对所有表做一次major_compact，这个可以在做完一次major_compact后，观看所有的storefile数量，如果storefile数量增加到major_compact后的storefile的近二倍时，可以对所有表做一次major_compact，时间比较长，操作尽量避免高锋期

注：

fms现在生产上开启了自动major_compact，不需要做手动majorcompact

  balance_switch

balance_switchtrue打开balancer

balance_switchflase关闭balancer

配置master是否执行平衡各个regionserver的region数量，当我们需要维护或者重启一个regionserver时，会关闭balancer，这样就使得region在regionserver上的分布不均，这个时候需要手工的开启balance。

  regionserver重启

    graceful_stop.sh--restart--reload--debug nodename

进行操作前先将balancer关闭，操作完成后再打开balancer

这个操作是平滑的重启regionserver进程，对服务不会有影响，他会先将需要重启的regionserver上面的所有 region迁移到其它的服务器，然后重启，最后又会将之前的region迁移回来，但我们修改一个配置时，可以用这种方式重启每一台机    子，对于hbaseregionserver重启，不要直接kill进程，这样会造成在zookeeper.session.timeout这个时间长的中断，也不要通过 bin/hbase-daemon.shstopregionserver去重启，如果运气不太好，-ROOT-或者.META.表在上面的话，所有的    请求会全部失败

 regionserver关闭下线

bin/graceful_stop.sh nodename

进行操作前先将balancer关闭，操作完成后再打开balancer

和上面一样，系统会在关闭之前迁移所有region，然后stop进程。

 flush表

所有memstore刷新到hdfs，通常如果发现regionserver的内存使用过大，造成该机的regionserver很多线程block，可以执行一下flush操作，这个操作会造成hbase的storefile数量剧增，应尽量避免这个操作，还有一种情况，在hbase进行迁移的时候，如果选择拷贝文件方式，可以先停写入，然后flush所有表，拷贝文件

强制split

Hbase允许客户端强制执行split,在hbaseshell中执行以下命令：

split'forced_table','b'//其中forced_table为要split的table,‘b’为split点

regionsplits 执行过程：

regionserver处理写请求的时候，会先写入memstore，当memstore达到一定大小的时候，会写入磁盘成为一个storefile。

这个过程叫做memstoreflush。

当storefiles堆积到一定大小的时候，regionserver会执行‘compact’操作，把他们合成一个大的文件。

当每次执行完flush或者compact操作，都会判断是否需要split。

当发生split的时候，会生成两个regionA和regionB但是parentregion数据file并不会发生复制等操作，而是regionA和regionB会有这些file的引用。

这些引用文件会在下次发生compact操作的时候清理掉，并且当region中有引用文件的时候是不会再进行split操作的。

这个地方需要注意一下:

（大量的写入会刷大量的HFile，一个region就会对这大量的hfile进行compact操作。

如果这时候触发了split操作，这个region会成为父region，而两个子region会保留父region的引用文件。

而在这其间，子region会继续写入数据。

那么又可能触发子region的compact，这里的关键点来了——子region如果做compact的文件都是新写入的文件，而迟迟不去compact父region引用的文件，会导致一个问题——就是这个子region无法被split掉了（因为含有父region引用的region是不能被split的）。

那么子region越来越大，由于写入文件数量急剧增长，父region的ref文件总也得不到机会compact，就形成了大region的恶性循环情况——由于region太大，compact无法完成，但是由于compact无法完成导致region无法split，无法分摊compact的压力给其他regionserver。

）

虽然splitregion操作是regionserver单独确定的，但是split过程必须和很多其他部件合作。

regionserver在split开始前和结束前通知master,并且需要更新.META.表，这样，客户端就能知道有新的region。

在hdfs中重新排列目录结构和数据文件。

split是一个复杂的操作。

在splitregion的时候会记录当前执行的状态，当出错的时候，会根据状态进行回滚。

下图表示split中，执行的过程。

（红色线表示regionserver或者master的操作，绿色线表示client的操作。

）

1.regionserver决定splitregion，第一步，regionserver在zookeeper中创建在

/hbase/region-in-transition/region-name目录下，创建一个znode，状态为SPLITTING.

2.因为master有对 region-in-transition的znode做监听，所以，mater的得知parentregion需要split

3.regionserver 在hdfs的parentregion的目录下创建一个名为“.splits”的子目录

4.regionserver关闭parentregion。

强制flush缓存，并且在本地数据结构中标记region为下线状态。

如果这个时候客户端刚好请求到parentregion，会抛出NotServingRegionException。

这时客户端会进行补偿性重试。

5.regionserver在.split目录下分别为两个daughterregion创建目录和必要的数据结构。

然后创建两个引用文件指向parentregions的文件。

6.regionserver在HDFS中，创建真正的region目录，并且把引用文件移到对应的目录下。

7.regionserver发送一个put的请求到.META.表中，并且在.META.表中设置parentregion为下线状态，并且在parentregion对应的row中两个daughterregion的信息。

但是这个时候在.META.表中daughterregion还不是独立的row。

这个时候如果clientscan.META.表，会发现parentregion正在split，但是client还看不到daughterregion的信息。

当这个put成功之后，parentregionsplit会被正在的执行。

如果在RPC成功之前regionserver就失败了，master和下次打开parentregion的regionserver会清除关于这次split的脏状态。

但是当RPC返回结果给到parentregion，即.META.成功更新之后，，regionsplit的流程还会继续进行下去。

相当于是个补偿机制，下次在打开这个parentregion的时候会进行相应的清理操作。

8.regionserver打开两个daughterregion接受写操作。

9.regionserver在.META.表中增加daughtersA和B region的相关信息，在这以后，client就能发现这两个新的regions并且能发送请求到这两个新的region了。

client本地具体有.META.表的缓存，当他们访问到parentregion的时候，发现parentregion下线了，就会重新访问.META.表获取最新的信息，并且更新本地缓存。

10.regionserver更新znode 的状态为SPLIT。

master就能知道状态更新了，master的平衡机制会判断是否需要把daughterregions分配到其他regionserver中。

11.在split之后，meta和HDFS依然会有引用指向parentregion.当compact操作发生在daughterregions中，会重写数据file，这个时候引用就会被逐渐的去掉。

垃圾回收任务会定时检测daughterregions是否还有引用指向parentfiles，如果没有引用指向parentfiles的话，parentregion就会被删除。

0.96版本中去掉了root表，因为觉的目的是根据root表获取meta地址，过程是通过zookeeper获取root表地址，在根据root表记录meta表地址进行访问，还不如和zookeeper通讯一次。

meta表信息存放在zookeeper的/hbase/meta-region-server文件中。

新版本中还添加了hbase:

namespace命名空间表，系统表放在hbase空间下，用户表如果没有指定命名空间则放在default空间下。

重新生成META表：

 ./hbaseorg.apache.hadoop.hbase.util.hbck.OfflineMetaRepair

宽表好处：

行数变少，bolckindex索引减少。

布隆过滤器metaindex索引减少。

减少空间占用和内存占用。

宽表劣处：

 hbase的split是基于行的，会影响split机制：

    HBase的split操作只会在行的边界上发生，所以更倾向于长窄表：

     宽表情况下，单独一行大小超过hbase.hregion.max.filesize值，也不会做分割

     相同rowkey下插入很多不同版本的记录，即使大小超过hbase.hregion.max.filesize值，也不会做分割

窄表好处：

将列放入rowkey查询更加灵活方便。

利于split机制

窄表劣处：

索引空间占用比宽表要大。

 MR统计行数：

$HBASE_HOME/bin/hbaseorg.apache.hadoop.hbase.mapreduce.RowCounter‘tablename’