大数据高可用系列--kudu高可用应急方案
1 设置机架感知
1.1 前置说明
1.9版本后的kudu已经支持机架感知（cdh6之后的版本中的kudu已支持），由于kudu的每个Tablet一般是三副本，一个leader两个flower， 且随机分布在不通数据节点；要想实现完全的跨机房高可用，则需要三个机房（对应三个机架），若2个机房的话，挂掉一个机房后，若有2个副本 （不论是两个flower或者一个flower一个leader）此tablet都无法自动回复三副本；当然只有一个副本的时候也可以通过命令来恢复 （不过若剩下的副本非leader，则有一定的数据丢失风险，flower未完全同步leader数据的情况下）
1.2 调整机架
根据实际情况，数据节点机架与机房保持一致即可（一个机房一个机架）
1.3 kudu rebalancer
进入cm页面 kudu服务，点击Run Kudu Rebalancer Tool进行自动均衡
均衡后观察Tablet的副本分布，发现已经均衡分布
2 高可用恢复
若数据已经分布在三个机房的机架，挂掉一个机房的多台主机，自动做个rebalancer即可，若为2个机房，停掉2台会涉及tablet挂掉2个副本的情况， 此时无法选主，无法rebalancer自动恢复，此时需要手动修复
2.1 获取异常tablet
sudo -u kudu kudu cluster ksck cdh1,cdh2,cdh3 获取异常的Tablet id，以及对应RUNNING状态的节点及其ID
2.2 修复Tablet
sudo -u kudu kudu remote_replica unsafe_change_config <tserver_address> <tablet_id> <peer uuids> * tserver_address：可用副本所在的tserver（cdh2:7050） * tablet_id：非健康的tablet * peer uuids：可用副本所在的tserver的uuid 举例： sudo -u kudu kudu remote_replica unsafe_change_config cdh2:7050 7fef9bf5de2b4cad93f88c94689dfb68 b58a7ccb60b84623a3614b61b26f10ec 此命令无法修复leader已经挂掉（且挂掉了半数）的tablet
2.3 批量修复Tablet
如果有问题的tablet非常多，可以参考如下命令：
$ kudu cluster ksck localhost|grep -e '^Tablet '|awk '{print $2}'|xargs -i echo "sudo -u kudu kudu remote_replica
unsafe_change_config cdh2:7050 {} <cdh2-uuid>"
上面命令可批量获取异常的tablet id并生成批量、修复命令3 集群监控检查
修复工作完成后，执行如下命令，发现无异常tablet，及修复完成 sudo -u kudu kudu cluster ksck cdh1,cdh2,cdh3 此时可以观察任务运行是否恢复正常
