2. 首页 > 国产数据库教程 > OceanBase教程 > 正文

OceanBase教程FG088-OceanBase高可用故障演练

教程整理：风哥教程  |  更新时间：2026-01-29  |  教程分类：OceanBase教程  |  文档学习：22

本文档风哥主要介绍OceanBase数据库高可用故障演练，包括OceanBase高可用概念、OceanBase故障类型、OceanBase演练目的、OceanBase演练规划、OceanBase节点故障演练、OceanBase Zone故障演练、OceanBase网络故障演练等内容，风哥教程参考OceanBase官方文档高可用、故障处理等内容编写，适合DBA人员在学习和测试中使用，如果要应用于生产环境则需要自行确认。

Part01-基础概念与理论知识

1.1 OceanBase高可用概念

高可用是指系统在部分组件故障时仍能持续提供服务的能力。OceanBase通过多副本架构实现高可用，支持自动故障切换。更多视频教程www.fgedu.net.cn

OceanBase高可用特性：

  • 多副本：默认3副本，数据冗余存储
  • Paxos协议：保证数据强一致性
  • 自动切换：故障自动检测和切换
  • RPO=0：数据零丢失
  • RTO<30s：快速故障恢复

1.2 OceanBase故障类型

# 故障类型

1. 节点故障
– OBServer进程崩溃
– 服务器宕机
– 资源耗尽（OOM）
– 磁盘故障

2. Zone故障
– 整个可用区宕机
– 网络中断
– 电力故障
– 自然灾害

3. 网络故障
– 网络分区
– 网络延迟
– 丢包
– 带宽不足

4. 其他故障
– RootService故障
– OBProxy故障
– 配置错误
– 数据损坏

1.3 OceanBase演练目的

# 演练目的

1. 验证高可用能力
– 故障检测速度
– 自动切换能力
– 数据一致性
– 业务影响评估

2. 检验应急预案
– 预案可行性
– 操作熟练度
– 工具可用性
– 沟通效率

3. 发现潜在问题
– 配置缺陷
– 监控盲区
– 流程漏洞
– 技能短板

4. 提升团队能力
– 故障处理经验
– 协作配合
– 压力应对
– 持续改进

风哥提示：故障演练是验证系统高可用能力的重要手段，建议定期进行演练，确保应急预案的有效性。

Part02-生产环境规划与建议

2.1 OceanBase演练规划

# 演练规划

1. 演练频率
– 月度演练：单节点故障
– 季度演练：Zone故障
– 年度演练：大规模故障

2. 演练时间
– 选择业务低峰期
– 避开重要业务时段
– 提前通知相关人员
– 准备回滚方案

3. 演练范围
┌─────────────────┬─────────────────────┐
│ 演练类型 │ 影响范围 │
├─────────────────┼─────────────────────┤
│ 单节点故障 │ 单节点 │
│ Zone故障 │ 整个Zone │
│ 网络分区 │ 部分节点 │
│ 全集群故障 │ 整个集群 │
└─────────────────┴─────────────────────┘

4. 演练团队
– 演练负责人
– 技术支持团队
– 业务验证团队
– 监控观察团队

2.2 OceanBase场景设计

# 场景设计

1. 场景分类
– 计划内演练：提前规划的演练
– 突击演练：不通知的随机演练
– 混沌演练：随机注入故障

2. 场景示例
┌─────────────────┬─────────────────────┐
│ 场景编号 │ 场景描述 │，风哥提示：。
├─────────────────┼─────────────────────┤
│ HA-001 │ 单OBServer宕机 │
│ HA-002 │ Zone网络中断 │
│ HA-003 │ RootService切换 │
│ HA-004 │ 磁盘空间满 │
│ HA-005 │ 高CPU负载 │
│ HA-006 │ 内存溢出 │
└─────────────────┴─────────────────────┘

3. 场景要素
– 触发条件
– 预期现象
– 验证方法
– 恢复步骤
– 评估标准

2.3 OceanBase回滚方案

# 回滚方案

1. 自动恢复
– 节点自动重启
– 副本自动补齐
– Leader自动选举

2. 手动恢复
– 节点启动
– 副本添加，学习交流加群风哥微信: itpux-com。
– 配置恢复

3. 回滚检查清单
– [ ] 集群状态正常
– [ ] 所有副本同步
– [ ] 业务验证通过
– [ ] 监控无告警
– [ ] 性能恢复正常

4. 应急回滚脚本
#!/bin/bash
# rollback.sh
# from:www.itpux.com.qq113257174.wx:itpux-com

echo “开始回滚操作…”

# 检查集群状态
obclient -e “SELECT * FROM oceanbase.__all_zone WHERE name = ‘status’;”

# 检查副本状态
obclient -e “SELECT * FROM oceanbase.__all_virtual_replica_task WHERE status != ‘FINISH’;”

# 检查Leader分布
obclient -e “SELECT zone, count(*) as leader_count FROM oceanbase.__all_virtual_core_meta_table GROUP BY zone;”

echo “回滚完成”

生产环境建议：演练前一定要做好数据备份，确保可以快速回滚，避免对生产业务造成影响。学习交流加群风哥微信: itpux-com

Part03-生产环境项目实施方案

3.1 OceanBase节点故障演练

# 节点故障演练

1. 演练前检查，学习交流加群风哥QQ113257174。
# 检查集群状态
obclient> SELECT * FROM oceanbase.__all_server;
+—————+———-+———-+——-+——————–+
| svr_ip | svr_port | inner_port| zone | status |
+—————+———-+———-+——-+——————–+
| 192.168.1.100 | 2882 | 2881 | zone1 | ACTIVE |
| 192.168.1.101 | 2882 | 2881 | zone2 | ACTIVE |
| 192.168.1.102 | 2882 | 2881 | zone3 | ACTIVE |
+—————+———-+———-+——-+——————–+

# 检查Leader分布
obclient> SELECT zone, count(*) as leader_count
FROM oceanbase.__all_virtual_core_meta_table
GROUP BY zone;
+——-+————–+
| zone | leader_count |
+——-+————–+
| zone1 | 167 |
| zone2 | 166 |
| zone3 | 167 |
+——-+————–+

2. 注入故障
# 停止OBServer进程
$ ssh 192.168.1.102
$ kill -9 $(pidof observer)

# 或者使用obd命令
$ obd cluster stop fgedu_cluster -s 192.168.1.102

3. 观察现象
# 集群状态变化
obclient> SELECT * FROM oceanbase.__all_server;
+—————+———-+———-+——-+——————–+
| svr_ip | svr_port | inner_port| zone | status |
+—————+———-+———-+——-+——————–+
| 192.168.1.100 | 2882 | 2881 | zone1 | ACTIVE |
| 192.168.1.101 | 2882 | 2881 | zone2 | ACTIVE |
| 192.168.1.102 | 2882 | 2881 | zone3 | INACTIVE |
+—————+———-+———-+——-+——————–+，更多视频教程www.fgedu.net.cn。

# Leader重新选举
obclient> SELECT zone, count(*) as leader_count
FROM oceanbase.__all_virtual_core_meta_table
GROUP BY zone;
+——-+————–+
| zone | leader_count |
+——-+————–+
| zone1 | 250 |
| zone2 | 250 |
| zone3 | 0 |
+——-+————–+

4. 业务验证
# 测试读写
obclient> INSERT INTO fgedu_test VALUES (1, ‘test’);
Query OK, 1 row affected

obclient> SELECT * FROM fgedu_test;
+—-+——+
| id | name |
+—-+——+
| 1 | test |
+—-+——+

5. 恢复节点
$ obd cluster start fgedu_cluster -s 192.168.1.102

# 检查恢复状态
obclient> SELECT * FROM oceanbase.__all_server;
+—————+———-+———-+——-+——————–+
| svr_ip | svr_port | inner_port| zone | status |
+—————+———-+———-+——-+——————–+
| 192.168.1.100 | 2882 | 2881 | zone1 | ACTIVE |
| 192.168.1.101 | 2882 | 2881 | zone2 | ACTIVE |
| 192.168.1.102 | 2882 | 2881 | zone3 | ACTIVE |
+—————+———-+———-+——-+——————–+

6. 演练总结
– 故障检测时间：< 5秒，更多学习教程公众号风哥教程itpux_com。 - Leader切换时间：< 10秒 - 业务影响时间：< 15秒 - 数据一致性：✓

3.2 OceanBase Zone故障演练

# Zone故障演练

1. 演练前准备
# 确认3副本配置
obclient> SELECT * FROM oceanbase.__all_tenant;
+————-+————-+————-+—————+
| tenant_id | tenant_name | primary_zone| locality |
+————-+————-+————-+—————+
| 1001 | fgedu_tenant| zone1 | FULL{1}@zone1,|
| | | | FULL{1}@zone2,|
| | | | FULL{1}@zone3 |
+————-+————-+————-+—————+

2. 注入故障
# 模拟整个Zone故障
$ ssh 192.168.1.100
$ systemctl stop network

# 或者关闭所有OBServer
$ obd cluster stop fgedu_cluster -s 192.168.1.100,192.168.1.101,192.168.1.102

3. 观察现象，from DB视频:www.itpux.com。
# 检查集群状态
obclient> SELECT zone, count(*) as server_count
FROM oceanbase.__all_server
WHERE status = ‘ACTIVE’
GROUP BY zone;
+——-+—————-+
| zone | server_count |
+——-+—————-+
| zone2 | 1 |
| zone3 | 1 |
+——-+—————-+

# 检查服务可用性
obclient> SELECT 1;
+—+
| 1 |
+—+
| 1 |
+—+

4. 业务影响评估
– 写服务：正常（2副本满足多数派）
– 读服务：正常
– 副本数：从3副本降为2副本
– 风险等级：高（失去容错能力）

5. 恢复Zone
$ systemctl start network
$ obd cluster start fgedu_cluster -s 192.168.1.100

6. 验证恢复
# 检查副本补齐
obclient> SELECT * FROM oceanbase.__all_virtual_replica_task;
+————-+———-+———-+——–+——–+——–+——–+
| tenant_id | table_id | partition_id| status| type | src | dst |
+————-+———-+———-+——–+——–+——–+——–+
| 1001 | 1001 | 0 | FINISH| ADD_REPLICA| zone2| zone1|
+————-+———-+———-+——–+——–+——–+——–+

# 确认3副本恢复
obclient> SELECT zone, count(*) as replica_count
FROM oceanbase.__all_virtual_core_meta_table
GROUP BY zone;
+——-+—————-+
| zone | replica_count |
+——-+—————-+
| zone1 | 500 |
| zone2 | 500 |
| zone3 | 500 |
+——-+—————-+

3.3 OceanBase网络故障演练

# 网络故障演练

1. 网络分区场景
# 模拟Zone1与Zone2、Zone3网络不通
$ ssh 192.168.1.100
$ iptables -A INPUT -s 192.168.1.101 -j DROP
$ iptables -A INPUT -s 192.168.1.102 -j DROP
$ iptables -A OUTPUT -d 192.168.1.101 -j DROP
$ iptables -A OUTPUT -d 192.168.1.102 -j DROP

2. 观察现象
# 检查选举状态
obclient> SELECT svr_ip, svr_port, role
FROM oceanbase.__all_virtual_core_meta_table
WHERE table_id = 1 AND partition_id = 0;
+—————+———-+———-+
| svr_ip | svr_port | role |
+—————+———-+———-+
| 192.168.1.101 | 2882 | LEADER |
| 192.168.1.102 | 2882 | FOLLOWER |
+—————+———-+———-+

# 检查服务状态
obclient> SELECT * FROM oceanbase.__all_server;
+—————+———-+———-+——-+——————–+
| svr_ip | svr_port | inner_port| zone | status |
+—————+———-+———-+——-+——————–+
| 192.168.1.100 | 2882 | 2881 | zone1 | INACTIVE |
| 192.168.1.101 | 2882 | 2881 | zone2 | ACTIVE |
| 192.168.1.102 | 2882 | 2881 | zone3 | ACTIVE |
+—————+———-+———-+——-+——————–+

3. 业务验证
# 从Zone2/Zone3访问
obclient -h192.168.1.101 -P3306 -ufgedu@fgedu_tenant -p -e “SELECT 1”
+—+
| 1 |
+—+
| 1 |
+—+

# 从Zone1访问（应该失败）
obclient -h192.168.1.100 -P3306 -ufgedu@fgedu_tenant -p -e “SELECT 1”
ERROR 4012 (HY000): Timeout

4. 恢复网络
$ iptables -F
$ iptables -X

5. 验证恢复
# 检查集群状态
obclient> SELECT * FROM oceanbase.__all_server;
+—————+———-+———-+——-+——————–+
| svr_ip | svr_port | inner_port| zone | status |
+—————+———-+———-+——-+——————–+
| 192.168.1.100 | 2882 | 2881 | zone1 | ACTIVE |
| 192.168.1.101 | 2882 | 2881 | zone2 | ACTIVE |
| 192.168.1.102 | 2882 | 2881 | zone3 | ACTIVE |
+—————+———-+———-+——-+——————–+

6. 演练总结
– 网络分区检测：< 10秒 - Leader切换：< 15秒 - 少数派节点自动降级 - 业务连续性保障

风哥提示：网络分区是最复杂的故障场景，需要特别注意脑裂和数据一致性问题。

Part04-生产案例与实战讲解

4.1 OceanBase OBServer故障案例

# 案例背景
– 生产环境3节点集群
– 业务高峰期单节点OOM
– 自动故障切换验证

# 故障现象
[2024-01-20 14:30:15] ERROR: observer process killed by OOM killer
[2024-01-20 14:30:16] WARNING: zone1 server 192.168.1.100 status changed to INACTIVE
[2024-01-20 14:30:18] INFO: Leader election started for partition 1001
[2024-01-20 14:30:20] INFO: New leader elected: 192.168.1.101

# 处理过程
1. 故障检测
– OCP告警触发
– 自动电话通知
– 值班人员响应

2. 故障确认
– 检查节点状态
– 确认业务影响
– 评估恢复时间

3. 自动恢复
– Leader自动切换
– 副本自动补齐
– 业务自动恢复

4. 根因分析
– 内存配置不足
– 突发查询导致OOM
– 需要增加内存或优化SQL

# 经验总结
– 故障检测：5秒
– 自动切换：10秒
– 业务恢复：15秒
– 数据一致性：无丢失

4.2 OceanBase Zone宕机案例

# 案例背景
– 同城双活架构
– 机房电力故障导致Zone1宕机
– 验证跨机房高可用

# 故障现象
[2024-01-20 03:00:00] CRITICAL: Zone zone1 all servers INACTIVE
[2024-01-20 03:00:05] WARNING: Lost majority for some partitions
[2024-01-20 03:00:10] INFO: Service degraded but available

# 处理过程
1. 故障确认
– 机房电力故障
– 预计恢复时间：2小时
– 启动应急预案

2. 业务影响评估
– 写服务：正常（2副本满足多数派）
– 读服务：正常
– 副本数：降级为2副本
– 风险：失去容错能力

3. 应急措施
– 通知业务部门
– 加强监控频率
– 准备扩容方案
– 暂停非关键操作

4. 恢复过程
– 电力恢复
– 服务器启动
– OBServer启动
– 副本自动补齐

# 经验总结
– 同城双活有效保障业务连续性
– 2副本运行

本文由风哥教程整理发布,仅用于学习测试使用,转载注明出处:http://www.fgedu.net.cn/10327.html

相关推荐

联系我们

在线咨询：点击这里给我发消息

微信号：itpux-com

工作日：9:30-18:30，节假日休息