我正在努力恢复。我已经备份了namenode和journal节点元数据。它包含编辑日志和图像。
我的系统中有两个NN。我定期备份两个nns上的元数据（hdfs元数据和qjm元数据）。我想在最坏的情况下测试恢复过程。假设nns和journal节点都已关闭，元数据已完全删除。
我想从备份中恢复nn元数据并启动nn。我知道可能会丢失数据，因为备份后所做的最新更改将丢失。
问题：
你认为这种情况可能/可行吗？
我面临一些与txn id不匹配，承诺txn id有关的问题。请告诉我是否有相同的解决方案。
尝试的步骤：
对nn和qjm进行元数据备份。执行一些hdfs文件操作（创建新文件）。
停止两台机器上的nn和journal节点。
从/data/hdfs和journal目录中删除元数据。
从备份中还原fsimages（返回一段时间）。
启动nn。它失败了，但有以下例外。
替代方法：将所有编辑日志和fsimage恢复到hdfs和qjm目录，然后启动nn，但仍然失败。
两个国家队都倒下了，我提不上来。我不想格式化hdfs，因为它会更改集群id，备份将不可用。
例外情况：
编辑日志中似乎有一个间隙。我们期望得到TXID71453，但得到了TXID71466
客户端尝试将承诺的txid从71599向后移动到71453
所需日志的recoverunfinalizedsegments失败。决定将日志同步到starttxid:71453，但记录器10.204.64.26:8485发现txid 71599已提交
3条答案
按热度按时间s5a0g9ez1#
可以在启用恢复标志的情况下启动namenode。namenode recover将处理损坏的maetadata。
kqlmhetl2#
由于最新的fsimage和edit已丢失或损坏，您应该尝试恢复元数据
./bin/hadoop namenode -recover请参阅：用于hadoop分布式文件系统的namenode恢复工具因为日志与namenode不同步，所以应该重新创建它
./bin/hdfs namenode -initializeSharedEdits因为恢复的fsimage丢失了自上次备份以来更新的最新数据，所以应该检查并删除损坏的数据./bin/hadoop fsck -delete /如果不执行fsck，namenode可能会因太多无响应的块而卡在安全模式下。xmakbtuz3#
启动所有日志节点。确保已复制fsimage、fsimage.md5和版本文件。然后运行hdfs namenode-initializesharededits-force，它将只格式化journalnode。然后启动namenode（1）。应该有用。如果不行，就告诉我。