OceanBase教程FG061-OceanBase数据损坏恢复实战

本文档风哥主要介绍OceanBase数据库数据损坏恢复相关知识，包括OceanBase数据损坏类型、OceanBase数据损坏原因、OceanBase数据损坏预防、OceanBase损坏检测方法、OceanBase轻微损坏恢复、OceanBase严重损坏恢复等内容，风哥教程参考OceanBase官方文档数据恢复、故障处理等内容编写，适合DBA人员在学习和测试中使用，如果要应用于生产环境则需要自行确认。

Part01-基础概念与理论知识

1.1 OceanBase数据损坏类型

OceanBase数据库可能遇到多种类型的数据损坏，了解损坏类型有助于选择合适的恢复方法。更多视频教程www.fgedu.net.cn

OceanBase数据损坏类型：

物理损坏：存储介质故障导致的数据损坏
逻辑损坏：软件Bug或操作错误导致的数据不一致
元数据损坏：系统表或元数据损坏
副本不一致：多副本之间数据不一致
校验和失败：数据校验和不匹配

1.2 OceanBase数据损坏原因

# 数据损坏原因

1. 硬件故障
– 磁盘坏道
– 内存错误
– 电源故障
– 网络丢包

2. 软件故障
– 操作系统崩溃
– 数据库Bug
– 存储引擎故障
– 文件系统损坏

3. 人为因素
– 误操作
– 强制关机
– 错误配置
– 不当维护

4. 外部因素
– 病毒攻击
– 恶意破坏
– 自然灾害
– 电力中断

1.3 OceanBase数据损坏预防

# 数据损坏预防

1. 硬件层面
– 使用RAID磁盘阵列
– 使用ECC内存
– 配置UPS电源
– 冗余网络链路

2. 软件层面
– 定期更新补丁
– 启用数据校验
– 配置多副本
– 定期健康检查

3. 运维层面
– 规范操作流程
– 定期备份数据
– 监控告警
– 灾难演练

4. 架构层面
– 多副本部署
– 跨机房部署
– 读写分离
– 定期切换演练

风哥提示：数据损坏预防比恢复更重要，建立完善的数据保护机制可以有效降低数据损坏风险。

Part02-生产环境规划与建议

2.1 OceanBase损坏检测策略

# 损坏检测策略

1. 定期检测
– 每日数据校验
– 每周完整性检查
– 每月全量校验

2. 实时监控
– 校验和监控
– 副本一致性监控
– 错误日志监控
– 性能异常监控

3. 检测工具
– OBCheck工具
– 系统视图查询
– 日志分析
– 第三方工具

4. 检测指标
– 校验和失败次数
– 副本不一致数量
– 错误日志数量
– 异常查询数量

2.2 OceanBase恢复策略

# 恢复策略

1. 轻微损坏恢复
– 使用副本修复
– 在线数据修复
– 自动恢复机制

2. 严重损坏恢复
– 从备份恢复
– 重建表/分区
– 数据导入导出

3. 元数据损坏恢复
– 系统表修复，风哥提示：。
– 从备份恢复
– 重建租户

4. 灾难恢复
– 异地灾备切换
– 全量备份恢复
– 日志回放恢复

2.3 OceanBase备份策略

# 备份策略

1. 备份类型
– 物理备份：数据文件备份
– 逻辑备份：SQL导出
– 增量备份：差异备份
– 归档备份：日志备份

2. 备份频率
– 全量备份：每周一次
– 增量备份：每天一次
– 日志备份：实时备份

3. 备份验证
– 定期恢复测试
– 数据一致性校验
– 备份可用性检查，学习交流加群风哥微信: itpux-com。

4. 备份保留
– 本地：7天
– 异地：30天
– 归档：1年

生产环境建议：建立完善的数据保护体系，定期检测数据完整性，确保备份可用。学习交流加群风哥微信: itpux-com

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

3.1 OceanBase损坏检测方法

3.1.1 使用系统视图检测

# 使用系统视图检测数据损坏

1. 检查副本一致性
$ obclient -h192.168.1.101 -P2881 -uroot@sys -p -e ”
SELECT
table_id,
partition_id,
COUNT(*) as replica_count,
COUNT(DISTINCT data_checksum) as checksum_count
FROM oceanbase.__all_virtual_proxy_schema
GROUP BY table_id, partition_id
HAVING checksum_count > 1;
”

2. 检查校验和失败
$ obclient -h192.168.1.101 -P2881 -uroot@sys -p -e ”
SELECT
svr_ip,
svr_port,
table_id,
partition_id,
data_checksum,
row_checksum
FROM oceanbase.__all_virtual_proxy_schema，学习交流加群风哥QQ113257174。
WHERE data_checksum = 0 OR row_checksum = 0;
”

3. 检查宏块状态
$ obclient -h192.168.1.101 -P2881 -uroot@sys -p -e ”
SELECT
svr_ip,
svr_port,
macro_block_id,
checksum,
status
FROM oceanbase.__all_virtual_sstable_macro_info
WHERE status != ‘VALID’;
”

4. 检查微块状态
$ obclient -h192.168.1.101 -P2881 -uroot@sys -p -e ”
SELECT
svr_ip,
svr_port,
micro_block_id,
checksum,
status
FROM oceanbase.__all_virtual_sstable_micro_info
WHERE status != ‘VALID’;
”

3.1.2 使用OBCheck工具

# 使用OBCheck工具检测

1. 安装OBCheck
$ cd /ob/app/oceanbase/tools
$ ./obcheck –version
OBCheck version 4.2.1

2. 执行数据校验
$ ./obcheck –host=192.168.1.101 –port=2881 –user=root@sys –password=****** check-data，更多视频教程www.fgedu.net.cn。

[2024-01-20 10:00:00] INFO: Starting data check…
[2024-01-20 10:00:10] INFO: Checking table: fgedudb.fgedu_order
[2024-01-20 10:00:15] INFO: Table fgedudb.fgedu_order: OK
[2024-01-20 10:00:20] INFO: Checking table: fgedudb.fgedu_user
[2024-01-20 10:00:25] WARN: Table fgedudb.fgedu_user: Checksum mismatch found
[2024-01-20 10:00:30] INFO: Data check completed

3. 执行副本一致性检查
$ ./obcheck –host=192.168.1.101 –port=2881 –user=root@sys –password=****** check-replica

[2024-01-20 10:00:00] INFO: Starting replica check…
[2024-01-20 10:00:05] INFO: Checking partition: 12345
[2024-01-20 10:00:10] WARN: Partition 12345: Replica inconsistent
[2024-01-20 10:00:15] INFO: Replica check completed

4. 生成检查报告
$ ./obcheck –host=192.168.1.101 –port=2881 –user=root@sys –password=****** –report=check_report.html

Report generated: check_report.html

3.2 OceanBase轻微损坏恢复

# 轻微损坏恢复

1. 副本修复
$ obclient -h192.168.1.101 -P2881 -uroot@sys -p -e ”
— 修复指定分区的副本
ALTER SYSTEM REPAIR PARTITION ‘12345’ SERVER ‘192.168.1.102:2882’;
”

2. 重新平衡副本
$ obclient -h192.168.1.101 -P2881 -uroot@sys -p -e ”
— 触发副本重新平衡
ALTER SYSTEM MIGRATE REPLICA
PARTITION_ID = 12345
SOURCE = ‘192.168.1.102:2882’
DESTINATION = ‘192.168.1.103:2882’;
“，更多学习教程公众号风哥教程itpux_com。

3. 重建索引
$ obclient -h192.168.1.101 -P2881 -uroot@fgedu_tenant -p -e ”
— 重建损坏的索引
ALTER INDEX fgedu_idx_order_date ON fgedudb.fgedu_order REBUILD;
”

4. 修复统计信息
$ obclient -h192.168.1.101 -P2881 -uroot@fgedu_tenant -p -e ”
— 重新收集统计信息
CALL DBMS_STATS.GATHER_TABLE_STATS(‘fgedudb’, ‘fgedu_order’);
”

3.3 OceanBase严重损坏恢复

# 严重损坏恢复

1. 从备份恢复表
$ obclient -h192.168.1.101 -P2881 -uroot@fgedu_tenant -p -e ”
— 删除损坏的表
DROP TABLE IF EXISTS fgedudb.fgedu_order_corrupted;

— 从备份恢复
SOURCE /backup/fgedudb_fgedu_order_backup.sql;
”

2. 使用闪回恢复
$ obclient -h192.168.1.101 -P2881 -uroot@fgedu_tenant -p -e “，from DB视频:www.itpux.com。
— 闪回表到指定时间点
FLASHBACK TABLE fgedudb.fgedu_order TO TIMESTAMP ‘2024-01-20 09:00:00’;
”

3. 重建表
$ obclient -h192.168.1.101 -P2881 -uroot@fgedu_tenant -p -e ”
— 创建新表
CREATE TABLE fgedudb.fgedu_order_new AS SELECT * FROM fgedudb.fgedu_order WHERE 1=0;

— 从备份导入数据
LOAD DATA INFILE ‘/backup/fgedu_order_data.csv’ INTO TABLE fgedudb.fgedu_order_new;

— 重命名表
RENAME TABLE fgedudb.fgedu_order TO fgedudb.fgedu_order_old;
RENAME TABLE fgedudb.fgedu_order_new TO fgedudb.fgedu_order;

— 删除旧表
DROP TABLE fgedudb.fgedu_order_old;
”

4. 从物理备份恢复
# 停止OBServer
$ cd /ob/app/oceanbase
$ ./bin/observer -stop

# 恢复数据文件
$ cp /backup/data/fgedudb/* /ob/fgdata/sstable/

# 启动OBServer
$ ./bin/observer -start

# 验证恢复
$ obclient -h192.168.1.101 -P2881 -uroot@fgedu_tenant -p -e ”
SELECT COUNT(*) FROM fgedudb.fgedu_order;
”

风哥提示：严重损坏恢复需要谨慎操作，建议先在测试环境验证恢复流程，确保恢复成功后再在生产环境执行。学习交流加群风哥QQ113257174

Part04-生产案例与实战讲解

4.1 OceanBase校验和失败案例

# 故障现象
– 查询表时报错：checksum mismatch
– 日志显示数据校验失败
– 业务查询受到影响

# 排查过程

1. 查看错误日志
$ tail -100 /ob/fgdata/log/observer.log | grep checksum
[2024-01-20 10:00:00.123456] ERROR [STORAGE] check_data_checksum (ob_macro_block.cpp:456) [12345]
[lt=0] [dc=0] data checksum mismatch, macro_block_id=12345, expected=67890, actual=67891

2. 定位损坏位置
$ obclient -h192.168.1.101 -P2881 -uroot@sys -p -e ”
SELECT
svr_ip,
svr_port,
macro_block_id,
table_id,
partition_id
FROM oceanbase.__all_virtual_sstable_macro_info
WHERE macro_block_id = 12345;
”

+—————+———-+—————-+———-+—————+
| svr_ip | svr_port | macro_block_id | table_id | partition_id |
+—————+———-+—————-+———-+—————+
| 192.168.1.102 | 2882 | 12345 | 10001 | 20001 |
+—————+———-+—————-+———-+—————+

3. 检查副本状态
$ obclient -h192.168.1.101 -P2881 -uroot@sys -p -e ”
SELECT
svr_ip,
svr_port,
role,
data_checksum
FROM oceanbase.__all_virtual_proxy_schema
WHERE table_id = 10001 AND partition_id = 20001;
”

+—————+———-+——+—————+
| svr_ip | svr_port | role | data_checksum |
+—————+———-+——+—————+
| 192.168.1.101 | 2882 | LEADER | 67890 |
| 192.168.1.102 | 2882 | FOLLOWER | 67891 |
| 192.168.1.103 | 2882 | FOLLOWER | 67890 |
+—————+———-+——+—————+

4. 修复损坏副本
$ obclient -h192.168.1.101 -P2881 -uroot@sys -p -e ”
— 删除损坏的副本
ALTER SYSTEM DELETE REPLICA
PARTITION_ID = 20001
SERVER = ‘192.168.1.102:2882’;

— 等待副本重新生成
”

5. 验证修复
$ obclient -h192.168.1.101 -P2881 -uroot@sys -p -e ”
SELECT
svr_ip,
data_checksum
FROM oceanbase.__all_virtual_proxy_schema
WHERE table_id = 10001 AND partition_id = 20001;
”

+—————+—————+
| svr_ip | data_checksum |
+—————+—————+
| 192.168.1.101 | 67890 |
| 192.168.1.102 | 67890 |
| 192.168.1.103 | 67890 |
+—————+—————+

# 修复完成

4.2 OceanBase副本损坏案例

# 故障现象
– 某节点磁盘故障
– 该节点上多个副本损坏
– 需要修复副本

# 恢复过程

1. 检查损坏范围
$ obclient -h192.168.1.101 -P2881 -uroot@sys -p -e ”
SELECT
svr_ip,
COUNT(*) as damaged_replicas
FROM oceanbase.__all_virtual_proxy_schema
WHERE svr_ip = ‘192.168.1.102’
AND (data_checksum = 0 OR status != ‘VALID’)
GROUP BY svr_ip;
”

+—————+——————+
| svr_ip | damaged_replicas |
+—————+——————+
| 192.168.1.102 | 50 |
+—————+——————+

2. 停止故障节点
$ ssh admin@192.168.1.102
$ cd /ob/app/oceanbase
$ ./bin/observer -stop

3. 更换磁盘
# 联系硬件工程师更换磁盘
# 格式化新磁盘
$ mkfs.ext4 /dev/sdb
$ mount /dev/sdb /ob/fgdata

4. 重新部署节点
$ cd /ob/app/oceanbase
$ ./bin/observer -i eth0 -p 2881 -P 2882 -z zone2 -c 1 -d /ob/fgdata \
-r ‘192.168.1.101:2882:2881;192.168.1.102:2882:2881;192.168.1.103:2882:2881’ \
-o ‘memory_limit=100G’

5. 等待副本恢复
$ obclient -h192.168.1.101 -P2881 -uroot@sys -p -e ”
SELECT
svr_ip,
COUNT(*) as total_replicas,
SUM(CASE WHEN is_restore = 1 THEN 1 ELSE 0 END) as restoring
FROM oceanbase.__all_virtual_proxy_schema
WHERE svr_ip = ‘192.168.1.102’
GROUP BY svr_ip;
”

+—————+—————-+———–+
| svr_ip | total_replicas | restoring |
+—————+—————-+———–+
| 192.168.1.102 | 500 | 50 |
+—————+—————-+———–+

# 等待restoring变为0

6. 验证恢复
$ obclient -h192.168.1.101 -P2881 -uroot@sys -p -e ”
SELECT
svr_ip,
status,
start_service_time
FROM oceanbase.__all_server
WHERE svr_ip = ‘192.168.1.102’;
”

+—————+——–+———————+
| svr_ip | status | start_service_time |
+—————+——–+———————+
| 192.168.1.102 | active | 2024-01-20 11:00:00 |
+—————+——–+———————+

# 恢复完成

4.3 OceanBase表损坏案例

# 故障现象
– 查询表时返回错误结果
– 表数据不一致
– 需要重建表

# 恢复过程

1. 检查表状态
$ obclient -h192.168.1.101 -P2881 -uroot@fgedu_tenant -p -e ”
CHECK TABLE fgedudb.fgedu_order;
”

2. 备份损坏的表
$ obclient -h192.168.1.101 -P2881 -uroot@fgedu_tenant -p -e ”
— 尝试导出可用数据
SELECT * INTO OUTFILE ‘/backup/fgedu_order_rescue.csv’
FROM fgedudb.fgedu_order
WHERE create_time > ‘2024-01-01’;
”

3. 从备份恢复
$ obclient -h192.168.1.101 -P2881 -uroot@fgedu_tenant -p -e ”
— 重命名损坏的表
RENAME TABLE fgedudb.fgedu_order TO fgedudb.fgedu_order_corrupted;

— 从备份创建新表
SOURCE /backup/fgedudb_fgedu_order_backup.sql;
”

4. 恢复增量数据
$ obclient -h192.168.1.101 -P2881 -uroot@fgedu_tenant -p -e ”
— 从归档日志恢复数据
— 或使用闪回查询恢复
INSERT INTO fgedudb.fgedu_order
SELECT * FROM fgedudb.fgedu_order_corrupted
AS OF TIMESTAMP ‘2024-01-20 09:00:00’
WHERE create_time > ‘2024-01-19 00:00:00’;
”

5. 验证数据
$ obclient -h192.168.1.101 -P2881 -uroot@fgedu_tenant -p -e ”
— 检查数据量
SELECT COUNT(*) FROM fgedudb.fgedu_order;

— 检查数据一致性
SELECT
order_status,
COUNT(*) as cnt,
SUM(order_amount) as total_amount
FROM fgedudb.fgedu_order
GROUP BY order_status;

— 删除损坏的表
DROP TABLE fgedudb.fgedu_order_corrupted;
”

# 恢复完成

生产环境建议：数据损坏恢复需要谨慎操作，建议先在测试环境验证恢复流程，确保数据完整性。更多学习教程公众号风哥教程itpux_com

Part05-风哥经验总结与分享

5.1 OceanBase数据损坏恢复最佳实践

# 数据损坏恢复最佳实践

1. 预防措施
– 多副本部署
– 定期数据校验
– 及时更新补丁
– 硬件冗余配置

2. 检测机制
– 定期完整性检查
– 实时监控告警
– 自动修复机制
– 日志分析

3. 恢复流程
– 快速定位损坏
– 评估影响范围
– 选择恢复方案
– 验证恢复结果

4. 备份策略
– 定期全量备份
– 实时日志备份
– 异地备份存储
– 定期恢复演练

5. 应急响应
– 建立应急团队
– 制定恢复预案
– 定期演练
– 持续改进

5.2 OceanBase损坏排查方法

# 损坏排查方法

1. 日志分析
# 查看错误日志
grep -i ‘corrupt\|checksum\|error’ /ob/fgdata/log/observer.log

# 查看警告日志
grep -i ‘warn’ /ob/fgdata/log/observer.log

2. 系统视图查询
# 检查副本状态
SELECT * FROM oceanbase.__all_virtual_proxy_schema WHERE status != ‘VALID’;

# 检查宏块状态
SELECT * FROM oceanbase.__all_virtual_sstable_macro_info WHERE status != ‘VALID’;

3. 工具检测
# 使用OBCheck
./obcheck check-data
./obcheck check-replica

4. 数据验证
# 检查表数据
CHECK TABLE table_name;

# 分析表
ANALYZE TABLE table_name;

5.3 OceanBase损坏恢复常见问题

# 损坏恢复常见问题及解决

Q1: 如何检测数据损坏？
A1: 使用OBCheck工具、查询系统视图、分析错误日志

Q2: 副本损坏如何处理？
A2: 删除损坏副本，等待自动重建，或手动迁移副本

Q3: 表损坏如何恢复？
A3: 从备份恢复、使用闪回、重建表

Q4: 元数据损坏如何处理？
A4: 从备份恢复、重建租户、联系技术支持

Q5: 如何预防数据损坏？
A5: 多副本、定期校验、硬件冗余、及时更新

Q6: 损坏恢复需要多长时间？
A6: 取决于损坏范围，轻微损坏几分钟，严重损坏几小时

Q7: 恢复后如何验证数据完整性？
A7: 对比数据量、校验数据校验和、运行测试查询

Q8: 备份损坏如何处理？
A8: 使用其他备份、使用日志恢复、联系技术支持

Q9: 可以在线修复数据损坏吗？
A9: 轻微损坏可以在线修复，严重损坏需要停服修复

Q10: 损坏恢复会影响业务吗？
A10: 轻微修复不影响，严重恢复需要停服

风哥提示：数据损坏恢复是DBA的核心技能，需要熟练掌握各种恢复场景和操作流程。建议定期进行恢复演练，确保在紧急情况下能够快速响应。from OceanBase视频:www.itpux.com

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