1、发现集群误删数据处理
与现场核实是否可以停止集群,建议立即停止集群,减少数据丢失数据。
2、第一时间检查Fsimage文件,确认是否存在可用于数据恢复的Fsimage文件。
最新checkpoint的元数据只有原来的1/4,故使用离当前时间点最近的fsimage816 来恢复数据。
3、若明确删除操作,且数据必须恢复。
需确认最早的fsimage replay 的最后一个editlog 时间点。
Ls -lrt //namenode/current/ | grep “最早fsimage的txid”| grep edits
查询该editlog以后一个txid的时间—timestamp
将editlog转为xml查看:
Hdfs oev -i edits*** -o edits***.xmls
确认最早的FsImage文件replay的最后一个editlog文件的时间,若晚于删除操作的时间,即最早的FsImage文件存储的元数据中,已经将数据删除,故最早的FsImage文件已经无法用于数据恢复。此时只能通过操作系统层面恢复删除的fsimage。
4、检查dn是否已存在大量数据删除
说明存储节点相关的block已经被大量删除,这些数据文件从平台层面已经无法恢复。若必须恢复,可以从操作系统层面,去恢复没有被覆写(overwrite)的硬盘(HDD)分区(sector)。
5、数据恢复
- namode所有节点的current目录元数据只保留—fsimage faimage.md5 Vesion文件。其余全部移走(可以保留删除操作id之后的editlog尽量恢复数据。)。
- journalnode数据清理:ambariUI修改数据目录或者所有jn节点数据目录清理掉edit文件。
- journalnode初始化:启动jourbalnode,在任意一台nn节点执行命令:sudo su ocdp -l -c ‘hdfs namenode -initializeSharedEdits’
4.ambariUI启动nn1,监控启动日志或hdfs 50070,提示退出安全模式
5.手动退出安全模式:hdfs dfsadmin -safemode forceExit
6.在nn2,nn3 节点上执行命令,拉取元数据
sudo su ocdc -l -c ‘hdfs namenode -bootstrapStandby’
7.拉取完成后,ambariUI启动nn2,nn3