OceanBase 两地三中心双活配置

双活架构设计

1. 架构拓扑

2. 副本分布策略

sql

-- 设置集群副本分布策略
ALTER SYSTEM SET locality = 'F@zone1,F@zone2,F@zone3';

-- 设置租户级副本分布
ALTER TENANT mysql_tenant SET locality = 'F@zone1,F@zone2,F@zone3';

-- 设置表级副本分布
ALTER TABLE app_db.important_table SET locality = 'F@zone1,F@zone2,F@zone3';

3. 网络拓扑设计

中心内网络：使用高速网络连接同一机房内的节点
中心间网络：使用专线或高质量网络连接不同地理位置的数据中心
网络延迟要求：
- 同城中心间延迟：< 5ms
- 异地中心间延迟：< 50ms
- 丢包率：< 0.1%

双活配置步骤

1. 基础环境准备

bash

# 配置主机名和 IP 映射
echo "192.168.1.101 zone1-1" >> /etc/hosts
echo "192.168.1.102 zone1-2" >> /etc/hosts
echo "192.168.2.101 zone2-1" >> /etc/hosts
echo "192.168.2.102 zone2-2" >> /etc/hosts
echo "192.168.3.101 zone3-1" >> /etc/hosts

# 配置网络参数
sysctl -w net.core.somaxconn=65535
sysctl -w net.ipv4.tcp_max_syn_backlog=65535
sysctl -w net.ipv4.tcp_tw_reuse=1
sysctl -w net.ipv4.tcp_fin_timeout=30

2. 集群部署

bash

# 部署 Zone1
obd cluster deploy zone1-cluster -c zone1-deploy.yaml
obd cluster start zone1-cluster

# 部署 Zone2
obd cluster deploy zone2-cluster -c zone2-deploy.yaml
obd cluster start zone2-cluster

# 部署 Zone3
obd cluster deploy zone3-cluster -c zone3-deploy.yaml
obd cluster start zone3-cluster

# 合并为一个集群
obd cluster join global-cluster -c global-deploy.yaml

3. 双活配置

sql

-- 1. 创建集群
CREATE CLUSTER obcluster
  ZONE_LIST = ('zone1', 'zone2', 'zone3')
  LOCALITY = 'F@zone1,F@zone2,F@zone3';

-- 2. 创建资源单元和资源池
CREATE RESOURCE UNIT cpu_unit MAX_CPU 16, MIN_CPU 8, MEMORY_SIZE '32G', MAX_IOPS 10000, MIN_IOPS 5000;

CREATE RESOURCE POOL zone1_pool UNIT 'cpu_unit', UNIT_NUM 3, ZONE_LIST ('zone1');
CREATE RESOURCE POOL zone2_pool UNIT 'cpu_unit', UNIT_NUM 3, ZONE_LIST ('zone2');
CREATE RESOURCE POOL zone3_pool UNIT 'cpu_unit', UNIT_NUM 3, ZONE_LIST ('zone3');

-- 3. 创建租户
CREATE TENANT mysql_tenant
  RESOURCE_POOL_LIST = ('zone1_pool', 'zone2_pool', 'zone3_pool')
  PRIMARY_ZONE = 'zone1,zone2,zone3'
  LOCALITY = 'F@zone1,F@zone2,F@zone3'
  TENANT_MODE = 'MYSQL';

-- 4. 配置双活参数
ALTER SYSTEM SET enable_active_active = true;
ALTER SYSTEM SET active_active_zone_list = 'zone1,zone2';
ALTER SYSTEM SET active_active_replica_count = 2;
ALTER SYSTEM SET active_active_sync_timeout = 5000;

4. OBProxy 双活配置

sql

-- 配置 OBProxy 连接两个活跃中心
ALTER PROXYCONFIG SET cluster_list = 'obcluster:192.168.1.101:2881,obcluster:192.168.2.101:2881';
ALTER PROXYCONFIG SET proxy_route_policy = 'weight';
ALTER PROXYCONFIG SET obcluster_weight = 'zone1:50,zone2:50';

-- 刷新 OBProxy 配置
ALTER PROXYCONFIG REFRESH;

双活数据同步

1. 同步机制

OceanBase 双活架构基于 Paxos 共识协议实现数据同步：

同步复制：两个活跃中心之间采用同步复制，确保数据一致性
异步复制：活跃中心与备用中心之间采用异步复制，平衡性能和一致性
日志复制：通过 redo 日志实现跨中心数据复制
一致性校验：定期进行数据一致性校验，确保数据完整性

2. 同步延迟监控

sql

-- 查看副本同步延迟
SELECT * FROM oceanbase.GV$OB_REPLICA_LAG;

-- 查看日志复制状态
SELECT * FROM oceanbase.GV$OB_LOG_STAT WHERE stat_id IN ('log_send_throughput', 'log_receive_throughput');

-- 查看 Paxos 状态
SELECT * FROM oceanbase.GV$OB_PAXOS_STAT;

3. 同步异常处理

sql

-- 查看同步异常
SELECT * FROM oceanbase.GV$OB_REPLICA WHERE status != 'NORMAL';

-- 修复同步异常
ALTER SYSTEM REPAIR REPLICA ON table_name PARTITION partition_name;

-- 手动触发日志同步
ALTER SYSTEM SYNC LOG TO ZONE 'zone3';

故障切换机制

1. 自动故障切换

sql

-- 启用自动故障切换
ALTER SYSTEM SET enable_auto_failover = true;
ALTER SYSTEM SET failover_timeout = 30000;
ALTER SYSTEM SET max_failover_retry_count = 3;

-- 配置故障切换策略
ALTER SYSTEM SET failover_policy = 'zone_priority';
ALTER SYSTEM SET zone_priority_list = 'zone1,zone2,zone3';

2. 手动故障切换

sql

-- 手动切换主中心
ALTER SYSTEM SWITCHOVER PRIMARY ZONE TO 'zone2,zone1,zone3';

-- 手动切换租户主中心
ALTER TENANT mysql_tenant SWITCHOVER PRIMARY ZONE TO 'zone2,zone1,zone3';

-- 强制切换（在极端情况下）
ALTER SYSTEM FORCE SWITCHOVER PRIMARY ZONE TO 'zone2,zone1,zone3';

3. 故障恢复流程

故障检测：系统检测到数据中心故障
自动切换：触发自动故障切换流程
新主选举：选举新的主中心
数据同步：确保数据一致性
流量切换：将业务流量切换到新的主中心
故障恢复：修复故障数据中心
重新加入：故障数据中心修复后重新加入集群
恢复双活：恢复两地三中心双活状态

双活监控与告警

1. 关键监控指标

sql

-- 集群级监控
SELECT * FROM oceanbase.GV$OB_CLUSTER_STAT WHERE stat_id IN ('cpu_total', 'memory_total', 'iops_total');

-- 副本同步监控
SELECT * FROM oceanbase.GV$OB_REPLICA_STAT WHERE stat_id IN ('replica_sync_lag', 'log_send_queue_length');

-- 双活状态监控
SELECT * FROM oceanbase.GV$OB_ACTIVE_ACTIVE_STAT;

2. 告警配置

sql

-- 配置同步延迟告警
ALTER SYSTEM SET alert_replica_lag_threshold = 10000;  -- 10秒
ALTER SYSTEM SET alert_replica_lag_duration = 60;     -- 持续60秒

-- 配置双活状态告警
ALTER SYSTEM SET alert_active_active_status = true;
ALTER SYSTEM SET alert_active_active_switch = true;

3. 监控工具集成

Prometheus + Grafana：配置 OceanBase 双活监控仪表盘
OCP 监控：使用 OceanBase 云平台监控双活状态
第三方监控：集成 Zabbix、Nagios 等监控工具

双活最佳实践

1. 资源规划

CPU 资源：每个节点预留 20% 资源用于双活同步
内存资源：为日志缓存预留足够内存
存储资源：使用高性能 SSD 存储，避免 IO 瓶颈
网络资源：确保中心间网络带宽足够，延迟符合要求

2. 配置优化

sql

-- 优化 Paxos 配置
ALTER SYSTEM SET paxos_thread_count = 8;
ALTER SYSTEM SET paxos_retry_interval = 100;

-- 优化日志配置
ALTER SYSTEM SET max_syslog_file_count = 200;
ALTER SYSTEM SET max_syslog_keep_time = 7;
ALTER SYSTEM SET enable_syslog_recycle = true;

-- 优化双活配置
ALTER SYSTEM SET active_active_sync_timeout = 5000;
ALTER SYSTEM SET active_active_replica_count = 2;

3. 测试与验证

故障注入测试：定期进行故障注入测试，验证故障切换功能
性能测试：测试双活状态下的性能表现
容灾演练：定期进行容灾演练，验证灾难恢复能力
数据一致性验证：定期验证跨中心数据一致性

4. 运维管理

定期巡检：建立双活集群定期巡检机制
监控告警：配置完善的监控和告警体系
文档更新：及时更新双活配置文档
人员培训：培训运维人员掌握双活集群管理

常见故障处理

1. 同步延迟过大

故障现象：跨中心同步延迟超过阈值

排查步骤：

sql

-- 查看同步延迟
SELECT * FROM oceanbase.GV$OB_REPLICA_LAG WHERE lag_time > 10000;

-- 查看网络状态
SELECT * FROM oceanbase.GV$OB_NETWORK_STAT;

-- 查看系统负载
SELECT * FROM oceanbase.GV$OB_SYSLOAD;

解决方案：

优化网络带宽和延迟
调整同步策略（同步→半同步）
增加节点资源配置
优化 SQL 查询，减少大事务

2. 双活状态异常

故障现象：双活状态变为非活跃

排查步骤：

sql

-- 查看双活状态
SELECT * FROM oceanbase.GV$OB_ACTIVE_ACTIVE_STAT;

-- 查看错误日志
SELECT * FROM oceanbase.GV$OB_ERROR_LOG WHERE error_no != 0 ORDER BY log_time DESC LIMIT 10;

-- 查看集群状态
SELECT * FROM oceanbase.GV$OB_CLUSTER_STATUS;

解决方案：

修复导致双活状态异常的节点
手动恢复双活状态
调整双活配置参数
检查并修复网络连接

3. 故障切换失败

故障现象：自动故障切换失败

排查步骤：

sql

-- 查看故障切换日志
SELECT * FROM oceanbase.GV$OB_FAILOVER_HISTORY WHERE status = 'FAILED' ORDER BY start_time DESC LIMIT 1;

-- 查看集群状态
SELECT * FROM oceanbase.GV$OB_CLUSTER_STATUS;

-- 查看节点状态
SELECT * FROM oceanbase.GV$OB_SERVERS WHERE status != 'ACTIVE';

解决方案：

检查故障切换配置
修复导致切换失败的节点
手动执行故障切换
调整故障切换参数

双活与其他架构对比

架构类型	可用性	灾难恢复	性能	成本	复杂度	适用场景
单活架构	中	低	高	低	低	小型应用
主备架构	高	中	中	中	中	中型应用
双活架构	极高	高	中	高	高	关键业务
多活架构	极高	极高	高	极高	极高	超大型应用

常见问题（FAQ）

Q1: 两地三中心双活架构的 RTO 和 RPO 是多少？

A1: 两地三中心双活架构的 RTO 和 RPO 取决于具体配置：

RTO：自动故障切换时约为秒级，手动切换时约为分钟级
RPO：同步复制时为 0，异步复制时取决于复制延迟

Q2: 双活架构对网络有什么要求？

A2: 双活架构对网络的要求：

同城中心间延迟：< 5ms
异地中心间延迟：< 50ms
带宽：根据业务量确定，建议至少 1Gbps
丢包率：< 0.1%

Q3: 如何平衡双活架构的性能和一致性？

A3: 平衡性能和一致性的方法：

两个活跃中心间使用同步复制，保证数据一致性
活跃中心与备用中心间使用异步复制，提高性能
根据业务需求调整同步策略
优化网络和存储性能，减少同步延迟

Q4: 双活架构下如何进行备份恢复？

A4: 双活架构下的备份恢复策略：

定期在三个中心分别执行备份
备份数据存储在独立的地理位置
制定跨中心恢复流程
定期测试恢复流程

Q5: 如何监控双活架构的健康状态？

A5: 监控双活架构健康状态的方法：

监控副本同步延迟
监控双活状态和切换事件
监控网络和存储性能
监控集群和节点状态
配置完善的告警机制

OceanBase 两地三中心双活配置 ​

双活架构设计 ​

1. 架构拓扑 ​

2. 副本分布策略 ​

3. 网络拓扑设计 ​

双活配置步骤 ​

1. 基础环境准备 ​

2. 集群部署 ​

3. 双活配置 ​

4. OBProxy 双活配置 ​

双活数据同步 ​

1. 同步机制 ​

2. 同步延迟监控 ​

3. 同步异常处理 ​

故障切换机制 ​

1. 自动故障切换 ​

2. 手动故障切换 ​

3. 故障恢复流程 ​

双活监控与告警 ​

1. 关键监控指标 ​

2. 告警配置 ​

3. 监控工具集成 ​

双活最佳实践 ​

1. 资源规划 ​

2. 配置优化 ​

3. 测试与验证 ​

4. 运维管理 ​

常见故障处理 ​

1. 同步延迟过大 ​

2. 双活状态异常 ​

3. 故障切换失败 ​

双活与其他架构对比 ​

常见问题（FAQ） ​

Q1: 两地三中心双活架构的 RTO 和 RPO 是多少？ ​

Q2: 双活架构对网络有什么要求？ ​

Q3: 如何平衡双活架构的性能和一致性？ ​

Q4: 双活架构下如何进行备份恢复？ ​

Q5: 如何监控双活架构的健康状态？ ​

OceanBase 两地三中心双活配置

双活架构设计

1. 架构拓扑

2. 副本分布策略

3. 网络拓扑设计

双活配置步骤

1. 基础环境准备

2. 集群部署

3. 双活配置

4. OBProxy 双活配置

双活数据同步

1. 同步机制

2. 同步延迟监控

3. 同步异常处理

故障切换机制

1. 自动故障切换

2. 手动故障切换

3. 故障恢复流程

双活监控与告警

1. 关键监控指标

2. 告警配置

3. 监控工具集成

双活最佳实践

1. 资源规划

2. 配置优化

3. 测试与验证

4. 运维管理

常见故障处理

1. 同步延迟过大

2. 双活状态异常

3. 故障切换失败

双活与其他架构对比

常见问题（FAQ）

Q1: 两地三中心双活架构的 RTO 和 RPO 是多少？

Q2: 双活架构对网络有什么要求？

Q3: 如何平衡双活架构的性能和一致性？

Q4: 双活架构下如何进行备份恢复？

Q5: 如何监控双活架构的健康状态？