由于hbase集群的namenode所在机柜需要尽快让出，因此需迁移namenode，旧nn的ip是0.238，新的ip是0.249，249服务器是之前老hbase集群的一个数据节点，由于基于hbase的应用的写入操作均是先写redis队列，再异步写hbase，并且我在停止hbase集群服务时不会停止zookeeper（zk停止服务后，client端重试机制会导致一个请求超过几十秒的等待），因此可以允许短暂的hbase服务停止，不会影响带来收入的充值业务，以下记录了整个迁移过程：
1、环境准备
1）创建hadoop用户（之前的hbase集群的root用户），并且把存放数据的/data/hdfs目录的所属用户给hadoop用户：chown -R hadoop:hadoop /data/hdfs，删除之前的内容
2）修改主机名与旧nn服务器的主机名称一样，注意如果配置有dns服务则主机名称不能相同，目前没有配置因此可以如此做，主机名称保持相同，可以只用修改hosts对应的ip地址即可，不用修改hadoop、hbase等相关的nn服务器的域名，修改后重启服务器
3）从旧nn上copy hosts的内容到新nn上，并nn对应的ip改为新nn的ip
4）配置ssh，端口与其它节点保持一致，改为2222，生成ssh钥匙对，并编辑authorized_keys文件，把snn和新nn的公钥均放置其中，并对该文件赋予600的权限：chmod 600 ~/.ssh/authorized_keys
5）删除之前安装的jdk版本，重新安装于其它节点相同的jdk
2、配置新nn服务器的hadoop
1）从旧nn服务器拷贝hadoop文件到新nn，保持目录结构相同
2）配置hadoop用户的环境变量：vi /home/hadoop/.bash_profile，配置java、hadoop的home和path
3）删除hadoop目录下的tmp、logs文件内容
4）检查core-site.xml、hdfs-site.xml、masters、slaves、hadoop-env.sh文件的配置，如果不合理，此时可以借机修改
3、配置新nn服务器的hbase
1）从旧nn服务器拷贝hbase文件到新nn，保持目录结构相同
2）配置hadoop用户的环境变量：vi /home/hadoop/.bash_profile，配置hbase的home和path
3）删除hbase目录下的tmp、logs文件内容
4）检查hbase-site.xml、hbase-env.sh、regionservers文件的配置，如果不合理，此时可以借机修改
4、检查hadoop和hbase的所有节点的配置文件，如果有不合理的地方，可以借此重启的机会修改，注意就nn也需要修改，万一迁移失败要回滚还需要启动旧nn
5、提前准备好计划执行的命令：
1）停止hbase（在旧nn服务器上执行）：hbase-daemons.sh stop regionserver hbase-daemon.sh stop master，停止nn服务器的zk：hbase-daemon.sh stop zookeeper（由于之前负责hbase的同事配置了4个zk，因此可以停止nn的zk，只需要其它三个即可）
2）停止hdfs（在旧nn服务器上执行）: stop-dfs.sh stop-mapred.sh，由于之前维护hbase的同学对hbase进行了扩容，但是扩容时没有修改把其它节点的slaves文件里添加新节点的主机名称，因此导致stop时遗留了一台服务器，可以手动kill
3）Copy nn的元数据目录到新nn服务器：
在旧nn上执行：
scp -P 33312 -r /data/hdfs/dfs/name Wang_Neng@192.168.0.249:/tmp/hadoop_name
在新nn上执行（注意：需提前打开一个root用户登录的新nn服务器终端，以便执行如下命令）：
mv /tmp/hadoop_name/* /data/hdfs/dfs/name/
chown -R hadoop:hadoop /data/hdfs/
4）启动hdfs（在新nn上执行）：start-dfs.sh
5）启动hbase（在新nn上执行）：
hbase-daemon.sh start master
hbase-daemons.sh start regionserver
6、打开一个新的xshell终端，在该终端中打开所有的hbase集群的节点（除旧nn），以root用户登录，打开每个服务器的hosts文件，vi编辑，把旧nn的ip换成新nn的ip，修改完后，先不保存，等停止hadoop、hbase后再保存，避免对停止服务器产生影响
7、打开一个新的xshell终端，在该终端中打开所有的hbase集群的节点(除旧nn)，以hadoop用户登录，打开每个服务器的/home/hadoop/.ssh/authorized_keys文件，vi编辑，把旧nn的ssh公钥换成新nn的公钥，修改完后，先不保存，等停止hadoop、hbase后再保存，避免对停止服务器产生影响
8、准备工作准备完后按照步骤5的子步骤进行操作，当执行完3）步后，一定要检查一下新nn的元数据文件大小是否正确，确保无误，然后保存第6步骤修改的host，保存第7步骤修改的ssh文件，并且需要手动在新snn上ssh访问一下snn和数据节点，否则会导致启动hdfs时出现ssh问题
9、启动hdfs
10、启动hbase的master、regionserver
11、在停止hbase服务后需在启动hbase前完成hbase客户端应用所在服务器的hosts文件的修改，该工作需要其他同事支持，并行操作
12、修改nginx配置，把hbase的master监控页面的server修改为新nn的ip，自此迁移完成。
注意：迁移前需先进行迁移演练，在迁移前准备好需要执行的脚步、配置文件等，并做好迁移失败的准备。
后记：本计划2分钟完成，实际上花了12分钟，究其原因，有两点：
1、高估了操作的速度，和停止、启动hbase、hdfs的时间
2、过于乐观或者经验不足，在迁移的过程中遇到了一些问题，一一呈列如下：
a)原hbase维护者在扩容时，相关配置没有修改彻底，导致无法在nn节点停止扩容的数据节点，花了时间查问题、手动kill、并完善配置 ----------迁移前应该彻底检查每台服务器的所有配置，尤其是nn的每个配置
b)ssh配置好后，必须先手动访问，并选择yes，把访问记录添加到known_hosts中，避免多次启动--------线上业务分秒必争
c)拷贝元数据时，由于在第5步提前准备命令时在新nn服务器上产生了临时的元数据，迁移前忘了清除，导致在迁移过程中copy元数据出现覆盖提示，为确保万无一失，删除后又进行了重copy，随着迁移的时间推移，各种应用开始报警，在高度紧张的情况下出现了一次copy错误，总共copy了三次元数据 ---------迁移前一定要检查每一个环节是否到位，最好在迁移前再按照事前准备的步骤推演一次
d)有一个节点的配置文件配置错了，不符合xml格式，导致启动失败，其实这个问题是在配置完nginx可以看到hbase监控页面后才发现有一个节点没有起来，发现时已经是几分钟之后了，在启动时居然没有发现有一个节点没有起来，呵呵，过于紧张，没办法，在我们公司hbase是提供在线核心数据服务的数据库，很多关键业务均依赖它 ---------没有配置文件管理工具则只能细致又细致。
还好，除了迁移时间长一些，没有其它问题，由于写是先写redis队列，部分业务的读是先读redis，因此对收入没有影响，对用户体验略有影响，其实如果不着急，应该在半夜业务低峰时处理最好，当然如果那样则会有一堆人陪我熬夜了，嘿嘿。
评论