使用 Apache HBase HBCK2 工具

Artículo
07/01/2024

本文展示如何使用 HBase HBCK2 工具。 HBCK2 是 Apache HBase 群集的修复工具。

HBCK2 概述

HBCK2 目前是一个简单的工具，它一次只执行一项操作。在 hbase-2.x 中，Master 是所有状态的最终仲裁者，因此大多数 HBCK2 命令的一般原则是它会请求 Master 执行所有修复。

Master 必须已启动并运行，然后你才能运行 HBCK2 命令。 HBCK1 执行了分析，并报告群集为正常或有问题，而 HBCK2 则较为保守。在 hbase-2.x 中，操作员确定需要修复的内容，然后使用工具（包括 HBCK2）进行修复。

HBCK2 与 HBCK1 的比较

HBCK2 是 HBCK 的继承者，它是 hbase-1.x（也称为 HBCK1）随附的修复工具。可以使用 HBCK2 代替 HBCK1 来针对 hbase-2.x 群集进行修复。 HBCK1 不应针对 hbase-2.x 安装运行，因为它可能会造成损坏。它的写入功能 (-fix) 已移除。它可报告 hbase-2.x 群集的状态，但其评估不准确，因为它不了解 hbase-2.x 的内部工作原理。

HBCK2 的工作方式与 HBCK1 不同，即使是命令在两个版本中命名类似的情况下也是如此。

获取 HBCK2

可在 HBase 分发目录下找到版本。有关详细信息，请参阅 HBase 下载页。

Master UI：HBCK 报告

在 /hbck.jsp 的 2.1.6 中，一个 HBCK 报告页添加到了 Master，该页面显示 Master 每隔一段时间运行的两次检查的输出。一个是 CatalogJanitor 每次运行时的输出。如果发现 hbase:meta 中有重叠或漏洞，CatalogJanitor 会列出它找到的内容。另一个后台 chore 进程会比较 hbase:meta 和文件系统内容。如果发现异常，它会在其 HBCK 报告部分进行记录。

若要运行 CatalogJanitor，请在 hbase shell 中执行命令：catalogjanitor_run。

若要运行 hbck chore，请在 hbase shell 中执行命令：hbck_chore_run。

这两个命令都不接受任何输入。

运行 HBCK2

可以通过 $HBASE_HOME/bin/hbase 脚本启动它来运行 hbck 命令。默认情况下，运行 bin/hbase hbck 时，将运行内置的 HBCK1 工具。若要运行 HBCK2，需要使用 -j 选项指向生成的 HBCK2 jar，如此例所示：

hbase --config /etc/hbase/conf hbck -j ~/hbase-operator-tools/hbase-hbck2/target/hbase-hbck2-1.x.x-SNAPSHOT.jar

此命令会打印 HBCK2 帮助，而不传递选项或参数。

HBCK2 命令

注意

在生产环境中运行这些命令之前，先在测试群集中测试以了解它们的功能。

assigns [OPTIONS] <ENCODED_REGIONNAME/INPUTFILES_FOR_REGIONNAMES>... | -i <INPUT_FILE>...

选项：

-o,--override：由另一过程替代所有权。
-i,--inputFiles：接受一个或多个编码区域名称。

此 raw 分配即使在 Master 初始化期间也可使用（如果指定了 -skip 标记）。它会绕过协处理器并传递一个或多个编码区域名称。 de00010733901a05f5a2a3a382e27dd4 是用户空间编码区域名称的示例。例如：

hbase --config /etc/hbase/conf hbck -j ~/hbase-operator-tools/hbase-hbck2/target/hbase-hbck2-1.x.x-SNAPSHOT.jar assigns de00010733901a05f5a2a3a382e27dd4

它返回创建的 AssignProcedures 的 PID，如果没有，则返回 -1。如果指定了 -i or --inputFiles，则它会传递一个或多个输入文件名。每个文件都包含编码区域名称，每行一个。例如：

hbase --config /etc/hbase/conf hbck -j ~/hbase-operator-tools/hbase-hbck2/target/hbase-hbck2-1.x.x-SNAPSHOT.jar assigns -i fileName1 fileName2

unassigns [OPTIONS] <ENCODED_REGIONNAME>...| -i <INPUT_FILE>...

选项：

-o,--override：由另一过程替代所有权。
-i,--inputFiles：接受编码名称的一个或多个输入文件。

此 raw 取消分配即使在 Master 初始化期间也可使用（如果指定了 -skip 标记）。它会绕过协处理器并传递一个或多个编码区域名称。 de00010733901a05f5a2a3a382e27dd4 是用户替代空间编码区域名称的示例。例如：

hbase --config /etc/hbase/conf hbck -j ~/hbase-operator-tools/hbase-hbck2/target/hbase-hbck2-1.x.x-SNAPSHOT.jar unassign de00010733901a05f5a2a3a382e27dd4

它返回创建的 UnassignProcedures 的 PID，如果没有，则返回 -1。如果指定了 -i or --inputFiles，则它会传递一个或多个输入文件名。每个文件都包含编码区域名称，每行一个。例如：

hbase --config /etc/hbase/conf hbck -j ~/hbase-operator-tools/hbase-hbck2/target/hbase-hbck2-1.x.x-SNAPSHOT.jar unassigns fileName1 -i fileName2

bypass [OPTIONS] <PID>...

选项：

-o,--override：如果过程正在运行或卡住，则替代。
-r,--recursive：绕过父级及其子级。 此选项速度缓慢且成本高昂。
-w,--lockWait：等待几毫秒后再放弃。默认值=1。
-i,--inputFiles：接受 PID 的一个或多个输入文件。

它会传递一个或多个过程 PID 以跳到过程完成。绕过的过程的父级会跳到完成。实体处于不一致状态，需要手动修复。它可能需要重启 Master 以清除仍保留的锁。如果过程具有子级，则绕过会失败。如果你只有一个父 PID，则添加 recursive 来完成父级和子级。 此选项速度缓慢且危险，因此请选择性地使用它。它并不总是有效。

hbase --config /etc/hbase/conf hbck -j ~/hbase-operator-tools/hbase-hbck2/target/hbase-hbck2-1.x.x-SNAPSHOT.jar bypass <PID>

如果指定了 -i or --inputFiles，则传递一个或多个输入文件名。每个文件都包含 PID，每行一个。例如：

hbase --config /etc/hbase/conf hbck -j ~/hbase-operator-tools/hbase-hbck2/target/hbase-hbck2-1.x.x-SNAPSHOT.jar bypass -i fileName1 fileName2

reportMissingRegionsInMeta <NAMESPACE|NAMESPACE:TABLENAME>... | -i <INPUT_FILE>...

选项：

i,--inputFiles：接受命名空间或表名的一个或多个输入文件。

如果 hbase:meta 中缺少区域，但 HDFS 中仍存在目录，请使用此选项。此命令只是一个检查方法。它专为报告目的而设计，不执行任何修复。它提供了一个视图，显示哪些区域（如果有）将被重新添加到 hbase:meta，按各自的表或命名空间分组。

若要在元中有效地重新添加区域，请运行 addFsRegionsMissingInMeta。此命令需要 hbase:meta 联机。对于作为参数传递的每个命名空间/表，它对照 HDFS 上的现有区域目录，在 hbase:meta 中可用的区域之间执行差异分析。没有匹配项的区域目录按其相关表名称进行分组打印。没有缺失区域的表显示“无区域缺失”消息。如果未指定命名空间或表，它会验证所有现有区域。

它接受多个命名空间和表的组合。表名称应包含命名空间部分，即使对于默认命名空间中的表也是如此。否则，它会假定一个命名空间值。此示例为默认命名空间下的表 table_1 和 table_2 触发缺失区域报告：

hbase --config /etc/hbase/conf hbck -j ~/hbase-operator-tools/hbase-hbck2/target/hbase-hbck2-1.x.x-SNAPSHOT.jar reportMissingRegionsInMeta default:table_1 default:table_2

此示例为默认命名空间下的表 table_1 以及命名空间 ns1 中的所有表触发缺失区域报告：

hbase --config /etc/hbase/conf hbck -j ~/hbase-operator-tools/hbase-hbck2/target/hbase-hbck2-1.x.x-SNAPSHOT.jar reportMissingRegionsInMeta default:table_1 ns1

它返回作为参数传递的每个表或指定为参数的命名空间上的每个表的缺失区域列表。如果指定了 -i or --inputFiles，则它会传递一个或多个输入文件名。每个文件都包含 <NAMESPACE|NAMESPACE:TABLENAME>，每行一个。例如：

hbase --config /etc/hbase/conf hbck -j ~/hbase-operator-tools/hbase-hbck2/target/hbase-hbck2-1.x.x-SNAPSHOT.jar reportMissingRegionsInMeta -i fileName1 fileName2

addFsRegionsMissingInMeta <NAMESPACE|NAMESPACE:TABLENAME>... | -i <INPUT_FILE>...

选项：

-i,--inputFiles：接受命名空间表名的一个或多个输入文件，当 hbase:meta 中缺少区域但 HDFS 中仍然存在目录时使用。 要求 hbase:meta 联机。

对于作为参数传递的每个表名称，它在 hbase:meta 中可用的区域和 HDFS 上的区域目录之间执行差异分析。然后，对于没有 hbase:meta 匹配项的目录，它读取 regioninfo 元数据文件，并在 hbase:meta 中重新创建特定区域。区域在 hbase:meta 表中以“已关闭”状态重新创建，而不是在 Masters 缓存中。也不会分配它们。若要使这些区域联机，请在此命令运行完成时运行打印的 HBCK2 assigns 命令。

如果你使用低于 2.3.0 的 hbase 版本，则需要在执行 assigns 输出集之前滚动重启 HMaster。此示例为默认命名空间中的表 tbl_1、命名空间 n1 中的 tbl_2 和命名空间 n2 中的所有表添加缺失区域：

hbase --config /etc/hbase/conf hbck -j ~/hbase-operator-tools/hbase-hbck2/target/hbase-hbck2-1.x.x-SNAPSHOT.jar addFsRegionsMissingInMeta default:tbl_1 n1:tbl_2 n2

它返回 HBCK2 和 assigns 命令以及所有重新插入的区域。如果指定了 -i or --inputFiles，则它会传递一个或多个输入文件名。每个文件都包含 <NAMESPACE|NAMESPACE:TABLENAME>，每行一个。例如：

hbase --config /etc/hbase/conf hbck -j ~/hbase-operator-tools/hbase-hbck2/target/hbase-hbck2-1.x.x-SNAPSHOT.jar addFsRegionsMissingInMeta -i fileName1 fileName2

extraRegionsInMeta <NAMESPACE|NAMESPACE:TABLENAME>... | -i <INPUT_FILE>...

选项：

-f, --fix：通过删除找到的所有额外区域来修复元数据。
-i,--inputFiles：接受命名空间或表名称的一个或多个输入文件。

它报告 hbase:meta 上存在但文件系统上没有相关目录的区域。 要求 hbase:meta 联机。 对于作为参数传递的每个表名称，它在 hbase:meta 中可用的区域和特定文件系统上的区域目录之间执行差异分析。如果它传递了 --fix 选项，则会从元数据中删除额外的区域。

注意

在决定使用 --fix 选项之前，有必要检查报告的额外区域是否与现有的有效区域重叠。如果重叠，那么 extraRegionsInMeta --fix 是最佳解决方案。否则，assigns 命令是更简单的解决方案。它会在文件系统中重新创建区域目录（如果不存在）。

此示例为默认命名空间下的 table_1 和命名空间 ns1 中的所有表触发额外区域报告：

hbase --config /etc/hbase/conf hbck -j ~/hbase-operator-tools/hbase-hbck2/target/hbase-hbck2-1.x.x-SNAPSHOT.jar extraRegionsInMeta default:table_1 ns1

此示例为默认命名空间下的 table_1 和命名空间 ns1 中的所有表触发额外区域报告，同时提供修复选项：

hbase --config /etc/hbase/conf hbck -j ~/hbase-operator-tools/hbase-hbck2/target/hbase-hbck2-1.x.x-SNAPSHOT.jar extraRegionsInMeta -f default:table_1 ns1

它返回作为参数传递的每个表或指定为参数的命名空间上的每个表的额外区域列表。如果指定了 -i or --inputFiles，则传递一个或多个输入文件名。每个文件都包含 <NAMESPACE|NAMESPACE:TABLENAME>，每行一个。例如：

hbase --config /etc/hbase/conf hbck -j ~/hbase-operator-tools/hbase-hbck2/target/hbase-hbck2-1.x.x-SNAPSHOT.jar extraRegionsInMeta -i fileName1 fileName2

fixMeta

注意

此选项不太适用于 HBase 2.1.6。不建议将其用于 2.1.6 HBase 群集。

在 hbase:meta 中对错误或不一致状态执行服务器端修复。 Master UI 有一个匹配的新 HBCK Report 选项卡，用于转储 catalogjanitor 的最近运行和新的 hbck chore 所生成的报告。

在进行任何其他修复之前，首先保持 hbase:meta 运行正常至关重要。 它修复了 holes 和 overlaps，在 HDFS 中创建（空）区域目录来匹配添加到 hbase:meta 的区域。

此命令与命名类似的旧 hbck1 命令不同。 它针对最后的 catalog_janitor 和 hbck chore 运行生成的报告。如果没有可修复的，则运行会循环。否则，如果 HBCK Report UI 报告了问题，则 fixMeta 运行会清除 hbase:meta 问题。

hbase --config /etc/hbase/conf hbck -j ~/hbase-operator-tools/hbase-hbck2/target/hbase-hbck2-1.x.x-SNAPSHOT.jar fixMeta

generateMissingTableDescriptorFile <NAMESPACE:TABLENAME>

此命令尝试通过生成缺少的表描述符文件来修复孤立表。如果表文件夹缺失或 .tableinfo 存在，则此命令不起作用。（我们不会替代现有的表描述符。）此命令首先检查 TableDescriptor 是否缓存在 HBase Master 中，如果在，它会相应地恢复 .tableinfo。如果 .tableinfo 未在 Master 中缓存，则它会创建包含以下项的默认 TableDescriptor 文件：

表名称。
基于文件系统确定的列族列表。
TableDescriptor 和 ColumnFamilyDescriptors 的默认属性。如果 .tableinfo 文件是使用默认参数生成的，请务必在稍后检查表或列族属性。（根据需要更改它们。）此方法不会更改 HBase 中的任何内容。它仅将新的 .tableinfo 文件写入文件系统。若要让孤立表（如 ServerCrashProcedures）保持稳定，你可能需要在生成缺少的表信息文件后修复错误。

hbase --config /etc/hbase/conf hbck -j ~/hbase-operator-tools/hbase-hbck2/target/hbase-hbck2-1.x.x-SNAPSHOT.jar generateMissingTableDescriptorFile namespace:table_name

replication [OPTIONS] [<NAMESPACE:TABLENAME>... | -i <INPUT_FILE>...]

选项：

-f, --fix：修复发现的任何复制问题。
-i,--inputFiles：接受表名称的一个或多个输入文件。

它会查找未删除的复制队列，如果它传递了 --fix 选项，则会将这些队列删除。它会传递表名来检查是否存在复制屏障，如果 --fix，则会进行清除。

hbase --config /etc/hbase/conf hbck -j ~/hbase-operator-tools/hbase-hbck2/target/hbase-hbck2-1.x.x-SNAPSHOT.jar replication namespace:table_name

如果指定了 -i or --inputFiles，则它会传递一个或多个输入文件名。每个文件都包含 <TABLENAME>，每行一个。例如：

hbase --config /etc/hbase/conf hbck -j ~/hbase-operator-tools/hbase-hbck2/target/hbase-hbck2-1.x.x-SNAPSHOT.jar replication -i fileName1 fileName2

setRegionState [<ENCODED_REGIONNAME> <STATE> | -i <INPUT_FILE>...]

选项：

-i,--inputFiles：接受编码区域名称和状态的一个或多个输入文件。

可能的区域状态：

OFFLINE
OPENING
OPEN
CLOSIN
CLOSED
SPLITTING
SPLIT
FAILED_OPEN
FAILED_CLOSE
MERGING
MERGED
SPLITTING_NEW
MERGING_NEW
ABNORMALLY_CLOSED

警告

此风险选项仅作为最后手段。

示例场景包括由于区域在 hbase:meta 中处于不一致状态而无法继续的取消分配或分配。例如，只有在以下状态之一传递区域时，才能继续执行 unassigns 命令：SPLITTING、SPLIT、MERGING、OPEN 或 CLOSING。

在使用此命令手动设置区域状态之前，请确认该区域未由正在运行的过程（如 assign 或 split）处理。可使用 list_procedures 命令查看 hbase shell 中正在运行的过程。以下示例将区域 de00010733901a05f5a2a3a382e27dd4 设置为 CLOSING：

hbase --config /etc/hbase/conf hbck -j ~/hbase-operator-tools/hbase-hbck2/target/hbase-hbck2-1.x.x-SNAPSHOT.jar setRegionState de00010733901a05f5a2a3a382e27dd4 CLOSING

如果区域状态发生更改，则返回 0，否则返回 1。如果指定了 -i or --inputFiles，则传递一个或多个输入文件名。每个文件都包含 <ENCODED_REGIONNAME> <STATE>，每行一对。例如：

hbase --config /etc/hbase/conf hbck -j ~/hbase-operator-tools/hbase-hbck2/target/hbase-hbck2-1.x.x-SNAPSHOT.jar setRegionState -i fileName1 fileName2

setTableState [<TABLENAME> <STATE> | -i <INPUT_FILE>...]

选项：

-i,--inputFiles：接受表名称和状态的一个或多个输入文件。

可能的表状态为 ENABLED、DISABLED、DISABLEING 和 ENABLEING。

若要读取当前表状态，请在 hbase shell 中运行：

hbase> get 'hbase:meta', '<TABLENAME>', 'table:state'

值 x08x00 == ENABLED、x08x01 == DISABLED 等。它还可在 shell 提示符中运行 describe <TABLENAME>。此示例使表名 user 处于 ENABLED 状态：

hbase --config /etc/hbase/conf hbck -j ~/hbase-operator-tools/hbase-hbck2/target/hbase-hbck2-1.x.x-SNAPSHOT.jar setTableState users ENABLED

它会返回上一个表状态（不管是什么）。如果指定了 -i or --inputFiles，则它会传递一个或多个输入文件名。每个文件都包含 <TABLENAME> <STATE>，每行一对。例如：

hbase --config /etc/hbase/conf hbck -j ~/hbase-operator-tools/hbase-hbck2/target/hbase-hbck2-1.x.x-SNAPSHOT.jar setTableState -i fileName1 fileName2

scheduleRecoveries <SERVERNAME>... | -i <INPUT_FILE>...

选项：

-i,--inputFiles：接受服务器名称的一个或多个输入文件。

为 RegionServers 的列表计划 ServerCrashProcedure(SCP)。将服务器名称的格式设置为 <HOSTNAME>,<PORT>,<STARTCODE>。（请参阅 HBase UI/日志。）

此示例使用 RegionServer a.example.org, 29100,1540348649479：

hbase --config /etc/hbase/conf hbck -j ~/hbase-operator-tools/hbase-hbck2/target/hbase-hbck2-1.x.x-SNAPSHOT.jar scheduleRecoveries a.example.org,29100,1540348649479

它会返回创建的 ServerCrashProcedures 的 PID，如果未创建过程，则返回 -1。（请参阅 Master 日志以了解原因。）HBase 版本 2.0.3、2.1.2、2.2.0 或更高版本中添加了命令支持。如果指定了 -i or --inputFiles，则它会传递一个或多个输入文件名。每个文件都包含 <SERVERNAME>，每行一个。例如：

hbase --config /etc/hbase/conf hbck -j ~/hbase-operator-tools/hbase-hbck2/target/hbase-hbck2-1.x.x-SNAPSHOT.jar scheduleRecoveries -i fileName1 fileName2

修复问题

此部分可帮助你对常见问题进行故障排除。

一般原则

进行修复时，在修复任何其他问题类型（例如文件系统偏差）之前，请先确保 hbase:meta 一致。按顺序放置 hbase:meta 后，应解决文件系统中的偏差或分配问题。如果 hbase:meta 出现问题，那么当 Master 采用孤立文件系统数据或进行区域分配时，它无法进行适当的放置。

如果某个区域处于 CLOSING 状态，则无法分配它（或相反地，如果它处于 OPEN 状态，则无法取消分配）除非先通过 CLOSED 进行转换。区域必须始终从 CLOSED 到 OPENING 到 OPEN，再到 CLOSING，然后 CLOSED。

进行修复时，一次修复一个表。

如果表为 DISABLED，则无法分配区域。在 Master 日志中，可以看到跳过了 Master 报告已跳过，因为表的状态为 DISABLED。你可以分配区域，因为它目前的状态是 OPENING，而你希望它处于 CLOSED 状态，使它与表的 DISABLED 状态一致。在这种情况下，可能需要暂时将表状态设置为 ENABLED，以便执行分配。然后，在取消分配语句后再次将其设置回去。 HBCK2 具有可进行此更改的功能。请查看 HBCK2 使用情况输出。

分配和取消分配

通常，在分配时，Master 会一直持续直到成功。分配对区域采用独占锁。该锁阻止了并发分配或取消分配的运行。针对锁定区域的分配会等到锁释放后才继续进行。

Master startup cannot progress, in holding-pattern until region online：

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

Master 无法继续启动，因为没有过程分配 hbase:meta（或 hbase:namespace）。若要注入一个，请使用 HBCK2 工具：

hbase --config /etc/hbase/conf hbck -j ~/hbase-operator-tools/hbase-hbck2/target/hbase-hbck2-1.x.x-SNAPSHOT.jar assigns -skip 1588230740

在此例中，1588230740 是 hbase:meta 区域的编码名称。传递 -skip 选项可停止 HBCK2 对远程 Master 执行版本检查。如果远程 Master 未启动，则版本检查会提示 Master is initializing response 或 PleaseHoldException，并删除分配尝试。 -skip 命令可避免版本检查并执行计划的分配。

hbase:namespace 系统表也可能发生这种情况。查找 hbase:namespace 区域的编码区域名称，并执行与 hbase:meta 类似的步骤。在后一种情况下，Master 实际上打印了一条有用的消息，与下例类似：

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

要为前面日志行中记下的 hbase:namespace 表计划分配：

hbase --config /etc/hbase/conf hbck -j ~/hbase-operator-tools/hbase-hbck2/target/hbase-hbck2-1.x.x-SNAPSHOT.jar -skip assigns 9559cf72b8e81e1291c626a8e781a6ae

传递命名空间区域的编码名称。（编码名称因部署而异。）

hbase:meta 区域/表还原/重新生成中的缺失区域

某些异常情况已从 hbase:meta 表中删除表区域。对这些案例的会审显示，它们是由操作员诱发的。用户针对 HBCK2 群集运行了过时的 HBCK1 OfflineMetaRepair 工具。 OfflineMetaRepair 是用于修复 HBase 1.x 版本上的 hbase:meta 表相关问题的一个知名工具。原始版本与 HBase 2.x 或更高版本不兼容，并且已经过一些调整。在极端情况下，现在可以通过 HBCK2 运行它。

在大多数情况下，hbase:meta 中最终会随机缺少区域，但 hbase 可能仍可正常运行。在这种情况下，可以使用 HBCK2 中的 addFsRegionsMissingInMeta 命令通过 Master 联机解决此问题。与后面介绍的完全 hbase:meta 重新生成相比，此命令对 hbase 的破坏更小。它甚至可用于恢复命名空间表区域。

hbase:meta 区域/表还原/重新生成中的额外区域

还有一些情况是，在文件系统中移除了表区域，但在 hbase:meta 表上仍然有相关条目。这可能是由于拆分问题、手动操作错误（例如手动删除或移动区域目录），甚至元信息丢失（如 HBASE-21843）导致的。

可以使用 HBCK2 中的 extraRegionsInMeta --fix 命令通过 Master 联机解决此类问题。与后面介绍的完全 hbase:meta 重新生成相比，此命令对 hbase 的破坏更小。在不支持 fixMeta HBCK2 选项的版本（任何低于 2.0.6、2.1.6、2.2.1、2.3.0 和 3.0.0 的版本）中发生此情况时，此方法也很有用。

联机 hbase:meta 重建配方

如果 hbase:meta 损坏不太严重，hbase 仍然能够使其联机。即使命名空间区域是缺失的区域之一，也可在初始化期间扫描 hbase:meta，此时 Master 正在等待分配命名空间。若要验证此情况，可以执行 hbase:meta 扫描命令。如果它未超时或显示任何错误，则 hbase:meta 是联机的：

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

如果消息不显示任何错误，则可以使用 HBCK2 addFsRegionsMissingInMeta。它会读取 FS 区域目录上可用的区域元数据信息，以在 hbase:meta 中重新创建区域。因为它可以在 hbase 部分运行的情况下运行，所以它会尝试禁用受报告的问题影响的联机表，并将区域重新添加到 hbase:meta。它可以对特定表或命名空间或来自所有命名空间的所有表执行检查。在此示例中，为默认命名空间中的表 tbl_1、命名空间 n1 中的 tbl_2 和命名空间 n2 中的所有表添加了缺失区域：

hbase --config /etc/hbase/conf hbck -j ~/hbase-operator-tools/hbase-hbck2/target/hbase-hbck2-1.x.x-SNAPSHOT.jar addFsRegionsMissingInMeta default:tbl_1 n1:tbl_2 n2

由于它独立于 Master 运行，成功完成后，需要执行更多步骤才能分配重新添加的区域。这些消息如下所示：

addFsRegionsMissingInMeta 输出包含已重新添加的所有区域的 assigns 命令。必须稍后执行此命令，因此为了方便起见，请复制并保存它。
对于 2.3.0 之前的 HBase 版本，在 addFsRegionsMissingInMeta 成功完成并保存输出后，请重启所有正在运行的 HBase Master。

在 Master 重启且 hbase:meta 已联机后（检查 Web UI 是否可访问），请从之前保存的 addFsRegionsMissingInMeta 输出运行 assigns 命令。

注意

如果命名空间区域是缺失的区域之一，则需要在返回的 assigns 命令的开头添加 --skip 标志。

如果群集遭受了严重的 hbase:meta 表丢失，可按照以下方案进行粗略的重建。概括地讲，我们将停止群集。运行 HBCK2 OfflineMetaRepair 工具，它可读取放入文件系统的目录和元数据，尽最大努力重建可行的 hbase:met 表。重启群集。注入分配以使系统命名空间表联机。最后，重新分配要启用的用户空间表。（重建的 hbase:meta 会创建一个表，所有表脱机且未分配任何区域。）

详细的重新生成方案

注意

仅将此选项作为最后手段。但我们不建议这样做。

停止群集。
从 HBCK2 运行 rebuild hbase:meta 命令。此命令将原始的 hbase:meta 放到一边，并放置一个重新生成的项。此示例演示如何运行该工具。它会添加 -details 标志，以便工具转储它在 HDFS 中找到的区域的信息：
```
hbase --config /etc/hbase/conf -j ~/hbase-operator-tools/hbase-hbck2/target/hbase-hbck2-1.x.x-SNAPSHOT.jar org.apache.hbase.hbck1.OfflineMetaRepair -details
```
设置群集。它不会完全启动。停滞的原因是命名空间表未联机，并且过程存储中没有针对这种偶然情况的分配过程。 HBase Master 日志显示了此状态。此示例展示了它记录的内容：
```
2019-07-10 18:30:51,090 WARN  [master/localhost:16000:becomeActiveMaster] master.HMaster: hbase:namespace,,1562808216225.725a0fe6c2c869d3d0a9ed82bfa80fa3. isn't online; state={725a0fe6c2c869d3d0a9ed82bfa80fa3 state=CLOSED, ts=1562808619952, server=null}; ServerCrashProcedures=false. Master startup can't progress, in holding-pattern until region onlined.
```
若要分配命名空间表区域，不能使用 shell。如果使用 shell，它将失败并出现 PleaseHoldException，因为 Master 尚未启动。（它正在等待命名空间表联机，然后声明自己“启动”。）必须使用 HBCK2 assigns 命令。若要进行分配，需要命名空间编码名称。它显示引用的日志中。在本例中就是 725a0fe6c2c869d3d0a9ed82bfa80fa3。必须传递 -skip 命令才能跳过 Master 版本检查。（如果没有它，HBCK2 调用会引发 PleaseHoldException，因为 Master 尚未启动。）此示例会添加命名空间表的分配：
```
hbase --config /etc/hbase/conf hbck -j ~/hbase-operator-tools/hbase-hbck2/target/hbase-hbck2-1.x.x-SNAPSHOT.jar -skip assigns 725a0fe6c2c869d3d0a9ed82bfa80fa3
```
如果调用与 Connection refused 一起返回，则 Master 是否已启动？如果 Master 无法自行初始化，它会在一段时间后关闭。重启群集/Master 并重新运行 assigns 命令。

分配成功运行后，你会看到它发出类似于以下示例的内容。末尾的 48 是分配过程计划的 PID。如果返回的 PID 为 -1，则表示 Master 启动进展不充分，需要重试。或者，编码的区域名称可能不正确，请检查此问题。

hbase --config /etc/hbase/conf hbck -j ~/hbase-operator-tools/hbase-hbck2/target/hbase-hbck2-1.x.x-SNAPSHOT.jar -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 sufpport check skipped
[48]

检查 Master 日志。 Master 应该已经启动。可以看到成功完成 (PID=48)。查找类似于此示例的行来验证 Master 启动是否成功：
```
master.HMaster: Master has completed initialization 132.515sec
```
可能需要一段时间才会显示。

重新生成 hbase:meta 会将用户表添加到 DISABLED 状态，将区域添加到 CLOSED 模式下。通过 shell 重新启用表，使所有表区域重新联机。逐个执行或使用启用所有的“.*”命令一次性启用所有表。

重新生成元缺少编辑，可能需要使用本文前面所述的工具进行后续修复和清理。

已删除引用文件、缺少 hbase.version 文件和文件损坏

HBCK2 可检查是否有挂起的引用和损坏的文件。你可以要求它将错误文件放在一边，可能需要执行此操作来克服区域不联机或读取失败问题。请查看 HBCK2 列表中的文件系统命令。传递一个或多个表名称（或者使用 none 检查所有表）。会报告错误文件。传递 --fix 选项进行修复。

过程重启

作为最后手段，如果 Master 不稳定，并且所有修复尝试都只能带来不可操作的锁或无法完成的过程，或者如果 MasterProcWALs 集合无限制地增长，则可以将 Master 状态擦除干净。将 HBase 安装下的 /hbase/MasterProcWALs/ 目录移到一边，然后重启 Master 进程。它会以表格格式返回，没有内存。

如果在擦除时，所有区域都已顺利分配或脱机，在 Master 重启时，Master 应该会继续执行，就像什么都没有发生一样。但是如果当前存在转换中的区域，那么操作员必须进行干预，使未完成的分配或取消分配操作完成。

按所述方法读取 hbase:meta info:state 列以确定需要分配或取消分配的内容。在通过将 MasterProcWALs 移到一边来擦除所有历史记录后，应该没有任何实体会锁定，所以你可以自由地进行批量分配或取消分配。

Compartir a través de