Hbase HBCK2

1. Apache HBase HBCK2 Tool

HBCK2 是 Apache HBase 集群的修复工具。

Operator 中的问题都属于 bug。之所以需要 HBCK2 修复，意味着是一种在新的 hbase 版本中发布之前进行修复错误的解决方法。

1.1. HBCK2 vs hbck1

HBCK2 是 hbck 的继承者，hbck (或者说是 hbck1) 是 hbase-1.x 版本附带的修复工具。使用 HBCK2 代替 hbck1 对 hbase-2.x 集群进行修复。

hbck1 不应该 hbase-2.x 环境上运行，因为可能会带来一定的风险。为了减少意外，hbck1 仍然绑定在 hbase-2.x 版本中，但是已经被弃用，将会在 hbase-3.x 被移除。
hbck1 的-fix已经被删除，虽然它可以报告 hbase-2.x 集群的状态。但是它的评估是不准确的，因为它不理解 hbase-2.x 的内部工作原理。

即使 HBCK2 和 hbck1 两个工具中有名称类似的命令，但 HBCK2 和 hbck1 的工作完全不同。

1.2. 总述

HBCK2 每次运行时仅仅执行一个单独的任务。HBCK2 并不假定一个工具可以分析出集群运行中的所有问题，然后按照像 hbck1 工具那样的使用建议进行修复 “所有的问题”。

HBCK2 是用来修复的，对于集群运行中的 inconsistencies 或堵塞问题，可以查看集群 Master 运行的日志或者 Web UI。一旦发现问题，可以使用 HBCK2 工具来要求 Master 执行修复或跳过坏状态。

要求 Master 执行修复，而不是尝试在修复工具的上下文中进行本地修复，这是 HBCK2 和 hbck1 之间的另一个重要区别。

关于修复工具和 HBCK2 如何工作的更多信息可以在下面的章节中找到。

1.3. 获取 HBCK2

社区希望把 HBase 相关的外围工具抽离出 HBase 项目，所以在 github 上建了一个项目 hbase-operator-tools， HBCK2 是该项目的子模块之一。因此可以直接从 github 上获取该项目，当然在 HBase 官网的下载页也提供了相应的下载路径 HBASE Downloads Page。HBase 官网提供的下载包并不是最新的。

1.4. 构建 HBCK2

构建时, 需要将 hbase-operator-tools 项目中父 pom.xml 文件中 hbase 的版本修改成与自己集群所对应的版本，以匹配自己集群的部署，实现最平稳的运行(hbase-operator-tools 项目中父 pom.xml 文件详见 hbase.version to set)

编译出 jar 包：

$ mvn install

构建的 hbck2 jar 将位于 hbase-hbck2 模块的 target 子目录中。

1.5. 运行 HBCK2

当 HBCK2 版本在你的 hbase 版本之前，你的 hbase 可能不支持当前 HBCK2 中的所有 API。当 HBCK2 的 API 服务器端不支持时，它应该优雅地失败。这时需要使用旧版本的 HBCK2 或升级集群。

构建的 HBCK2 jar 包并不是一个 ‘fat’ jar，不包含 Dependencies，Dependencies 必须是 provided。最简单的“提供” HBCK2 依赖项的方式是通过 $HBASE_HOME/bin/hbase 脚本启动 HBCK2。

bin/hbase 脚本本身就提供了 hbck 选项，可以在帮助输出中看到 hbck 选项。
默认情况下，运行 bin/hbase hbck 时，会运行内置的 hbck1 工具。想要运行 HBCK2，需要使用 -j 选项指向构建的 HBCK2 jar 包，如下所示:

 $ ${HBASE_HOME}/bin/hbase --config /etc/hbase-conf hbck -j ~/hbase-operator-tools/hbase-hbck2/target/hbase-hbck2-1.0.0-SNAPSHOT.jar

在上述示例中，/etc/hbase-conf 是 hbase 集群的配置文件路径，~/hbase-operator-tools/hbase-hbck2/target/hbase-hbck2-1.0.0-SNAPSHOT.jar 是 HBCK2 jar 包的路径。

不带任何参数运行 HBCK2 jar 时，将会打印 HBCK2 的 help 信息。

usage: HBCK2 [OPTIONS] COMMAND <ARGS>
Options:
 -d,--debug                                       run with debug output
 -h,--help                                        output this help message
 -p,--hbase.zookeeper.property.clientPort <arg>   port of hbase ensemble
 -q,--hbase.zookeeper.quorum <arg>                hbase ensemble
 -s,--skip                                        skip hbase version check
                                                  (PleaseHoldException)
 -v,--version                                     this hbck2 version
 -z,--zookeeper.znode.parent <arg>                parent znode of hbase
                                                  ensemble
Command:
 addFsRegionsMissingInMeta <NAMESPACE|NAMESPACE:TABLENAME>...
   Options:
    -d,--force_disable aborts fix for table if disable fails.
   To be used when regions missing from hbase:meta but directories are present still in HDFS. 
   Can happen if user has run _hbck1_ 'OfflineMetaRepair' against an hbase-2.x cluster. 
   Needs hbase:meta to be online. 
   For each table name passed as parameter,  performs diff between regions available in hbase:meta and region dirs on HDFS.
   Then for dirs with no hbase:meta matches, it reads the  'regioninfo' metadata file and re-creates given region in  hbase:meta. 
   Regions are re-created in 'CLOSED' state in the hbase:meta table, but not in the Masters' cache, and they are not assigned either. 
   To get these regions online, run the HBCK2 'assigns'command printed when this command-run completes.
   NOTE: If using hbase releases older than 2.3.0, a rolling restart of HMasters is needed prior to executing the set of 'assigns' output.
   An example adding missing regions for tables 'tbl_1' in the default namespace, 'tbl_2' in namespace 'n1' and for all tables from namespace 'n2':
     $ HBCK2 addFsRegionsMissingInMeta default:tbl_1 n1:tbl_2 n2
   Returns HBCK2  an 'assigns' command with all re-inserted regions.
   SEE ALSO: reportMissingRegionsInMeta
   SEE ALSO: fixMeta

 assigns [OPTIONS] <ENCODED_REGIONNAME/INPUTFILES_FOR_REGIONNAMES>...
   Options:
    -o,--override  override ownership by another procedure
    -i,--inputFiles  take one or more encoded region names
   A 'raw' assign that can be used even during Master initialization (if the -skip flag is specified). 
   Skirts Coprocessors. Pass one or more encoded region names. 
   1588230740 is the hard-coded name for the hbase:meta region and  de00010733901a05f5a2a3a382e27dd4 is an example of what a user-space encoded region name looks like. 
   For example:
     $ HBCK2 assigns 1588230740 de00010733901a05f5a2a3a382e27dd4
   Returns the pid(s) of the created AssignProcedure(s) or -1 if none.
   If -i or --inputFiles is specified, pass one or more input file names.
   Each file contains encoded region names, one per line. For example:
     $ HBCK2 assigns -i fileName1 fileName2
 bypass [OPTIONS] <PID>...
   Options:
    -o,--override   override if procedure is running/stuck
    -r,--recursive  bypass parent and its children. SLOW! EXPENSIVE!
    -w,--lockWait   milliseconds to wait before giving up; default=1
   Pass one (or more) procedure 'pid's to skip to procedure finish. 
   Parent of bypassed procedure will also be skipped to the finish. 
   Entities will be left in an inconsistent state and will require manual fixup. 
   May need Master restart to clear locks still held. Bypass fails if
   procedure has children. 
   Add 'recursive' if all you have is a parent pid to finish parent and children. 
   This is SLOW, and dangerous so use selectively. Does not always work.

 extraRegionsInMeta <NAMESPACE|NAMESPACE:TABLENAME>...
   Options:
    -f, --fix    fix meta by removing all extra regions found.
   Reports regions present on hbase:meta, but with no related directories on the file system. Needs hbase:meta to be online.
   For each table name passed as parameter, performs diff
   between regions available in hbase:meta and region dirs on the given file system. Extra regions would get deleted from Meta
   if passed the --fix option.
   NOTE: Before deciding on use the "--fix" option, it's worth check if reported extra regions are overlapping with existing valid regions.
   If so, then "extraRegionsInMeta --fix" is indeed the optimal solution.
   Otherwise, "assigns" command is the simpler solution, as it recreates
   regions dirs in the filesystem, if not existing.
   An example triggering extra regions report for tables 'table_1'
   and 'table_2', under default namespace:
     $ HBCK2 extraRegionsInMeta default:table_1 default:table_2
   An example triggering extra regions report for table 'table_1'
   under default namespace, and for all tables from namespace 'ns1':
     $ HBCK2 extraRegionsInMeta default:table_1 ns1
   Returns list of extra regions for each table passed as parameter, or
   for each table on namespaces specified as parameter.

 filesystem [OPTIONS] [<TABLENAME>...]
   Options:
    -f, --fix    sideline corrupt hfiles, bad links, and references.
   Report on corrupt hfiles, references, broken links, and integrity.
   Pass '--fix' to sideline corrupt files and links. '--fix' does NOT fix integrity issues; i.e. 'holes' or 'orphan' regions. 
   Pass one or more tablenames to narrow checkup. Default checks all tables and restores 'hbase.version' if missing. 
   Interacts with the filesystem only! Modified regions need to be reopened to pick-up changes.

 fixMeta
   Do a server-side fix of bad or inconsistent state in hbase:meta.
   Available in hbase 2.2.1/2.1.6 or newer versions. 
   Master UI has matching, new 'HBCK Report' tab that dumps reports generated by most recent run of _catalogjanitor_ and a new 'HBCK Chore'. 
   It is critical that hbase:meta first be made healthy before making any other repairs. 
   Fixes 'holes', 'overlaps', etc., creating (empty) region directories in HDFS to match regions added to hbase:meta.
   Command is NOT the same as the old _hbck1_ command named similarily. 
   Works against the reports generated by the last catalog_janitor and hbck chore runs. If nothing to fix, run is a noop. 
   Otherwise, if 'HBCK Report' UI reports problems, a run of fixMeta will clear up hbase:meta issues. 
   See 'HBase HBCK' UI for how to generate new report.
   SEE ALSO: reportMissingRegionsInMeta

 replication [OPTIONS] [<TABLENAME>...]
   Options:
    -f, --fix    fix any replication issues found.
   Looks for undeleted replication queues and deletes them if passed the '--fix' option. Pass a table name to check for replication barrier and purge if '--fix'.

 reportMissingRegionsInMeta <NAMESPACE|NAMESPACE:TABLENAME>...
   To be used when regions missing from hbase:meta but directories are present still in HDFS. 
   Can happen if user has run _hbck1_ 'OfflineMetaRepair' against an hbase-2.x cluster. 
   This is a CHECK only method, designed for reporting purposes and doesn't perform any fixes, providing a view of which regions (if any) would get re-added to hbase:meta, grouped by respective table/namespace. 
   To effectively re-add regions in meta, run addFsRegionsMissingInMeta.
   This command needs hbase:meta to be online. For each namespace/table passed as parameter, it performs a diff between regions available in hbase:meta against existing regions dirs on HDFS. 
   Region dirs with no matches are printed grouped under its related table name. 
   Tables with no missing regions will show a 'no missing regions' message. 
   If no namespace or table is specified, it will verify all existing regions.
   It accepts a combination of multiple namespace and tables. 
   Table names should include the namespace portion, even for tables in the default namespace, otherwise it will assume as a namespace value.
   An example triggering missing regions report for tables 'table_1'
   and 'table_2', under default namespace:
     $ HBCK2 reportMissingRegionsInMeta default:table_1 default:table_2
   An example triggering missing regions report for table 'table_1' under default namespace, and for all tables from namespace 'ns1':
     $ HBCK2 reportMissingRegionsInMeta default:table_1 ns1
   Returns list of missing regions for each table passed as parameter, or for each table on namespaces specified as parameter.

 setRegionState <ENCODED_REGIONNAME> <STATE>
   Possible region states:
    OFFLINE, OPENING, OPEN, CLOSING, CLOSED, SPLITTING, SPLIT,
    FAILED_OPEN, FAILED_CLOSE, MERGING, MERGED, SPLITTING_NEW,
    MERGING_NEW, ABNORMALLY_CLOSED
   WARNING: This is a very risky option intended for use as last resort.
   Example scenarios include unassigns/assigns that can't move forward because region is in an inconsistent state in 'hbase:meta'. 
   For example, the 'unassigns' command can only proceed if passed a region in one of the following states: SPLITTING|SPLIT|MERGING|OPEN|CLOSING Before manually setting a region state with this command, please certify that this region is not being handled by a running procedure, such as 'assign' or 'split'. 
   You can get a view of running procedures in the hbase shell using the 'list_procedures' command. 
   An example setting region 'de00010733901a05f5a2a3a382e27dd4' to CLOSING:
     $ HBCK2 setRegionState de00010733901a05f5a2a3a382e27dd4 CLOSING
   Returns "0" if region state changed and "1" otherwise.

 setTableState <TABLENAME> <STATE>
   Possible table states: ENABLED, DISABLED, DISABLING, ENABLING To read current table state, in the hbase shell run:
     hbase> get 'hbase:meta', '<TABLENAME>', 'table:state'
   A value of \x08\x00 == ENABLED, \x08\x01 == DISABLED, etc.
   Can also run a 'describe "<TABLENAME>"' at the shell prompt.
   An example making table name 'user' ENABLED:
     $ HBCK2 setTableState users ENABLED
   Returns whatever the previous table state was.

 scheduleRecoveries <SERVERNAME>...
   Schedule ServerCrashProcedure(SCP) for list of RegionServers. 
   Format server name as '<HOSTNAME>,<PORT>,<STARTCODE>' (See HBase UI/logs).
   Example using RegionServer 'a.example.org,29100,1540348649479':
     $ HBCK2 scheduleRecoveries a.example.org,29100,1540348649479
   Returns the pid(s) of the created ServerCrashProcedure(s) or -1 if no procedure created (see master logs for why not).
   Command support added in hbase versions 2.0.3, 2.1.2, 2.2.0 or newer.

 unassigns <ENCODED_REGIONNAME>...
   Options:
    -o,--override  override ownership by another procedure
   A 'raw' unassign that can be used even during Master initialization (if the -skip flag is specified). 
   Skirts Coprocessors. 
   Pass one or more encoded region names. 1588230740 is the hard-coded name for the hbase:meta region and de00010733901a05f5a2a3a382e27dd4 is an example of what a userspace encoded region name looks like. 
   For example:
     $ HBCK2 unassign 1588230740 de00010733901a05f5a2a3a382e27dd4
   Returns the pid(s) of the created UnassignProcedure(s) or -1 if none.

   SEE ALSO, org.apache.hbase.hbck1.OfflineMetaRepair, the offline hbase:meta tool. 
   See the HBCK2 README for how to use.

请注意，当向 bin/hbase 传递 hbck 参数时，默认情况下，它将使用着色客户端来访问目标 hbase 群集。这个对于大多数 HBCK2 使用来说已经足够了。如果遇到以下错误：

bin/hbase --config hbase-conf  hbck
2019-08-30 05:04:54,467 WARN  [main] util.NativeCodeLoader: Unable to load native-hadoop library for your platform... using builtin-java classes where applicable
Exception in thread "main" java.io.IOException: No FileSystem for scheme: hdfs
        at org.apache.hadoop.fs.FileSystem.getFileSystemClass(FileSystem.java:2799)
        at org.apache.hadoop.fs.FileSystem.createFileSystem(FileSystem.java:2810)
        at org.apache.hadoop.fs.FileSystem.access$200(FileSystem.java:100)
        at org.apache.hadoop.fs.FileSystem$Cache.getInternal(FileSystem.java:2849)
        at org.apache.hadoop.fs.FileSystem$Cache.get(FileSystem.java:2831)
        at org.apache.hadoop.fs.FileSystem.get(FileSystem.java:389)
        at org.apache.hadoop.fs.Path.getFileSystem(Path.java:356)
        at org.apache.hadoop.hbase.util.CommonFSUtils.getRootDir(CommonFSUtils.java:361)
        at org.apache.hadoop.hbase.util.HBaseFsck.main(HBaseFsck.java:3605)

这是因为 HDFS jars 包不在 CLASSPATH 上。默认情况下，当通过 bin/hbase 运行 hbck 时，不在 CLASSPATH 上绑定 DFS jars。在环境中定义HADOOP_HOME，以便 bin/hbase 可以找到本地安装的 HADOOP，然后加载其 HDFS jar。

1.6. HBCK2 概述

HBCK2 目前是一个简单的工具，一次只做一件事。

在 hbase-2.x 集群中，Master 是所有状态的最终仲裁者，因此对于大多数 HBCK2 命令来说，它要求 Master 执行所有修复。这意味着在运行 HBCK2 命令之前必须启动 Master。

HBCK2 实现方法是使用 Master 上托管的 HbckService。该服务发布了一些方法供 HBCK2 工具使用。因此，对于依赖于 Master 上 HbckService 服务的 HBCK2 命令，HBCK2 做的第一件事就是试探集群以确保服务可用。

如果服务器没有发布服务，或者 HbckService 缺少所请求的方法，则此操作将失败。对于后一种情况，需要更新集群以获得更多的修复功能。

一个 HBCK2 版本的工具应该能够跨多个 hbase-2.x 版本工作。如果无法运行，HBCK2 将会失败并且给出提示。在 2.0.3 和 2.1.1 之前的 hbase 版本中没有 HbckService。因此 HBCK2 不能工作和部署在这些版本上。

接下来，首先介绍如何在运行中的集群中“发现”问题，然后介绍如何“修复”发现的问题。

1.7. 发现问题

当 hbck1 执行分析时会报告集群正常还是异常，HBCK2 并不像 hbck1 那么武断，在 hbase-2.x 中，操作员计算出需要修复的部分，然后使用包括 HBCK2 在内的工具进行修复，操作人员可能必须来回运行几轮 HBCK2，然后检查集群状态。

为了得出集群中的问题，请利用下面列出的工具和排查方式。

1.7.1. 诊断工具

1.7.1.1. Master Logs

Master 运行所有的分配、服务器崩溃处理、集群启动和停止等等。在 hbase-2.x 环境中，Master 所做的一切都被转换为运行在状态机引擎上的 Procedures。详见 Procedure Framework 和 Assignment Manager 获取有关这些新特性如何工作的详细信息。

每个 Procedure 都有一个惟一的过程 id，即它的 pid，它会在每次日志记录中列出这个 pid。根据 pid，可以在 Master 日志中跟踪 Procedure 的生命周期，从 Procedure 开始到 Procedure 的每个阶段直至 Procedure 结束。有些 Procedure 产生子 Procedure，那么需要等待它们的子 Procedure 完成后，然后自己才可以完成。每个子 Procedure 都记录它的 pid 和 ppid (其父级的 pid)。

一般来说，所有的运行都没有问题，但是如果出现一些不可预见的情况，assignment 可能承受需要操作员干预的损害。
下面将讨论一些这样的情况：可能会在 Master 日志中显示为一个 Region 被 STUCK；或者由于另一个 Procedure 持有的 exclusive lock 并没有释放，导致一个 Procedure transitioning 实体（一个 Region 或一个 Table）被阻塞。

STUCK Procedures 在 Master 日志中的现象如下:

2018-09-12 15:29:06,558 WARN org.apache.hadoop.hbase.master.assignment.AssignmentManager: STUCK Region-In-Transition rit=OPENING, location=va1001.example.org,22101,1536173230599, table=IntegrationTestBigLinkedList_20180626110336, region=dbdb56242f17610c46ea044f7a42895b

1.7.1.2. Master UI: /master-status#tables

在 Master UI 主页的中间部分显示了一个 Tables 列表，列出了全部表的状态(ENABLED, ENABLING, DISABLING 或 DISABLED)。还列出了对应 Region 处于不同转换状态下（OPEN, CLOSED 等）数量。

通过该 Tables 列表有助于确定表的 Region 是否具有适当的配置。例如，如果一个表是处于 ENABLED 状态，而有些 Region 没有处于 OPEN 状态，并且 Master 日志对于任何正在进行的 assign 是静止的，那么一定是出了问题。

1.7.1.3. Master UI: ‘Procedures & Locks’

在 Master UI 主页的 Procedures & Locks 菜单栏下，在页面标题中列出了所有正在进行的 Procedure 和 Locks，以及当前的 Master Procedure WALs

启动时，在一个大型集群上进行激烈的分配时，这个页面充满了 Procedure 和 Locks 的列表。MasterProcWALs 的数量也会增加。如果在集群稳定下来后，有一个卡住的 Procedure 或 Locks 或 MasterProcWALs 的计数没有下降，而只是增长，那么需要操作员干预以排除堵塞。。

Procedure 和 Locks 的列表也可以通过 hbase shell 获得:

$ echo "list_locks" | hbase shell &> /tmp/locks.txt
$ echo "list_procedures" | hbase shell &> /tmp/procedures.txt

1.7.1.4. Master UI: The ‘HBCK Report’

在hbase 2.3.0 / 2.1.6 / 2.2.1版本 Master 的 /hbck.jsp 中添加了一个 HBCK Report 页面，它显示了 Master 按一定时间间隔运行的两次检查的输出；结果在访问该页面时输出。如果在 hbase:meta 出现 overlaps 或 holes，那么可以再该页面相对中部的位置找到相关内容（否则没有内容）。添加了另一个后台 “chore” 进程来进行 hbase:meta 与文件系统内容的比较；如果异常，将在其 HBCK Report 加以说明。

请参阅 “HBCK Report” 页面，了解如何强制执行检查员。

1.7.1.5. HBase Canary 工具

Canary 工具在验证 assign 的状态时非常有用。它可以针对某个具体的表运行，也可以针对整个集群运行。

例如，要检查集群分配:

$ hbase canary -f false -t 6000000 &>/tmp/canary.log

-f false 表示遇到失败的 Region 时继续执行检查； -t 6000000 表示最多运行2个小时后结束。
等待工具检测完成后，通过搜索上述 canary.log 文件中的 ERROR 行，来查找有问题的 Region 分配。

也可以进行像 Canary 在 hbase shell 中那样的检测，例如，给定一个 testtable 表中起始行为 d1dddd0c 的 Region，请执行以下操作：

hbase> scan 'testtable', {STARTROW => 'd1dddd0c', LIMIT => 10}

要了解如何将 Region 名称解析为其组成部分，详见 RegionInfo API.

1.7.1.6. 其他工具

想要计算处于 ENABLED 或 ENABLING 状态的表中非 OPEN 状态的 Region 列表，需要查询 hbase:meta 表的 info:state 列。例如，要查找表 IntegrationTestBigLinkedList_20180626064758 中所有 Region 的状态，执行以下操作:

$ echo "scan 'hbase:meta', {ROWPREFIXFILTER => 'IntegrationTestBigLinkedList_20180626064758,', COLUMN => 'info:state'}" | hbase shell > /tmp/t.txt

然后搜索 OPENING 或 CLOSING 的 Regions。

要将 OPENING 的问题移动到 OPEN 状态，使其符合表的 ENABLED 状态，可以在 hbase shell 中使用 assign 命令将一个新的分配 Procedure 放入到队列中（查看 Master 志以查看分配运行情况）。如果要指定多个 Region，请使用 HBCK2 工具。它可以进行批量 assign。

1.8. 修复问题

1.8.1. 一般性原则

在进行修复时，首先要确保 hbase:meta 是一致的，然后再修复其他类型的问题，比如文件系统异常。文件系统中的异常或分配问题应该在 hbase:meta 被整理好之后解决。如果 hbase:meta 出现故障，那么在采用 ‘Orphan’ Data 或进行 Region 分配时 Master 无法正确启动。

需要记住的其他一般原则包括，如果一个 Region 处于 CLOSING 状态，而不首先通过 CLOSED 进行转换，那么它就不能被 assigned ，反之，如果它处于 OPENING 状态，那么它就不能被 unassigned。Region 状态必须总是从 CLOSED 到 OPENING 再到 OPEN 状态，然后再到 CLOSING 到 CLOSED 状态。

在进行修复时，要一次修复一张表。

此外，如果表处于 DISABLED 状态，则无法分配 Region。在 Master 日志中，可以看到 Master 日志将报告由于该表处于 DISABLED 状态而跳过了分配。

您可能希望分配一个 Region，因为它目前处于 OPENING 状态。在这种情况下，您可能必须临时将表状态设置为 ENABLED，以便进行分配；
您可能希望 Region 处于 CLOSED 状态，以便它与表的 DISABLED 状态一致。在这种情况下，在 unassign 之后再次设置它；
HBCK2 支持进行这样的操作。请参阅 HBCK2 使用帮助。

下面是迄今为止运行 hbase-2.x 的经验得出的指示或注意事项。下面描述的导致状态出现的根本问题已在 hbase 的更高版本中修复，因此如果可以，请升级 HBase 以避免出现所述的安全问题。

1.8.2. Assigning/Unassigning

通常，在分配时，Master将一直保持到成功。
assign 对 Region 使用独占锁。这将阻止并发的 assign 或 unassign 运行。对锁定 Region 的 assign 将等待直到释放锁之后才能进行。请参阅上面的 [Procedures&Locks] 部分了解当前未完成锁的列表。

1.8.3. Master 日志中出现 Master startup cannot progress, in holding-pattern until region onlined

这种情况不应发生，如果发生了，问题现象如下所示:

2018-10-01 22:07:42,792 WARN org.apache.hadoop.hbase.master.HMaster: hbase:meta,,1.1588230740 is NOT online; state={1588230740 state=CLOSING, ts=1538456302300, server=ve1017.example.org,22101,1538449648131}; ServerCrashProcedures=true. Master startup cannot progress, in holding-pattern until region onlined.

Master 无法继续启动，因为没有 Procedure 来分配 hbase:meta 表的 Region。使用 HBCK2 工具进行修复:

$ HBASE_CLASSPATH_PREFIX=./hbase-hbck2-1.0.0-SNAPSHOT.jar 
$ hbase org.apache.hbase.HBCK2 -skip assigns 1588230740

其中1588230740是 hbase:meta 表 Region 的 encoded 名称。通过 -skip 选项来停止 HBCK2 对 Master 执行操作检查。如果不使用该选项，当 Master 未启动时，Master 版本检查将提示 “Master is initializing response” 或 “PleaseHoldException”，并删除分配尝试。-skip命令将跳过版本检查，并使计划执行的 assign 着陆。

hbase:namespace 系统表也可能发生同样的情况，问题现象如下：

2019-07-09 22:08:38,966 WARN  [master/localhost:16000:becomeActiveMaster] master.HMaster: hbase:namespace,,1562733904278.9559cf72b8e81e1291c626a8e781a6ae. is NOT online; state={9559cf72b8e81e1291c626a8e781a6ae state=CLOSED, ts=1562735318897, server=null}; ServerCrashProcedures=true. Master startup cannot progress, in holding-pattern until region onlined.

查找 hbase:namespace 表 Region 的 encoded 名称，并执行上述类似 hbase:meta 表所做的操作，如下所示：

 $ ${HBASE_HOME}/bin/hbase --config /etc/hbase-conf hbck -j ./hbase-hbck2-1.0.0-SNAPSHOT.jar -skip assigns 9559cf72b8e81e1291c626a8e781a6ae

传递 hbase:namespace 表 Region 的 encoded 名称（每个 Region 的 encoded 名称并不相同）。

1.8.4. Missing Regions in hbase:meta region/table restore/rebuild

在一些异常的情况下，表的 Region 被从 hbase:meta 表中移除。

通过对此类问题进行分析归纳，发现此类情况是由操作员引发的。如用户在 HBCK2 集群上运行废弃了的 hbck1 OfflineMetaRepair 工具。 OfflineMetaRepair 是一个修复 HBase 1.x 版本上的 hbase:meta 表相关问题的“著名”工具。OfflineMetaRepair 原来的版本与 HBase 2.x 或更高版本不兼容，同时 OfflineMetaRepair 已经进行了一些调整，因此在极端情况下，它现在可以通过 HBCK2 运行。

在大多数情况下，Region 最终在 hbase:meta 中随机丢失，但是 hbase 仍然可以运行。在这种情况下，可以在 Master 在线时解决，使用 HBCK2 中的 addFsRegionsMissingInMeta 命令。这个命令对 hbase 的破坏要小于重建覆盖整个 hbase:meta，它甚至可以用于恢复系统 hbase:namespace 表中的 Region。

1.8.5. Extra Regions in hbase:meta region/table restore/rebuild

也可能存在这样的情况：表中 Region 已在文件系统中删除，但在 hbase:meta 表中仍有相应的信息。这可能是由于 splitting 或用户手动操作错误（如手动删除/移除了 Region 目录），甚至是元数据丢失问题（例如HBASE-21843）造成的。

这样的问题可以在 Master 在线时解决，使用 HBCK2 中的 extraRegionsInMeta --fix 命令。这个命令对 hbase 的破坏性小于重建覆盖整个 hbase:meta。在 HBCK2 “2.0.6”、“2.1.6”、“2.2.1”、“2.3.0”、“3.0.0” 之前的版本不支持 fixMeta 命令时，也很有用。

1.8.5.1. hbase:meta 在线情况下的重建方法

如果 hbase:meta 的损坏不是很严重，hbase 仍然可以将其上线，即使 hbase:namespace 表中 Region 在缺失的 Region 列表中。在 Master 初始化期间仍然可以 scan 'hbase:meta'，Master 将等待 hbase:namespace 被分配。

为了验证这种情况，可以按如下所示执行 scan 'hbase:meta' 命令。如果它没有超时或显示任何错误，则说明 hbase:meta 是在线的：

$ echo "scan 'hbase:meta', {COLUMN=>'info:regioninfo'}" | hbase shell

如果上面命令执行后没有显示任何错误，则可以使用 HBCK2 addFsRegionsMissingInMeta 命令进行修复。它读取文件系统上 Region 目录中可用的 Region 元数据信息，以便在 hbase:meta 中重新创建 Region。因为它可以在 hbase 部分运行的情况下运行，所以它尝试 disable 受报告问题影响的在线的表，并将读取 hbase:meta 中的 Region。

它可以检查特定的表或名称空间，或者所有名称空间中的所有表。下面的例子显示了在 default 名称空间中的 "tbl_1"表，在 n1 名称空间中的 “tbl_2” 表，以及在 n2 名称空间中的所有表中添加缺失的 Region：

$ ${HBASE_HOME}/bin/hbase --config /etc/hbase-conf hbck -j ./hbase-hbck2-1.0.0-SNAPSHOT.jar addFsRegionsMissingInMeta default:tbl_1 n1:tbl_2 n2

因为它独立于 Master 运行，所以一旦成功完成，就需要额外的步骤来实际分配重新添加的 Region。步骤如下：

1. addFsRegionsMissingInMeta 输出一个 assigns 命令，其中包含重新添加的所有 region。这个命令需要稍后执行，所以为了方便起见，请复制并保存它。
2. 对于 2.3.0 之前的 HBase 版本，在 addFsRegionsMissingInMeta 成功完成并保存了输出后，重新启动所有的 master。
3. 一旦 Master 的被重新启动并且 hbase:meta 已经在线（检查 Web UI 是否可访问），运行 #1 中 addFsRegionsMissingInMeta 输出保存每条 assigns 命令。

注意:如果 hbase:namespace 表的 Region 也在缺失的 Region 中，则需要在 #1 中返回的 assign 命令的开头添加 --skip 标志。

如果集群中 hbase:meta 表遭受灾难性损失，可以使用以下方法进行粗略的重新构建。

概括地说，首先停止集群；运行 HBCK2 OfflineMetaRepair 工具，它读取放入文件系统中的目录和元数据，尽最大努力重建一个可行的 hbase:meta 表；然后重新启动集群，进行 assign hbase:namespace 表 Region 使其在线；最后，重新 assign 要启用的 userspace 中表（因为重新构建 hbase:meta 是创建了一个所有表不在线、没有分配 Region 的 hbase:meta 表）。

1.8.5.2. hbase:meta 不在线情况下的重建方法

首先停止集群，执行 HBCK2 中重建 hbase:meta 的命令。这将会删除原来的 hbase:meta 表然后重建创建一个新的。
下面是如何运行该工具的示例。添加了 -details 参数，这样工具就可以在文件系统中找到 Region 存储信息：

$ HBASE_CLASSPATH_PREFIX=~/hbase-operator-tools/hbase-hbck2/target/hbase-hbck2-1.0.0-SNAPSHOT.jar
$ ./bin/hbase org.apache.hbase.hbck1.OfflineMetaRepair -details

然后启动集群，但是集群并不会完全被正常启动。它将会被卡住，因为 hbase:namespace 表并不在线，以及 procedure 存储中并没有这个意外发生的 assign procedure。Master 日志将显示如下所示的内容：

2019-07-10 18:30:51,090 WARN  [master/localhost:16000:becomeActiveMaster] master.HMaster: hbase:namespace,,1562808216225.725a0fe6c2c869d3d0a9ed82bfa80fa3. is NOT online; state={725a0fe6c2c869d3d0a9ed82bfa80fa3 state=CLOSED, ts=1562808619952, server=null}; ServerCrashProcedures=false. Master startup cannot progress, in holding-pattern until region onlined.

要 assign hbase:namespace 表 Region 不能使用 hbase shell。如果使用 Hasee shell，将会发生 PleaseHoldException 异常，因为 Master 尚未启动（Master 只有等待 hbase:namespace 表上线后，才会声明自己为启动的）。
必须使用 HBCK2 的 assigns 命令，还必须使用 -skip 命令来跳过 Master 版本检查（如果不使用 -skip 参数， HBCK2 调用也将引发使用 hbase shell 中 assign 命令的PleaseHoldException 异常，因为 Master 尚未启动）。操作示例如下：

$ HBASE_CLASSPATH_PREFIX=~/hbase-operator-tools/hbase-hbck2/target/hbase-hbck2-1.0.0-SNAPSHOT.jar
$ ./bin/hbase org.apache.hbase.HBCK2 -skip assigns 725a0fe6c2c869d3d0a9ed82bfa80fa3

如果执行返回 “Connection refused”，那么Master 是否启动？如果 Master 不能初始化自己，它将在一段时间后关闭。只需重新启动集群/Master并重新运行上面的 HBCK2 的 assigns 命令。

当 assigns 成功运行时，将看到它发出如下类似的信息。最后的 [48] 是分配过程 procedure 的pid。如果返回的pid是 [-1]，那么 Master 启动没有进行充分……请重试，或者检查 Region 的 encoded 是否正确。

$ HBASE_CLASSPATH_PREFIX=./hbase-hbck2-1.0.0-SNAPSHOT.jar 
$ ./bin/hbase org.apache.hbase.HBCK2 -skip assigns 725a0fe6c2c869d3d0a9ed82bfa80fa3
18:40:43.817 [main] WARN  org.apache.hadoop.util.NativeCodeLoader - Unable to load native-hadoop library for your platform... using builtin-java classes where applicable
18:40:44.315 [main] INFO  org.apache.hbase.HBCK2 - hbck support check skipped
[48]

检查 master 日志。Master应该被成功启动。可以在 Master 日志中 pid=48 成功完成。查找如下所示类似的日志来验证 Master 启动是否成功（可能会需要一段时间才会出现）。

master.HMaster: Master has completed initialization 132.515sec

重建 hbase:meta 表后增加的用户表处于 DISABLED 状态并且其 Region 处于 CLOSED 模式。需要重新 enable 用户表，使表的所有 Region 在线。
一次执行一个，或者查看 enable_all ".*" 命令的用法一次性启用所有表。

重建 hbase:meta 可能会丢失 edits，并且可能需要使用 HBCK2 后续提供方法来进行修复和清理。

1.8.6. 删除 reference 文件, 丢失 hbase.version 文件和 hfiles 文件损坏

HBCK2 可以检查挂起的 references 和损坏的 hfiles。可以要求它把坏文件放在一边，这些文件可能是为了克服某些 Region 无法在线或读取失败而需要的。

请参阅 HBCK2 列表中的 filesystem 命令。传递一个或多个 tablename（或 ‘none’ 检查所有表），它会报告坏文件。并传递 --fix 选项进行修复。

1.8.7. 使 Procedure 重新开始

在极端情况下，作为最后一种资源，如果 Master 是 “心烦意乱的”，甚至所有修复的尝试都只出现不可撤销 locks 或无法完成的 Procedures，并且（或者）/hbase/MasterProcWALs/ 目录无限制地增长，那么可以清除 Master 状态。只需将 hbase 的 /hbase/MasterProcWALs/ 目录 mv 到一边，然后重新启动 Master 进程。它将作为一张没有过去糟糕时光记忆的“白板”回来。

如果在擦除的时候，所有的 Region 都被愉快地指定或离线，那么在 Master 重新启动时，Master 应该像什么都没有发生一样继续。但是，如果当时有 Regions-In-Transition，那么操作员将不得不干预，将未完成的 assigns/unassigns 带到其终点。

阅读[其他工具]章节说明的 hbase:meta info:state 列，以确定需要 assigning/unassigning 的内容。

擦除了所有的历史——把 /hbase/MasterProcWALs/ 移到一边，则没有一个实体应该被锁定，所以可以自由地批量 assign/unassign。

1.8.8. 采用 ‘Orphan’ Data

关于如何修复 ‘HBCK Chore’ 报告的 orphan Regions，请查阅 refguide 中有关 completebulkload 工具的高级部分 ‘Adopting’ Stray Data.