引言
欢迎来到"每天10分钟学会OceanBase"的第20天！在前19天里，我们已经掌握了OceanBase的部署、高可用、备份恢复等核心技能。昨天我们在课后思考中留了一个问题：如果整个机房因为断电或光缆被挖断而彻底瘫痪，单机房的高可用还能顶得住吗？
答案显然是不能。俗话说得好，"不要把鸡蛋放在同一个篮子里"。在金融级业务场景下，我们必须把数据分散到不同的物理机房。今天，我们就来聊聊如何构建跨机房容灾架构，让数据库真正具备"金刚不坏之身"。
核心概念
在动手之前，我们需要理清几个关键概念：
多Zone部署与跨机房容灾：OceanBase的Zone（可用区）在物理上通常对应一个机房。跨机房容灾的本质，就是将多个Zone分布在不同的物理机房中。
Multi-DC（多数据中心）架构：OceanBase原生支持多数据中心架构，通过Paxos协议保证多副本之间的数据强一致性。
RPO与RTO： - RPO（恢复点目标）：故障后允许丢失的数据量。OceanBase基于Paxos协议，跨机房同步模式下RPO=0，即数据零丢失。 - RTO（恢复时间目标）：故障后恢复服务的时间。OceanBase自动选举机制下，RTO通常在30秒以内。
Log Stream与Log Service：Log Stream是数据同步的基本单位，Log Service负责跨Zone的日志传输。它们是跨机房数据同步的"高速公路"。
Active-Standby vs Active-Active： - Active-Standby（主备）：一个机房提供服务，其他机房只同步数据，故障时切换。 - Active-Active（双活）：多个机房同时提供读写服务，OceanBase通过多副本Paxos原生支持这种模式。
10分钟实操：5步完整演练
第1步：查看当前集群的Zone分布
首先，我们来看看当前集群的Zone信息：
SELECT zone, svr_ip, svr_port, status, role
FROM oceanbase.__all_server;
第2步：规划跨机房部署拓扑
假设我们有三个机房：北京A、北京B、上海C。规划如下： - Zone1（北京A）：2个Observer节点 - Zone2（北京B）：2个Observer节点 - Zone3（上海C）：2个Observer节点
第3步：配置Observer节点的Zone归属
在每台机器的observer.conf配置文件中，设置Zone参数：
# 北京A机房节点
zone = zone1
# 北京B机房节点
zone = zone2
# 上海C机房节点
zone = zone3
第4步：设置跨机房数据同步策略
创建资源池时，指定跨Zone的副本分布：
CREATE RESOURCE POOL pool_cross_dc
UNIT = 'unit_2c4g',
UNIT_NUM = 1,
ZONE_LIST = ('zone1', 'zone2', 'zone3');
第5步：模拟机房级故障验证
停掉北京A机房的所有Observer节点，观察集群状态：
# 在北京A机房执行
killall observer
然后在其他机房执行以下SQL验证：
-- 检查集群状态
SELECT * FROM oceanbase.__all_zone WHERE name = 'status';
-- 验证数据完整性
SELECT COUNT(*) FROM your_business_table;
跨机房容灾最佳实践
- 机房选址：同城跨机房网络延迟应控制在3ms以内，这是保证写性能的关键。
- 副本分布：使用location标签将FOLLOWER副本合理分布，避免单机房副本过多。
- 带宽规划：日志同步对带宽敏感，建议预留至少50%的带宽余量应对峰值。
- 定期演练：每季度至少进行一次真实的跨机房切换演练。
- 安全合规：跨机房传输建议开启TDE加密，满足等保要求。
OceanBase特有优势
- 原生Paxos：无需额外部署复制组件，架构更简单。
- 自动负载均衡：节点扩缩容后自动重新平衡数据。
- 在线扩缩容：业务无感知，真正实现弹性。
- 跨地域复制：支持Cross-Region Replication，满足异地灾备需求。
运维避坑指南
- 延迟调优：跨机房写延迟较高，可通过调整log_disk_size和memory_limit优化。
- 脑裂预防：确保Paxos多数派节点分布在不同机房，避免网络分区导致双主。
- 监控覆盖：告警必须包含跨机房链路延迟、日志同步位点差等指标。
- 容量翻倍：跨机房部署意味着数据至少3副本，存储规划要预留足够空间。
今日小结
跨机房容灾不是可选项，而是生产环境的必选项。OceanBase的原生多副本架构让这一切变得简单而可靠。