HBase 是 ZooKeeper 最重的使用者之一。这篇真起一个 HBase 2.6.6,看它在 /hbase 下到底放了哪些节点、哪些信息在 ZooKeeper 里(谁是 master、哪些 region server 活着、meta 在哪)、哪些不在(region 的位置),再杀 region server 与 master,量切换时间和客户端受影响的程度。
backup-masters
draining
flush-table-proc
abort
acquired
reached
hbaseid master:7960h PBUF $a2d338cf-4858-467f-a979-e15f69c3815f
master [临时] master:7960 PBUF 127.0.0.1
master-maintenance
meta-region-server master:7960 &wsD PBUF 127.0.0.1
namespace
default master:79607;m default
hbase master:7960 hbase
online-snapshot
abort
acquired
reached
rs
127.0.0.1,7961,1790834465029 [临时] regionserver:7961 5Z6kPBUF 2.6.6 9git://buildbox.localdomain/home/apurtell/tmp/RM-2.6/hbas
127.0.0.1,7963,1790834465025 [临时] regionserver:7963 PBUF 2.6.6 9git://buildbox.localdomain/home/apurtell/tmp/RM-2.6/hbase (d
running master:7960 @Zo PBUF Thu Oct 01 14:01:06 CST 2026
splitWAL
table
hbase:meta master:7960 PBUF
hbase:namespace master:7960 PBUFHBase 默认 zookeeper.session.timeout 是 90000 ms(读自 hbase-default.xml);我把它设为 6000 才能在合理时间里观察切换。
TABLE_CREATED regions per server port: {7961=3, 7963=3}
ROWS_PUT 300
新增或变化的 znode:
t1 master:7960 PBUF
/hbase/meta-region-server = master:7960 &wsD PBUF 127.0.0.1/hbase/rs 下的节点 4.7 s 后消失;master 日志里:master.RegionServerTracker: RegionServer ephemeral node deleted, processing expiration [127.0.0.1,79 / master.ServerManager: Processing expiration of 127.0.0.1,7961,1790834465029 on 127.0.0.1,7960,179083 客户端:kill 之后共 6 次失败操作,第一个失败的操作开始于 +0.2 s,最后一个失败的操作结束于 +5.3 s(之后恢复;受影响的时间窗 5.0 s;每个失败的操作最多卡 hbase.client.operation.timeout=4000 ms);探测总次数 259 /hbase/rs 之前: 2 个 → 之后: 1 个
和服务发现一样靠临时节点的会话过期发现崩溃;但 HBase 还要把崩溃 server 的 region 重新分配、回放 WAL,所以客户端的受影响窗口比节点消失的时间更长。
/hbase/backup-masters 下: ['127.0.0.1,7962,1790834511049'] | 是否临时节点: True /hbase/master = master:7960 PBUF 127.0.0.1 /hbase/master 在 5.7 s 后换成新 master:master:7962o PBUF 127.0.0.1;active master 被杀期间客户端 123 次读写中失败 0 次(没有失败;推断是读写直接访问 region server、不经过 master,没有进一步验证)
master 选举与Master 选举那篇的做法一致:谁创建 /hbase/master 谁是 active,其余在 backup-masters 下等待。