HBase跨集群复制从原理到落地：WAL、Peer与容灾实战

搞大数据的同学，迟早会撞上这么个需求：业务要做多机房容灾了，线上集群的数据要汇到离线集群做分析了，老集群要整体换硬件了。你打开搜索引擎，跳出来的基本都是官方文档碎片，看着不难，真上手就会发现一堆细节。这篇文章就把 HBase 跨集群数据复制从原理到落地从头串一遍。刚接触 HBase 的，可以把它当成一篇能读懂的入门实战笔记；正在做架构改造、要自己搭复制链路的人，可以直接拿里面的命令、参数和排查思路去对方案。我会尽量把“为什么这么做”讲透，而不是扔一堆命令让你抄完就完事。

1. 跨集群复制到底是干嘛的，别和普通备份搞混

跨集群复制在 HBase 里对应的官方术语是 Replication，很多时候也被叫“集群间数据同步”。它解决的问题其实很单一：让一个集群里的写入，自动、持续地出现在另一个集群中。但就是这个看似简单的需求，细分下来有四种完全不同的业务场景，每种场景对延迟、一致性和容错的要求都不一样。如果在设计阶段没想清楚自己属于哪一类，后面所有参数调优都会很拧巴。

1.1 四种最常见的业务场景

第一种是容灾。主集群在 A 机房，备集群在 B 机房，主挂了以后业务切到备。这是最经典的“冷备转热备”诉求。这里对复制的要求是：数据延迟尽量小，最好在秒级到分钟级；备集群的 RegionServer 即使平时不接流量，也时刻准备好承接请求。要注意的是，这里的“备”不是备份，而是另一套处在运行状态的 HBase 集群。

第二种是数据汇聚或读分离。比如线上业务实时写入源集群，分析部门不希望自己的大批量 Scan 任务把线上 RegionServer 压垮，所以让源集群实时复制一份数据到分析集群。这种场景下，复制出来的集群可以有不同的表结构、不同的预分区策略，也可以适当降低副本因子，反正最终只是供离线任务读取。

第三种是集群迁移。老集群版本太旧、机器太破，或者要换机房，最稳妥的方式就是开一条复制链路，让新集群边接数据边追平，最后择机切换业务流量。这个方法比停机导出再用 Import 灌数据要平滑得多，也是最推荐的迁移姿势之一。这里对复制的要求是追平速度快，存量迁移能并行进行，切换窗口越小越好。

第四种是双活或者多活。A 和 B 同时给业务读写，两边数据互相同步。说句实在话，HBase 的异步复制并不是做双活的银弹，尤其是“双向复制”对冲突处理和环路问题要求极高，很多团队最后都退化成单向复制加应用层双写。如果对一致性有硬性要求，建议一开始就把这个方案排除掉。

1.2 为什么不用定时 ETL 和导出导入代替

很多人一听到跨集群同步，第一反应是写个定时任务，从源集群 Scan 增量数据再写进目标集群。真这么干过的人基本都被折腾过：Scan 会消耗源集群大量资源，Range 边界变化后增量位点难以维护，大批量 Put 会让目标集群 MemStore 频繁 flush，垃圾回收和 Region Split 也跟着凑热闹。

HBase 官方的 Replication 走的不是应用层读写，而是直接读每个 RegionServer 写下的 WAL 日志。业务每次 Put 或 Delete 在写 MemStore 时，都同步落了一条 WAL 记录，复制线程从这条日志里把编辑拆出来，打包发给远端集群，再由远端集群的 RegionServer 应用到内存和 WAL。整个流程对业务线程的干预极小，也不依赖你写任何业务代码。

所以说到底，复制和备份是两个层面的事。备份是“给你一个能恢复的时间点”，复制是“让两个集群持续保持接近一致的状态”。定时的导出导入只解决“一次性”问题，复制解决的是“一直变化”的问题。如果你需要的只是某个历史时间点的数据，那就老老实实做快照和备份，开复制反而是给自己找麻烦。

2. 复制原理拆解：从 WAL 到远端的完整链路

跨集群复制的原理其实可以总结成三兄弟协作：源集群 RegionServer 里的 WAL、ZooKeeper 里的复制队列、目标集群的 RegionServer。三者各干各的，但配合不好就会出现“队列堆积、磁盘告警、复制延迟飙升”这些常见事故。理解这条链路，后面的调优和故障排查才有依据。

2.1 一条写入到底是怎么“流”到远端集群的

先看源集群这边。业务每写一条数据，实际上是先写 WAL，再更新内存里的 MemStore。WAL 文件本质是 HDFS 上的 SequenceFile，里面是一长串有先后顺序的编辑记录。复制功能开启后，只要这张表的列族被标记为 global scope，RegionServer 上的 ReplicationSource 线程就会实时打开当前 WAL 文件，从尾部继续读，相当于边写边同步。

读出来的编辑不会一条条往远端发，而是攒成一个批次，尽量按行键和列族分组，通过网络传给目标集群的对应 RegionServer。目标集群接到这批编辑后，会先解包、按目标表的 Region 重新路由，再写入自己的 WAL 和 MemStore。因为写入请求本身就具备幂等性质，所以重复收到同一条 Put 或 Delete 并不会导致灾难性错误，只是会被再次执行一遍。

这中间 ZooKeeper 到底扮演什么角色？它维护的是每个源 RegionServer 到每个 Peer 的“复制进度队列”，队列里记录的是当前正在复制的 WAL 文件名，以及这个文件已经读到的偏移量。只要一条编辑确认被远端成功接收并处理，对应偏移量才会往前走。假如源 RegionServer 挂了，它的复制队列不会丢，其他存活的 RegionServer 会通过 ZooKeeper 感知并接管剩余 WAL，继续复制。这也是为什么 HBase 复制能撑住 RegionServer 故障的关键原因。

2.2 不是每张表都会自动复制，关键在 scope

很多第一次上手的人都会踩同一个坑：我明明 add_peer 了，为什么新写入的另一套集群里啥也没有？大概率是表列族的复制范围没开。HBase 表在创建时，列族的 REPLICATION_SCOPE 默认为 0，也就是只在本集群生效；只有把 scope 改成 1，编辑才会进入全局复制通道。

这个设计初看有点多余，细想非常有道理。假设一个集群里有几十张表，其中只有两张表需要跨集群，那其他表的 WAL 根本没必要被复制线程扫描，能省下大量 CPU 和网络开销。在 HBase Shell 里可以通过这样开启：

alter 'ods:user', {NAME => 'info', REPLICATION_SCOPE => 1}

或者在建表时直接指定：

create 'ods:user', {NAME => 'info', REPLICATION_SCOPE => 1}

如果想偷懒，直接用enable_table_replication 'ods:user'也能把表里所有列族一次性打开。不过在生产环境我更推荐手动控制，因为有些敏感列族其实并不需要出集群，开着等于少了一道过滤。

2.3 关键参数怎么调，先看机制再动按钮

跨集群复制不是“配置完就能自动跑满带宽”的组件，它有几个参数直接决定批次大小和线程数量。我列一张表，大家照着语义去 hbase-site.xml 里找对应配置项即可，不同版本的参数名可能稍有差异，但机制不变。

调参时改一个参数解决所有问题是不现实的，很多时候瓶颈根本不在源端参数，而在目标集群有没有足够的空闲 RegionServer 去处理这些写入。如果你发现复制速率一直上不去，别急着一口气把批次参数拉满，先看看目标集群的写路径压力和网络带宽是不是已经打满。我是见过有人把批次调得特别大，结果源端 RegionServer 频繁 Full GC，只是把问题从目标端搬到了源端。

2.4 顺序性、串行复制和异步复制之间的取舍

HBase 复制天然强调顺序：同一个 WAL 里的编辑会按顺序发送和处理，这样才能保证同一行的多次更新在目标端按时间顺序落地。但“全局串行”对吞吐是非常大的限制，因为一个 RegionServer 里的所有表、所有列族都串在一个复制流后面，前面慢一点，后面全卡住。

HBase 2.x 开始支持 Serial Replication，它允许复制的编辑按列族拆分到不同队列，同一列族内部保持顺序，不同列族之间可以并行。这个能力对“同一个 CF 内强一致、不同 CF 允许乱序”的业务来说，吞吐提升非常可观。如果你的 HBase 版本不支持，只能接受全串行模式，那就更需要在源端把待复制表的 Region 分布控制好，避免单个 RegionServer 撑着全集群的复制流量。

我这里再强调一句：复制的本质是异步的，RPO 不可能是零。如果业务对数据一致性要求极高，比如金融系统双活，官方复制方案只能作为其中一个环节，不能作为唯一保障。你始终要有一个“追平检查”和“切换演练”机制，而不是假设复制链路永远健康。

3. 一份可以照着做的落地实施流程

原理聊清楚了，接下来就是实操。我这套流程不是从官方手册抄的，而是结合多次迁移、容灾演练总结出来的“安全路线”：先补存量、再开增量、最后验证追踪。如果你跳过其中某一步，比如直接 add_peer 然后指望历史数据也自动过去，大概率会在第二天发现目标集群少了一大半数据。

3.1 动手前先检查这五件事

第一件事是版本兼容。HBase 跨版本复制并不是所有组合都能跑，主版本不一致很容易出现序列化不兼容或 RPC 协议对不上的问题。稳妥的做法是源集群和目标集群大版本保持一致，小版本尽量别差太远。如果确实存在版本差异，先找官方兼容性说明，别拿生产环境试错。

第二件事是网络和端口。复制链路用的是 RegionServer 的 RPC 端口，默认 16020。源和目标之间的安全组、防火墙要放通，而且要确认不是“单向 ping 通就行”，是源端所有 RegionServer 到目标端所有 RegionServer 都能连通。很多问题看着像复制超时，其实就是一个跨机房防火墙规则把部分源节点挡住了。

第三件事是目标集群的表结构。复制不会帮你自动建表，也不会帮你自动补列族。源表叫 ods:user，有 info、tag 两个列族，目标集群就必须有一个 ods:user，且 info、tag 都存在。列族参数不一致一般不影响数据落地，但 Region 分布、压缩算法、TTL 不一致，会导致目标集群性能差异极大。

第四件事是 Kerberos 权限。如果两边都开了认证，复制使用的用户必须在目标端有“写”权限，否则大量编辑会在远端被拒绝，错误日志还会被淹没在“AccessDeniedException”里。我建议提前建一个专用复制账号，权限最小化，别拿业务超级管理员账号去配复制链路。

第五件事是存量数据规模。复制只是增量通道，它解决不了“源集群里已经躺着 10TB 历史数据”这个事实。在启用复制前，生产上一定要先做一次快照导出，把存量数据搬运到目标集群。这一步是很多人最容易忽略的。

3.2 存量同步实操：快照导出，而不是直接复制

存量数据同步我推荐用 HBase 自带的快照工具。它比 DistCp 拷 HFile 更安全，因为快照不会阻塞在线写入，而且导出的 HFile 可以直接被目标集群加载。操作分三步。

第一步，在源集群创建快照：

hbase snapshot create -n initial_sync -t 'ods:user'

注意，快照名不能和已有快照重复。表特别大的时候，这个命令会执行一会儿，但不会锁表，业务照常读写。

第二步，使用 ExportSnapshot 把快照推到目标集群的 HDFS：

hbase org.apache.hadoop.hbase.snapshot.ExportSnapshot \ -snapshot initial_sync \ -copy-to hdfs://target-namenode:8020/hbase \ -mappers 16

-mappers控制并发度，可以根据网络带宽适当调大。这里假设两边 HDFS 是物理隔离的，需要通过 DistCp 类型的方式传文件。如果两个集群共享同一套 HDFS，这一步可以变成直接在目标集群 clone 快照，速度会快很多。

第三步，在目标集群通过恢复快照的方式拿到数据：

hbase shell restore_snapshot 'initial_sync'

恢复完成后，先用count或者Scan抽查几个关键表的行数，确保存量数据已经完整到达。数据量特别大时，用完全精确的行数比对可能太慢，我通常的土办法是：取最近一段时间的几个关键行键，对比两边数据是否一致，再用离线任务统计全表数量，随后再做第二轮核对。

3.3 增量复制配置：Peer 和表级开启

存量同步和增量启用的先后顺序，我建议是“先把快照恢复跑完，再开复制”。因为如果先开复制，源端历史上残留在旧 WAL 里的编辑也有可能被扫描出来，和你正在导入的存量数据叠在一起，虽然幂等，但会让目标集群多承受大量不必要的写放大。

添加复制 Peer 的命令很简单：

hbase shell add_peer 'peer_dr', 'zk1,zk2,zk3:2181:/hbase'

这里的zk1,zk2,zk3:2181:/hbase是目标集群的连接串，由目标集群的 ZooKeeper 节点列表和 chroot 组成。千万注意，这个 ZooKeeper 必须属于目标集群，不能顺手写成源集群自己的 ZooKeeper，否则 Peer 会连回自己，导致环路。

如果只想复制某些表的某些列族，可以用带映射的写法：

add_peer 'peer_dr', 'zk1,zk2,zk3:2181:/hbase', TABLE_CFS => { "ods:user" => ["info", "tag"], "ods:order" => ["record"] }

添加完 Peer 后，再把对应表的复制范围打开。使用enable_table_replication最省事：

enable_table_replication 'ods:user'

也可以指定列族：

alter 'ods:user', {NAME => 'info', REPLICATION_SCOPE => 1}

有些文章会建议在加 Peer 之前就改表配置，其实关系不大，关键是队列建立后 WAL 里新写入的编辑才会被标记为待复制。修改完表配置后，如果有需要，可以通过滚动重启 RegionServer 来确保所有 RegionServer 都加载到新的配置，但在线alter一般也能生效，具体看你的版本。

3.4 复制状态怎么确认，别靠用人眼扫数据

配置完成后，进入 HBase Shell 执行：

status 'replication'

这个命令会显示 Peer 列表和当前复制源的作用状态。更细一点可以拆开看：

status 'replication', 'source' status 'replication', 'sink'

源端会显示每个 RegionServer 的复制队列长度、最后传输时间；目标端会显示收到了多少批次。如果你启用了 Hadoop 的监控面板，可以再盯一下 JMX 里的ReplicationSource指标，重点看ageOfLastShippedOp。这个数字代表上一次成功传输距离当前有多远，持续快速增长就是复制卡住的信号。

最后，做一次端到端的验证：从源集群 put 一条新数据，十秒之内去目标集群 scan 这条记录。如果目标是读写分离场景，这一步基本就能证明链路通了。之后不要忘了把验证脚本留着，以后每次配置新 Peer 或者变更表结构，都能用同一套回归方法快速判断风险。

4. 实施中的典型坑和排查实录

复制链路这东西，平时不显山不露水，一旦出了问题就是“源端磁盘被 WAL 堆满”这种级别的事故。我在这部分把几个高频问题按“症状、可能原因、处理办法”列出来，大家可以直接对照排查。

4.1 存量同步完了，目标集群却收不到任何增量

这是最常见的起步问题。快照恢复了，Peer 也 add 了，表也 enable 了，新写入的作业始终不出现。第一优先怀疑对象是 CF 的 REPLICATION_SCOPE 没有真正生效，尤其当表是通过旧代码建出来、列族参数没改的时候。你可以用describe 'ods:user'看一眼，如果列族里没有REPLICATION_SCOPE或值为 0，那数据就不可能进复制通道。

处理方式是执行一次alter，把列族 scope 改为 1，或者直接enable_table_replication。改完之后，再观察源端 WAL 是否在滚动后进入队列。有些版本对存量 WAL 的处理并不积极，如果修改配置前那个 WAL 已经被复制线程跳过了，新数据就只能等下一个 WAL 文件生成。等不及的话可以用flush 'ods:user'强制滚动 WAL，但线下测试时别随便在生产这么干，容易引发瞬时性能抖动。

4.2 目标集群宕了，源端磁盘突然暴涨

复制是异步队列机制，目标集群连不上，源端不会丢数据，但会不停积压 WAL 文件。因为复制线程没法把日志偏移量推进，HMaster 和 RegionServer 就会认为这些 WAL 还没被“消费完”，不能清理。时间一长，源端 HDFS 的磁盘空间会被复制日志占满。这个坑其实是机制问题，不是 bug。

处理办法分两级。短期应急是找到积压最严重的 RegionServer，看它的复制队列长度，然后评估目标集群恢复时间。如果目标集群几个小时内能恢复，就扛一扛；如果确定要挂很久，先执行：

disable_peer 'peer_dr'

注意是disable_peer，不是remove_peer。remove_peer会删掉整个复制队列和进度信息，等链路恢复后很可能会漏数据。disable_peer只是暂停发送，队列和偏移量都还在，后续再enable_peer就能接着传，这是容灾链路里比较稳妥的“暂停”按钮。

长期方案则是给复制队列单独划一块磁盘或者配置 HDFS Quota，防止某个 Peer 故障把整个源集群拖垮。治本的方法是在目标集群做更完整的监控和告警，比如 ZooKeeper 可用性、YARN 资源、RegionServer 存活数，任何一项出问题都可能在短时间内传导成源端磁盘压力。

4.3 复制延迟很高，但源端 CPU 和网络看起来都不忙

这种情况我遇到过多次，表面上什么都正常，就是ageOfLastShippedOp越来越大，复制队列越积越长。把排查视角放到目标端后发现，目标集群的 Region 分布很不均匀，大量写入全打在几个 RegionServer 上，它们负载很高，处理不过来。

如果你确认目标端负载正常、网络也正常，那问题大概率出在复制线程本身。HBase 的复制线程在读取 WAL 时是串行的，一个 RegionServer 上如果有大量表开了复制，且早期 WAL 文件比较大，日志在“拆装打包”阶段就会占用较多时间。这时可以尝试调大批次参数，让每一次 RPC 携带更多数据，降低 RPC 次数，从而摊薄固定开销。

另一个容易被忽略的是 HBase 2.x 里 Serial Replication 的使用。如果你的业务允许多个列族并行复制，可以研究一下串行复制特性。它能把原来一条大流水拆成多条小流水，整个复制吞吐往往能翻倍。不过引入它之前，建议先做一次完整的乱序接受能力评估，别为了吞吐破坏业务一致性。

4.4 双向复制配置好后，发现数据出现环路风险

双向复制看起来美好，实际上非常容易出问题。A 集群的数据复制到 B，B 又把收到的数据当成自己的写入再复制回 A，如此反复。虽然 HBase 会对来自复制通道的写入做一些特殊标记，但官方并不建议通过简单配置双向 Peer 来实现双向同步，版本差异和表配置不一致都可能让环路风险变成实际事故。

我自己的经验是：能做单向就做单向。需要两个方向都同步时，优先考虑应用层双写，或者只用消息队列做一端的异步回放。如果你真的逃不开双向 Peer，至少把两张表拆成两个不同的列族，或者在应用层打上“来源标记”，从写入逻辑上强制避免同一行数据在两个集群里反复修改。这个方案很土，但比依赖底层防环机制要可靠得多。

4.5 复制链路的常见故障速查表

5. 什么样的场景不建议用官方复制

跨集群复制不是万金油，在某些场景下它比你想的更难用。批量离线同步几千张表这种场景，就不太适合。因为复制是对每一张打开 scope 的表实时生效的，如果只是想把一天一次的批处理结果从一个集群“搬”到另一个集群，开复制反而会让源集群持续背负网络开销和日志堆积压力，不如直接用快照、DistCp 或其他离线同步工具。

强一致同步写场景也不建议。官方复制默认异步，意味着主集群写入成功以后，备集群可能还没收到。金融交易、库存扣减这种必须保证两边同时生效的业务，靠复制是不够的。你可以考虑双写与事务消息，或者使用更专业的分布式数据层，把一致性问题交给有事务保证的系统去解决。

跨大版本甚至跨社区分支复制，比如 CDH 的 HBase 复制到原生 HBase，或者 HBase 1.x 复制到 HBase 3.x，也尽量别碰。不同版本之间的序列化格式、RPC 协议、ZooKeeper 数据结构差异非常大，表面看着能加 Peer，但真跑到一半报错，排查成本比直接升级迁移还要高。

跨集群复制这个方向，也是面试里经常被深挖的点。很多人只背了 add_peer 命令，问到“WAL 积压怎么处理”“为什么先迁存量再开增量”就答不上来。你把上面这套机制理解透了，面试官再往里问，也无非是看你能不能把 ZooKeeper 队列、WAL 清理、目标端 RPC 处理和幂等性串成一个完整故事。

最后再分享一个我自己踩过几次坑之后的习惯：每次搭完复制链路，我都会写一个小脚本，周期性从源集群随机取若干行，到目标集群比对最新值。这个脚本不重，但能帮你在“复制已经坏了几天”之前及时发现问题。大数据链路最怕的不是故障，而是故障发生后所有人都没察觉。复制链路看着是后台自动跑的，其实也需要你用非常朴素的措施去确认它还在好好工作。