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
