Hbck 修复问题

问题修复

一般原则

进行修复时，请先确保 hbase:meta 一致，然后再着手修复任何其他问题类型，例如文件系统偏差。 文件系统中的偏差或分配问题应在 hbase:meta 整理后解决。 如果 hbase:meta 出现问题，Master 在采用孤立文件系统数据或进行区域分配时无法进行正确的放置。

要记住的其他一般原则包括如果区域处于 CLOSING 状态（或相反，如果处于 OPENING 状态，则未分配），如果没有首先通过 CLOSED 进行转换，则无法分配区域：区域必须始终从 CLOSED 移动到 OPENING，再到 OPEN， 然后到 CLOSING，CLOSED。

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

此外，如果表已禁用，则无法分配区域。 在 Master 日志中，您会看到 Master 会报告由于表已禁用，因此已跳过分配。 您可能想要分配一个区域，因为它当前处于 OPENING 状态并且您希望它处于 CLOSED 状态，因此它与表的 DISABLED 状态一致。 在这种情况下，您可能必须暂时将表状态设置为 ENABLED，以便您可以进行分配，然后在取消分配后再次将其设置回来。 HBCK2 具有允许您执行此操作的功能。 请参阅 HBCK2 使用输出。

以下是迄今为止运行 hbase-2.x 的经验的混合注释和处方。 导致下面描述的状态的根本问题已在更高版本的 hbase 中修复，因此请尽可能升级以避免描述的情况

分配/取消分配
通常，在分配时，Master 会一直持续到成功。 分配对区域进行排他锁。 这会阻止并发分配或取消分配运行。 针对锁定区域的分配将等到锁定释放后再进行。 有关当前未完成锁的列表，请参阅上面的 [Procedures & Locks] 部分。

主启动无法进行，在保持模式直到区域在线
这不应该发生。 如果是这样，它看起来像这样：

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 无法继续启动，因为没有分配 hbase:meta（或 hbase:namespace）的过程。 要注入一个，请使用 HBCK2 工具：

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

…其中 1588230740 是 hbase:meta 区域的编码名称。 传递“-skip”选项以停止 HBCK2 对远程主机进行版本检查。 如果远程主机未启动，版本检查将提示“主机正在初始化响应”或“请保持异常”并放弃分配尝试。 ‘-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. 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 表安排分配，您可以：

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

…传递命名空间区域的编码名称（每次部署的编码名称会有所不同）。

hbase 中缺少区域：元区域/表恢复/重建
有一些不寻常的情况是从 hbase:meta 表中删除了表区域。 对此类案例的一些分类显示这些是操作员引起的。 用户已针对 HBCK2 集群运行过时的 hbck1 OfflineMetaRepair 工具。 OfflineMetaRepair 是一个众所周知的工具，用于修复 HBase 1.x 版本上与 hbase:meta 表相关的问题。 原来的版本不兼容HBase 2.x或更高版本，经过一些调整，到了极点，现在可以通过HBCK2运行了。

在大多数情况下，hbase:meta 中的区域最终会随机丢失，但 hbase 可能仍然可以运行。 在这种情况下，可以使用 HBCK2 中的 addFsRegionsMissingInMeta 命令在线解决问题。 与稍后介绍的完整 hbase:meta 重建相比，此命令对 hbase 的破坏性较小，甚至可以用于恢复命名空间表区域。

hbase 中的额外区域：元区域/表恢复/重建
在某些情况下，表区域已被文件系统删除，但在 hbase:meta 表上仍有相关条目。 这可能是由于拆分问题、手动操作错误（如手动删除/移动区域目录），甚至是 HBASE-21843 等元信息数据丢失问题。

此类问题可以通过在线 Master 解决，使用 HBCK2 中的 extraRegionsInMeta –fix 命令。 与稍后介绍的完整 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”中的所有表添加缺失区域：

$ HBCK2 addFsRegionsMissingInMeta default:tbl_1 n1:tbl_2 n2

由于它独立于 Master 运行，一旦它成功完成，需要额外的步骤来实际分配重新添加的区域。 下面列出了这些：

addFsRegionsMissingInMeta 输出一个分配命令，其中包含重新添加的所有区域。 该命令需要稍后执行，所以为了方便复制并保存。

对于 2.3.0 之前的 HBase 版本，在 addFsRegionsMissingInMeta 成功完成并保存输出后，重新启动所有正在运行的 HBase Master。

一旦 Master 重新启动并且 hbase:meta 已经在线（检查 Web UI 是否可访问），从 #1 中的指令保存的 addFsRegionsMissingInMeta 输出中运行 assigns 命令。
注意：如果命名空间区域在缺失区域中，则需要在返回的 assigns 命令的开头添加 –skip 标志。

如果集群遭受 hbase:meta 表的灾难性丢失，可以使用以下方法进行粗略的重建。 概括地说，我们停止集群； 运行 HBCK2 OfflineMetaRepair 工具，该工具读取放入文件系统的目录和元数据，尽最大努力重建可行的 hbase:meta 表； 重启你的集群； 注入分配以使系统命名空间表联机； 最后，重新分配您希望启用的用户空间表（重建的 hbase:meta 创建一个表，其中所有表脱机且未分配区域）。

详细的重建方法

停止集群。

从 HBCK2 运行重建 hbase:meta 命令。 这将移开原来的 hbase:meta 并放置一个新重建的。 以下是如何运行该工具的示例。 它添加了 -details 标志，因此该工具转储其在 hdfs 中找到的区域的信息：

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

启动集群。 它不会完全出现。 它将被卡住，因为命名空间表不在线并且过程存储中没有为此意外事件分配过程。 hbase 主日志将显示此状态。 这是它将记录的示例：

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.

要分配命名空间表区域，您不能使用 shell。 如果您使用 shell，它将失败并返回 PleaseHoldException，因为 master 尚未启动（它正在等待命名空间表在它声明自己“启动”之前上线）。 您必须使用 HBCK2 分配命令。 要分配，您将需要命名空间编码的名称。 它显示在上面引用的日志中：即 725a0fe6c2c869d3d0a9ed82bfa80fa3 在这种情况下。 您还必须通过 -skip 命令“跳过”主版本检查（没有它，您的 HBCK2 调用也会引发上述 PleaseHoldException，因为主版本尚未启动）。 这是一个添加命名空间表分配的示例：

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

如果调用返回“连接被拒绝”，那么 Master 起来了吗？ 如果 Master 无法初始化，它将在一段时间后关闭。 只需重新启动集群/主服务器并重新运行上述分配命令。

当分配成功运行时，您会看到它发出以下内容。 末尾的“48”是分配过程计划的 pid。 如果返回的 pid 是“-1”，那么主启动还没有充分进行……重试。 或者，编码的区域名称不正确。 查看。

$  HBASE_CLASSPATH_PREFIX=~/checkouts/hbase-operator-tools/hbase-hbck2/target/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

检查master日志。 master应该启动了。 您将看到 pid=48 成功完成。 寻找这样的行来验证成功启动master：

master.HMaster: Master has completed initialization 132.515sec

可能需要一段时间才能出现。

hbase:meta 的重建添加了处于 DISABLED 状态的用户表和处于 CLOSED 模式的区域。 通过 shell 重新启用表以使所有表区域重新联机。 一次做一个或查看 enable_all “.*” 命令一次性启用所有表。

重建元数据可能会丢失编辑，并且可能需要使用本自述文件中上方概述的工具进行后续修复和清理。

删除参考文件、丢失的 hbase.version 文件和损坏的 hfile
HBCK2 可以检查挂起的引用和损坏的 hfile。 您可以要求它排除错误文件，这些文件可能需要克服区域不在线或读取失败的驼峰。 请参阅 HBCK2 列表中的文件系统命令。 传递一个或多个表名（或“无”以检查所有表）。 它会报告坏文件。 通过 –fix 选项来进行修复。

程序重启
在极端情况下，作为最后的资源，如果 Master 心烦意乱，并且所有修复尝试只出现无法完成的锁或过程，和/或 MasterProcWAL 集无限制地增长，则可以擦除 Master state。 只需将 hbase 安装下的 /hbase/MasterProcWALs/ 目录移到一边，然后重新启动 Master 进程。 它会以空白的形式回归。

如果在擦除时，所有 Region 都被愉快地分配或脱机，那么在 Master 重启时，Master 应该接起并继续，就好像什么都没发生一样。 但是，如果当时有 Regions-In-Transition，那么运营商将不得不进行干预，以将未完成的分配/取消分配带到他们的终点。 阅读如上所述的 hbase:meta info:state 列，以了解需要分配/取消分配的内容。 删除 MasterProcWAL 的所有历史记录后，不应锁定任何实体，因此您可以自由批量分配/取消分配。

采用孤立数据
有关如何修复“HBCK Chore”报告的孤立区域，请参阅参考指南“采用”杂散数据中完整批量加载工具的高级部分。

本文为从大数据到人工智能博主「xiaozhch5」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。

原文链接：https://lrting.top/backend/3566/