删集群跑路

硬件：nn2台，ha架构，每台96g内存，3块4t硬盘，千兆网卡。dn32台，每台192g内存，13块4t硬盘，万兆网卡。
软件：hadoop2.6，hive2.0，spark1.5，filebeat+flume+kafka+azkaban

        公司起初就12台服务器，配置比较低，随着业务发展，数据量增多，入职至今的两年时间里公司做过很多硬件方面的升级，比如挂过盘，添过内存，升级过万兆网卡，买过更多的服务器，逐渐形成了30多台的规模，另外公司还有10多台服务器随时可以加入到集群内。由于集群机器越来越多，管理起来也越来越不方便，所以曾想搭建ambari来管理，但考虑到缺这方面的人才，工具太傻瓜，底层的东西不了解，出了问题我们更难解决，所以还是只能维持现状，由业余人员人肉监控维护。最近公司nn老是出些莫名的问题，比如网络问题，磁盘问题等等。。猜测可能是机器老化比较严重，运维也建议把nn机器从集群下掉，所以就需要把nn迁到新机器，然后杯具出现了，从删库到跑路。。。

       前两天8、9点早上起来看公司内部的报表邮件，发现没有数据，自己家里又没电脑，于是就问同事a是不是日志采集有问题。同事a跟我讲他昨晚测试迁移nn，搞到现在才回家，迁移很成功，用的冷迁移，停掉nn，scp目录文件到新机器搞得，然后迁移回去出问题了，有台dn死活起不来，因为集群副本数是2，所以问题不太大，一个人太困就回家了，让我到公司也看下这个问题，我想同事a真厉害，一个人就搞定了nn迁移。

        到了公司一看，50070页面上2000多万个块丢失，自己拿计算器算了下，一个块最大128m，这么说最多丢了2、30t的数据？接着看了下同事a说的dn，确实没有启动起来，看了下log，说是存储已被另外的nn占用。之前也遇到块丢失的情况，所以感觉问题不大，况且我俩副本，起不来，大不了我这台机器不要了行吧，丢数据也应该丢不了多少。另外一位同事b说找到问题了，问题dn机器挂盘挂错了，我一看还真是，把一块盘挂到了俩不同的数据目录上了，于是乎就改了配置文件，删掉了其中一个数据目录，这台dn终于启动了，到50070页面一看，还是丢2000多万块，比之前少了一丢丢。这咋回事儿，不行啊，俩副本怎么可能出现这种情况，解铃还须系铃人，总监call我同事a回来，同事a讲他也没改啥东西啊。之后总监a微信请教之前的同事，总监b电话请教自己的朋友，老板也举荐数据大牛。总监b的朋友说我们这种迁移方式不太对，应该在俩nn的基础上再加个nn，等集群稳定了再下掉老nn，这样比较稳妥，我们这儿的情况太极端，他也没有遇到过，唯一的建议是让我们把nn内存调大些。

        问题解决不了咋办，按照惯例删掉这些元数据吧，让集群跑起来重要，之前也是这么干的嘛。说干就干，删了一宿，最后剩下3条死活删不了，既然删不了就留下做个纪念吧，纪念这个屈指可数的通宵。凌晨0点多见证奇迹的时刻到了，重启集群，成功了！总监a，同事a，同事b，我欢呼雀跃，终于解决了个大问题啊。同事a说看下集群资源利用率吧，我打开50070的datanode页面，怎么感觉有些异样啊，之前磁盘利用率在80%多啊，现在怎么变20%不到了，接着看dn的总容量不到10个T，我说磁盘是不是少挂了，怎么好像只挂了三块盘。总监a说会不会是运维弄的？同事a看了下配置文件，发现hdfs-site配置文件分发错了，把nn的分发到dn上了，我们nn和dn是异构的啊，每台dn少配了10块盘。这真是晴天霹雳！我们一直都定位错问题了，四个人居然删了半天的元数据。

        怎么办！总监a说，先保证线上的任务吧，把集群跑起来，跑了俩小时发现根本不可行，数据都丢了，哪还能再跑出数据呢！我问同事a，做数据迁移的机器上还有元数据吧，我们尝试恢复下吧。于是四个人到了小屋里，各自分工，把每步操作都写到墙上，生怕再来个失误，彻底毁掉公司的数据。搞了几十分钟，最后启动集群，大家都抱着一丝丝希望，可现实就是这么残酷，报错了，因为ha集群是用jn的editlog和nn的fsimage合并的，我们跑了好多任务，元数据已经有gap了。于是乎各种百度，其中有一个回答说recover命令能恢复，我说试试，大家说别，因为不知道行不行，百度上面的都是自己测的，生产环境我们不能犯二次错误了。这种方案被pass了。我说要不去掉ha吧，用一台nn启动集群，总监a也说可以试试，让集群伪装成一个nn，不去合并jn上的editlog。可是同事a说不行，就算干到天明也不一定能弄好，况且ha这个东西牵扯到好多东西。这种方案不行怎么办？总监a咨询同事a，同事a说还弄回去吧，数据丢了再加工回来，之前也发生过这种问题。我说之前丢的数据少可以这么搞，现在这么多，没办法向老板交代啊，我建议维持现状，等到天明让老板找大牛来解决这个元数据gap的问题，因为这样保证丢的数据最少，只会丢一两天的数。同事a说就算老板找来了大牛，这种问题谁也不敢解决。想想也是。总监a拍板说按照同事a的方案来，让集群跑起来，数丢了再补。

        天快亮了，打扫卫生的过来，一脸懵，笑着说，你们干了一晚上啊，我们哪里还有心思陪笑。最后总监a让我们大家回去休息，他向老板交代问题。好吧，24小时不眠不休，4个人合力把公司的数据搞没了，竟然是这种结果。走出公司门口，看到新买的小车子淋了一夜的雨，莫名有点小心疼。我显然不适合骑车回家了，选择坐公交吧。在车上摇摇晃晃的，总有种自己要挂的感觉，下了车逆着人流回家，感觉自己像另一个世界的人。到家了倒头便睡，衣服也没脱，真希望醒过来，过去的只是一场梦。

        目前，只能亡羊补牢了。总结下吧，还是自己缺乏经验，其实之前也出过同样的问题，也是看50070发现的，之后完美解决。这次同事a说dn起不来，都还以为是dn的问题，一条路走到黑了。删库跑路这种经历恐怕很难再遇了，一次足矣。

ps:出了这么大的问题，好多部门都停摆了，总监a说这下老板们知道我们的重要性了吧，公司是不能没有我们的，要把这次恢复过程弄成项目，向公司申请项目奖！我们服了。后续同事a咨询了百度的朋友，清空了未挂的磁盘，把与系统共用且资源利用率高的盘数据直接拷贝到空磁盘，改hdfs-site后可识别使用，有得有失。but同事b又rm -rf误删了一块数据盘，我调侃说你们是不是已经找好下家了？这么玩儿！然后大家乐了，都认为这话很精辟！

hadoop fsck /user/hive/warehouse/ods.db/ods_jz_post_hourly/part-m-00001 -files -locations -blocks -racks