## 1. 预案目的
– 明确应急响应的目标和原则
– 规范应急响应的流程和步骤
– 确保在故障发生时能够快速、有效地处理

## 2. 组织架构
– 应急响应小组：负责故障的应急处理
– 组长：负责整体协调和决策
– 技术专家：负责技术分析和处理
– 沟通协调：负责与相关方的沟通

## 3. 故障分级
– 轻微故障：影响范围小，对业务影响不大，风哥提示：。
– 中等故障：影响部分业务，需要及时处理
– 严重故障：影响核心业务，需要立即处理

## 4. 应急响应流程
– 故障检测与报告
– 故障评估与分级
– 应急响应启动
– 故障定位与分析
– 故障处理与恢复
– 故障验证与总结

## 5. 应急响应措施
– 单机故障：重启服务、故障转移
– 集群故障：切换到备集群、恢复服务
– 网络故障：检查网络连接、修复网络问题
– 数据损坏：使用备份恢复、数据修复

## 6. 资源准备
– 应急响应工具：诊断工具、备份工具
– 备用资源：备用服务器、备用网络
– 联系方式：相关人员的联系方式

## 7. 演练与培训
– 定期进行应急响应演练
– 培训应急响应人员
– 更新应急响应预案

## 8. 预案更新
– 根据实际情况定期更新预案
– 记录演练和实际故障处理的经验教训，学习交流加群风哥微信: itpux-com。

## 诊断工具
– obclient：命令行客户端，用于执行SQL语句
– ODC：OceanBase开发者中心，用于SQL执行和分析
– 日志分析工具：分析OceanBase日志
– 系统诊断工具：如top、vmstat、iostat等

## 备份恢复工具
– 物理备份工具：用于全量和增量备份
– 逻辑备份工具：用于数据导出和导入
– 恢复工具：用于数据恢复

## 网络工具
– ping：检查网络连接
– telnet：检查端口连通性
– traceroute：跟踪网络路径
– netstat：查看网络状态

## 系统工具
– ps：查看进程状态
– kill：终止进程
– df：查看磁盘空间
– free：查看内存使用情况

## 文档工具
– 应急响应预案：指导应急响应流程
– 故障处理手册：常见故障的处理方法
– 联系方式清单：相关人员的联系方式

## 准备工作
– 确保工具已安装并配置正确
– 准备应急响应所需的账号和权限
– 建立应急响应的沟通渠道，学习交流加群风哥QQ113257174。
– 定期检查工具的可用性

## 轻微故障
– 影响范围：单个节点或非核心业务
– 影响程度：业务运行正常，性能略有下降
– 处理策略：在不影响业务的情况下，安排时间处理
– 响应时间：24小时内

## 中等故障
– 影响范围：多个节点或部分核心业务
– 影响程度：业务运行受到影响，性能明显下降
– 处理策略：优先处理，减少对业务的影响
– 响应时间：4小时内

## 严重故障
– 影响范围：整个集群或核心业务
– 影响程度：业务无法正常运行
– 处理策略：立即处理，尽快恢复业务
– 响应时间：立即

## 处理策略
– 轻微故障：常规处理，记录问题
– 中等故障：组织技术人员处理，监控进展
– 严重故障：启动应急响应预案，成立应急小组，24小时处理

## 升级机制
– 轻微故障在规定时间内无法解决，升级为中等故障
– 中等故障在规定时间内无法解决，升级为严重故障
– 严重故障持续超过24小时，上报高层管理

## 1. 查看OceanBase日志
$ tail -f /ob/app/oceanbase/log/observer.log

## 2. 查看错误日志
$ grep -i error /ob/app/oceanbase/log/observer.log

## 3. 查看告警日志
$ grep -i alert /ob/app/oceanbase/log/observer.log

## 4. 查看慢SQL日志
$ grep -i slow /ob/app/oceanbase/log/observer.log

## 5. 查看网络相关日志
$ grep -i network /ob/app/oceanbase/log/observer.log

## 6. 查看存储相关日志
$ grep -i storage /ob/app/oceanbase/log/observer.log

## 7. 查看集群相关日志
$ grep -i cluster /ob/app/oceanbase/log/observer.log

## 1. 检查集群状态
$ obclient -h192.168.1.10 -P2881 -uroot@sys -p -e “SELECT svr_ip, svr_port, zone, status FROM oceanbase.__all_server;”

+—————-+———-+————+———-+
| svr_ip | svr_port | zone | status |
+—————-+———-+————+———-+
| 192.168.1.10 | 2882 | zone1 | ACTIVE |
| 192.168.1.11 | 2882 | zone2 | INACTIVE |，更多学习教程公众号风哥教程itpux_com。
| 192.168.1.12 | 2882 | zone3 | ACTIVE |
+—————-+———-+————+———-+

## 2. 检查租户状态
$ obclient -h192.168.1.10 -P2881 -uroot@sys -p -e “SELECT tenant_id, tenant_name, status FROM oceanbase.__all_tenant;”

+—————————-+————-+———-+
| tenant_id | tenant_name | status |
+—————————-+————-+———-+
| 1 | sys | NORMAL |
| 1001 | fgedudb | NORMAL |
+—————————-+————-+———-+

## 3. 检查服务器状态
$ obclient -h192.168.1.10 -P2881 -uroot@sys -p -e “SELECT svr_ip, cpu_usage, mem_usage, load FROM oceanbase.__all_virtual_server_stat;”

+—————-+———–+———–+——-+
| svr_ip | cpu_usage | mem_usage | load |
+—————-+———–+———–+——-+
| 192.168.1.10 | 30.00 | 40.00 | 1.0 |
| 192.168.1.12 | 25.00 | 35.00 | 0.8 |
+—————-+———–+———–+——-+

## 4. 检查存储状态
$ obclient -h192.168.1.10 -P2881 -uroot@sys -p -e “SELECT svr_ip, device_name, total_size/1024/1024/1024 as total_gb, used_size/1024/1024/1024 as used_gb, usage_percent FROM oceanbase.__all_virtual_disk_stat;”

+—————-+————–+———-+———-+—————+
| svr_ip | device_name | total_gb | used_gb | usage_percent |
+—————-+————–+———-+———-+—————+
| 192.168.1.10 | /ob/fgdata | 200.00 | 40.00 | 20.00 |，from DB视频:www.itpux.com。
| 192.168.1.12 | /ob/fgdata | 200.00 | 30.00 | 15.00 |
+—————-+————–+———-+———-+—————+

## 1. 故障检测与报告
– 监控系统发现告警
– 用户反馈业务异常
– 运维人员发现系统异常

## 2. 故障评估与分级
– 评估故障影响范围
– 评估故障严重程度
– 确定故障级别

## 3. 应急响应启动
– 轻微故障：常规处理
– 中等故障：组织技术人员处理
– 严重故障：启动应急响应预案，成立应急小组

## 4. 故障定位与分析
– 查看系统日志
– 检查系统状态
– 分析故障原因

## 5. 故障处理与恢复
– 制定处理方案
– 执行处理操作
– 恢复系统运行

## 6. 故障验证
– 验证系统是否恢复正常
– 验证业务是否正常运行
– 验证数据是否完整

## 7. 故障总结
– 分析故障原因
– 总结处理经验
– 提出改进措施

## 8. 预案更新
– 根据故障处理经验，更新应急响应预案
– 记录故障处理过程，形成案例库

## 1. 检查节点状态
$ obclient -h192.168.1.10 -P2881 -uroot@sys -p -e “SELECT svr_ip, svr_port, zone, status FROM oceanbase.__all_server;”

+—————-+———-+————+———-+
| svr_ip | svr_port | zone | status |
+—————-+———-+————+———-+
| 192.168.1.10 | 2882 | zone1 | ACTIVE |
| 192.168.1.11 | 2882 | zone2 | INACTIVE |
| 192.168.1.12 | 2882 | zone3 | ACTIVE |
+—————-+———-+————+———-+

## 2. 检查节点服务器状态
$ ssh root@192.168.1.11
# ps -ef | grep observer

## 3. 启动observer进程
# cd /ob/app/oceanbase/bin
# ./observer start

## 4. 验证节点状态
$ obclient -h192.168.1.10 -P2881 -uroot@sys -p -e “SELECT svr_ip, svr_port, zone, status FROM oceanbase.__all_server;”

+—————-+———-+————+———-+
| svr_ip | svr_port | zone | status |
+—————-+———-+————+———-+
| 192.168.1.10 | 2882 | zone1 | ACTIVE |
| 192.168.1.11 | 2882 | zone2 | ACTIVE |
| 192.168.1.12 | 2882 | zone3 | ACTIVE |
+—————-+———-+————+———-+

## 5. 检查数据同步状态
$ obclient -h192.168.1.10 -P2881 -uroot@sys -p -e “SELECT * FROM oceanbase.__all_virtual_tablet_replica WHERE svr_ip = ‘192.168.1.11’;”

## 6. 验证业务运行
$ obclient -h192.168.1.10 -P2881 -uroot@fgedudb -p -e “SELECT * FROM fgedu.t1 LIMIT 10;”

## 1. 确认数据损坏
$ obclient -h192.168.1.10 -P2881 -uroot@fgedudb -p -e “SELECT * FROM fgedu.t1 WHERE id = 1;”

ERROR 1064 (42000): You have an error in your SQL syntax; check the manual that corresponds to your OceanBase server version for the right syntax to use near ‘t1 WHERE id = 1’ at line 1

## 2. 检查备份状态
$ obclient -h192.168.1.10 -P2881 -uroot@fgedudb -p -e “SELECT job_id, tenant_name, job_type, status, start_time, end_time FROM oceanbase.CDB_OB_BACKUP_JOB_HISTORY ORDER BY job_id DESC LIMIT 5;”

+——–+————-+———+———-+———————+———————+———————+
| job_id | tenant_name | job_type | status | start_time | end_time | comment |
+——–+————-+———+———-+———————+———————+———————+
| 10001 | fgedudb | BACKUP | SUCCESS | 2026-04-08 20:00:00 | 2026-04-08 20:30:00 | Backup success |
| 10000 | fgedudb | BACKUP | SUCCESS | 2026-04-07 20:00:00 | 2026-04-07 20:15:00 | Backup success |
+——–+————-+———+———-+———————+———————+———————+

## 3. 恢复数据
$ obclient -h192.168.1.10 -P2881 -uroot@fgedudb -p -e “ALTER SYSTEM RESTORE TENANT fgedudb FROM ‘s3://backup-bucket/fgedudb’ UNTIL TIME ‘2026-04-08 19:00:00’;”

## 4. 验证数据恢复
$ obclient -h192.168.1.10 -P2881 -uroot@fgedudb -p -e “SELECT * FROM fgedu.t1 WHERE id = 1;”

+—-+——+
| id | name |
+—-+——+
| 1 | test |
+—-+——+

## 5. 验证业务运行
$ obclient -h192.168.1.10 -P2881 -uroot@fgedudb -p -e “INSERT INTO fgedu.t1 VALUES (2, ‘test2’);”

Query OK, 1 row affected (0.05 sec)

$ obclient -h192.168.1.10 -P2881 -uroot@fgedudb -p -e “SELECT * FROM fgedu.t1;”

+—-+——-+
| id | name |
+—-+——-+
| 1 | test |
| 2 | test2 |
+—-+——-+

## 故障描述
– 节点192.168.1.11突然离线
– 集群状态变为2/3节点在线
– 业务受到影响，部分请求失败

## 处理步骤

### 1. 故障检测与报告
– 监控系统告警：节点192.168.1.11状态异常
– 业务反馈：部分请求失败

### 2. 故障评估与分级
– 影响范围：1/3节点离线，部分业务受影响
– 严重程度：中等故障
– 处理策略：立即处理

### 3. 故障定位与分析
– 检查节点服务器状态：
$ ssh root@192.168.1.11
# ps -ef | grep observer
# 发现observer进程不存在

– 检查服务器资源：
# free -h
# 内存使用正常
# df -h
# 磁盘空间正常

– 检查系统日志：
# tail -f /var/log/messages
# 发现系统重启记录

### 4. 故障处理与恢复
– 启动observer进程：
# cd /ob/app/oceanbase/bin
# ./observer start

– 验证节点状态：
$ obclient -h192.168.1.10 -P2881 -uroot@sys -p -e “SELECT svr_ip, svr_port, zone, status FROM oceanbase.__all_server;”

+—————-+———-+————+———-+
| svr_ip | svr_port | zone | status |
+—————-+———-+————+———-+
| 192.168.1.10 | 2882 | zone1 | ACTIVE |
| 192.168.1.11 | 2882 | zone2 | ACTIVE |
| 192.168.1.12 | 2882 | zone3 | ACTIVE |
+—————-+———-+————+———-+

– 检查数据同步：
$ obclient -h192.168.1.10 -P2881 -uroot@sys -p -e “SELECT * FROM oceanbase.__all_virtual_tablet_replica WHERE svr_ip = ‘192.168.1.11’;”

### 5. 故障验证
– 验证业务运行：
$ obclient -h192.168.1.10 -P2881 -uroot@fgedudb -p -e “SELECT * FROM fgedu.t1 LIMIT 10;”
$ obclient -h192.168.1.10 -P2881 -uroot@fgedudb -p -e “INSERT INTO fgedu.t1 VALUES (3, ‘test3’);”

– 验证集群状态：
$ obclient -h192.168.1.10 -P2881 -uroot@sys -p -e “SELECT * FROM oceanbase.__all_server;”

### 6. 故障总结
– 故障原因：系统重启导致observer进程停止
– 处理方法：重启observer进程
– 预防措施：设置observer进程自启动，监控系统重启事件

## 经验教训
– 系统重启会导致observer进程停止，需要设置自启动
– 监控系统应及时发现节点离线情况
– 恢复后需要验证数据同步状态

## 故障描述
– 集群节点之间网络延迟增加
– 业务响应时间变长
– 部分请求超时

## 处理步骤

### 1. 故障检测与报告
– 监控系统告警：网络延迟增加
– 业务反馈：响应时间变长，部分请求超时

### 2. 故障评估与分级
– 影响范围：整个集群网络
– 严重程度：中等故障
– 处理策略：立即处理

### 3. 故障定位与分析
– 检查网络连接：
$ ping 192.168.1.11
PING 192.168.1.11 (192.168.1.11) 56(84) bytes of data.
64 bytes from 192.168.1.11: icmp_seq=1 ttl=64 time=100.2 ms
64 bytes from 192.168.1.11: icmp_seq=2 ttl=64 time=120.5 ms
# 正常延迟应小于1ms

– 检查网络状态：
$ netstat -s | grep retransmit
1000 retransmits

– 检查交换机状态：
# 登录交换机，检查端口状态

### 4. 故障处理与恢复
– 检查网络设备：
# 重启交换机
# 检查网络线缆

– 优化网络配置：
# 调整网络参数
$ sysctl -w net.core.netdev_max_backlog=10000
$ sysctl -w net.ipv4.tcp_slow_start_after_idle=0

– 验证网络状态：
$ ping 192.168.1.11
PING 192.168.1.11 (192.168.1.11) 56(84) bytes of data.
64 bytes from 192.168.1.11: icmp_seq=1 ttl=64 time=0.5 ms
64 bytes from 192.168.1.11: icmp_seq=2 ttl=64 time=0.6 ms

### 5. 故障验证
– 验证业务运行：
$ obclient -h192.168.1.10 -P2881 -uroot@fgedudb -p -e “SELECT * FROM fgedu.t1 LIMIT 10;”
# 响应时间恢复正常

– 验证集群状态：
$ obclient -h192.168.1.10 -P2881 -uroot@sys -p -e “SELECT svr_ip, svr_port, zone, status FROM oceanbase.__all_server;”

### 6. 故障总结
– 故障原因：交换机故障导致网络延迟增加
– 处理方法：重启交换机，优化网络配置
– 预防措施：定期检查网络设备状态，设置网络监控

## 经验教训
– 网络故障会严重影响OceanBase集群性能
– 及时发现和处理网络问题非常重要
– 定期检查网络设备状态，预防网络故障

## 故障描述
– 业务反馈：部分数据查询失败
– 数据库日志：出现数据损坏错误
– 影响范围：单个表的数据

## 处理步骤

### 1. 故障检测与报告
– 业务反馈：部分数据查询失败
– 数据库日志：出现数据损坏错误

### 2. 故障评估与分级
– 影响范围：单个表的数据
– 严重程度：中等故障
– 处理策略：立即处理

### 3. 故障定位与分析
– 检查错误日志：
$ grep -i corruption /ob/app/oceanbase/log/observer.log
2026-04-09 10:00:00 [ERROR] [ob_data_block.cpp:1234] [fgedu.t1] data corruption detected

– 验证数据损坏：
$ obclient -h192.168.1.10 -P2881 -uroot@fgedudb -p -e “SELECT * FROM fgedu.t1 WHERE id = 100;”
ERROR 1064 (42000): Data corruption detected

### 4. 故障处理与恢复
– 检查备份状态：
$ obclient -h192.168.1.10 -P2881 -uroot@fgedudb -p -e “SELECT job_id, tenant_name, job_type, status, start_time, end_time FROM oceanbase.CDB_OB_BACKUP_JOB_HISTORY ORDER BY job_id DESC LIMIT 5;”

+——–+————-+———+———-+———————+———————+———————+
| job_id | tenant_name | job_type | status | start_time | end_time | comment |
+——–+————-+———+———-+———————+———————+———————+
| 10001 | fgedudb | BACKUP | SUCCESS | 2026-04-08 20:00:00 | 2026-04-08 20:30:00 | Backup success |
+——–+————-+———+———-+———————+———————+———————+

– 恢复数据：
$ obclient -h192.168.1.10 -P2881 -uroot@fgedudb -p -e “ALTER SYSTEM RESTORE TENANT fgedudb FROM ‘s3://backup-bucket/fgedudb’ UNTIL TIME ‘2026-04-08 19:00:00’;”

### 5. 故障验证
– 验证数据恢复：
$ obclient -h192.168.1.10 -P2881 -uroot@fgedudb -p -e “SELECT * FROM fgedu.t1 WHERE id = 100;”
+—–+———+
| id | name |
+—–+———+
| 100 | test100 |
+—–+———+

– 验证业务运行：
$ obclient -h192.168.1.10 -P2881 -uroot@fgedudb -p -e “INSERT INTO fgedu.t1 VALUES (101, ‘test101’);”
Query OK, 1 row affected (0.05 sec)

### 6. 故障总结
– 故障原因：数据文件损坏
– 处理方法：使用备份恢复数据
– 预防措施：定期进行备份验证，监控数据文件状态

## 经验教训
– 数据损坏是严重的故障，需要及时处理
– 定期备份和验证备份的完整性非常重要
– 建立数据恢复的应急预案，确保在数据损坏时能够快速恢复

## 1. 故障分析
– 分析故障原因：硬件、软件、网络、人为等
– 分析故障处理过程：处理步骤、时间、效果
– 分析故障影响：业务影响、数据影响、用户影响

## 2. 经验教训总结
– 识别系统弱点：硬件、软件、流程等
– 总结处理经验：成功的处理方法、失败的教训
– 制定改进措施：技术改进、流程改进、人员培训

## 3. 系统改进
– 硬件改进：升级硬件、增加冗余
– 软件改进：应用补丁、优化配置
– 流程改进：完善操作流程、加强监控
– 人员培训：提高操作技能、应急响应能力

## 4. 预案更新
– 根据故障处理经验，更新应急响应预案
– 补充新的故障类型和处理方法
– 定期演练，验证预案的有效性

## 5. 知识管理
– 建立故障案例库：记录故障处理过程和经验
– 分享故障处理经验：内部培训、技术分享
– 持续学习：关注行业动态，学习新的故障处理方法

## 6. 预防措施
– 加强监控：增加监控点，提高监控频率
– 定期检查：定期进行系统检查，发现潜在问题
– 备份策略：完善备份策略，确保数据安全
– 容灾方案：建立容灾系统，提高系统可用性