HBase滚动重启脚本为何先停止所有HMaster服务？

我查看了$HBASE_HOME/bin目录下的rolling-restart.sh脚本，发现该脚本会先停止所有HMaster服务（包括备用节点），之后再统一重启：

# The content of rolling-restart.sh
...
# stop all masters before re-start to avoid races for master znode
"$bin"/hbase-daemon.sh --config "${HBASE_CONF_DIR}" stop master
"$bin"/hbase-daemons.sh --config "${HBASE_CONF_DIR}" \
  --hosts "${HBASE_BACKUP_MASTERS}" stop master-backup

# make sure the master znode has been deleted before continuing
zmaster=`$bin/hbase org.apache.hadoop.hbase.util.HBaseConfTool zookeeper.znode.master`
...

# all masters are down, now restart
"$bin"/hbase-daemon.sh --config "${HBASE_CONF_DIR}" ${START_CMD_DIST_MODE} master
"$bin"/hbase-daemons.sh --config "${HBASE_CONF_DIR}" \
  --hosts "${HBASE_BACKUP_MASTERS}" ${START_CMD_DIST_MODE} master-backup

这种方式会导致这段时间HMaster服务完全不可用。你提出的分步重启流程确实更优雅：

1. 停止备用HMaster并重启它
2. 停止活跃HMaster，此时备用HMaster会自动晋升为活跃节点
3. 启动原活跃HMaster，使其成为新的备用节点

原脚本设计的原因 #

原脚本注释明确提到avoid races for master znode，这是核心考量：在早期HBase版本中，主节点选举的ZooKeeper节点处理逻辑不够健壮，如果采用分步重启，可能出现多个节点同时抢占Master ZNode的情况，引发选举冲突、脑裂，甚至长时间无法选出可用主节点的问题。原脚本通过一次性停掉所有主节点，再统一启动，避免了复杂的状态校验和竞争场景，简化了脚本实现。

你的方案的优势与注意细节 #

你的方案在现代HBase版本（2.x及以上）中是完全可行的，且能保证集群始终有可用的HMaster，避免服务中断，但需要注意几个细节：

• 状态确认：每一步操作后必须等待节点状态稳定：停止备用HMaster后，要确认其进程完全退出、ZooKeeper中对应的备份节点已清理；停止活跃HMaster后，必须通过hbase master status等命令确认备用节点已完成选举并接管集群服务，再启动原活跃节点。
• 版本兼容性：针对0.94及更早的老旧版本，这种分步操作可能触发选举异常，不建议使用；现代版本已优化了ZNode竞争处理，稳定性大幅提升。
• 监控保障：操作过程中要实时监控HMaster日志、ZooKeeper节点变化，及时处理假死、选举超时等异常情况。

总的来说，你的方案确实比原脚本的方式更优雅，适合对可用性要求高的生产环境。原脚本的设计更多是出于早期版本兼容性和简化实现的妥协。

内容的提问来源于stack exchange，提问作者Jack Yang