Hadoop 集群迁移历程 心得体会（一）

技术探讨联系方式：QQ:272428027

由于本人第一次写博客，不喜勿喷，本文章内容只是一个hadoop迁移的心得体会，具体技术问题会在另一篇博客当中详细给出。
本周重点工作就是Hadoop集群迁移，迁移过程中的各种坑都已经一一解决，在踩坑的过程中对于Hadoop的架构，元数据的存储，配置文件的组织等等都有进一步的了解，本周的心得有必要分享一下：
刚开始接到Hadoop迁移这个任务的时候自己心里是没有底气的，因为自我感觉这项任务要比重新搭建一个新集群更有挑战，一开始自己制订了两套技术方案。一、集群整体克隆 二、重新搭建新集群，然后数据一一迁移。第一套方案一旦成功，数据迁移就会很轻松的完成，第二套方案肯定能成功，但是比较麻烦，为了省事，果断先试试第一种方案，有句话说得好：“万一一不小心就成功了呢”。集群克隆以后发现各种遗留的配置信息导致集群根本就没法正常启动，还有各种莫名奇妙的问题，甚至克隆集群有些自启动的进程依然回去请求原来的集群导致老集群也运行异常，影响线上集群这可就吓死宝宝了，由于自己也不知道问题出在哪里，只能先把机器关闭，后来自己通过端口排查，竟然发现有一个很难发现的进程在跟线上集群通信，kill 线程问题就解决了。
接下来就是存在数据库里面的配置信息修改，刚开始自己都不知道这里面设计到几个数据库，几个数据库里面有几张表，自己根本就无从下手，主要是因为自己不了解CDH的配置原理，一旦有一条记录弄错，就有可能导致机毁人亡，重新再来，谨慎再谨慎，从网上找了好多资料发现有用的库有两个，一个是ClouderManager 集群、监控等等配置信息，另一个就是hive源数据表metastrore数据库，库明确了，再就是表，首先到网上查没一张表存储的内容以及每个字段的含义，配置信息可能设计那几张表，刚开始手动修改，后来索性就全down下来，文件批量修改，然后在导入到mysql，好久没用mysql了，基本的命令还需要重新拾起，特别是每次遇到每次头痛的远程登陆权限问题，又加上网络的各种限制，mysql远程登陆只能试了一边又一遍，因为自己根本就不确定是自己配置的问题还是网络的问题，还好这些问题都统统干掉了。Hadoop元数据修改也就告一段落了。
走到这里，集群应该已经可以病殃殃的起来了，不过很不健康，各种监控报警，接下来就要一一解决这些告警，印象最深的就是ntp时间服务器异常，按照网上资料跟以往经验感觉ntp配置是没有问题的，但就是不能通过检测，这个问题困扰了两天，后来看到有一个命令是这样的“ntpdc -xx loopxxx”，一看到loop 我就联想到轮询自检，会不会是localhost主机映射搞错了，然后在/etc/hosts里面配置了127.0.0.1 localhost映射，我的天啊，bug就这样解决了，困扰了两天，这个纯属巧合，踩了狗屎。至于解决告警还有很多坑就不一一列举，方法可谓是卑鄙下流，无所不用啊。。。。。
接下来就到了Hive了，启动hive，报错，找不到hdfs服务，找不到hdfs服务，给出的节点信息竟然是原来的namenode，这个就简单了，肯定是那个配置没有改过来，找了两天，整整两天啊终于找到了，就一个配置，差点让我放弃了，原因很简单，就是自己在本地配置了一个url覆盖了CDH自己的配置信息，真是天坑，欢天喜地的来到hive cli，运行一个简单查询没啥问题，恩，很开心，接着来一个一个复杂的，突然发现跑不出结果，看日志，结果网络不允许，网上找了半天也没有找到结果，最终发现是hadoop的一个bug，需要重新修改源代码打包覆盖，但是苦于没有修改class文件的过人本事，这个问题迟迟不能解决，困了两天，又两天啊，要放弃了。眯了一小会，突然想到，hadoop报错是因为空指针导致的异常，为什么不绕过去，让他不报空指针错误呢？然后就跟踪了一下源码，自我感觉是因为一个配置没找到导致的，然后赶紧去找这个配置项应该出现在那个配置文件里面，系统有几个这样的配置文件，全都翻出来，结果出乎意料，真的又一个历史配置还是线上集群的信息，长舒一口气，这个问题又要解决了，验证了一下，果然没错。就在下班前，任务算是圆满解决，整整一周。
自我感觉本周最大的收获就是排查问题的能力有所进步，每次想放弃的时候总会有惊喜，每次面对问题迷茫，徘徊过后都会有不一样的收获，苦逼的一周，收获满满的一周。

技术探讨联系方式：QQ:272428027