OceanBase 数据库级恢复

数据库级恢复是指将整个数据库恢复到指定时间点或指定备份集的过程，主要分为物理恢复和逻辑恢复两种类型，适用于数据库损坏、数据误操作、系统故障、版本升级失败和数据迁移等场景。

物理恢复

恢复前准备

检查备份集

bash

# 查看备份集列表
obbackup list --backup_dest=oss://backup-bucket/ob-backup

# 验证备份集完整性
obbackup validate --backup_dest=oss://backup-bucket/ob-backup --backup_set_name=full_backup_20231001

检查目标环境

bash

# 检查目标集群状态
obclient -h127.0.0.1 -P2881 -uroot -p -c -A oceanbase -e "SHOW CLUSTER STATUS;"

# 检查目标数据库状态
obclient -h127.0.0.1 -P2881 -uroot -p -c -A oceanbase -e "SHOW DATABASES;"

# 检查目标目录
mkdir -p /data/ob-recovery
chown -R oceanbase:oceanbase /data/ob-recovery

全量恢复

恢复命令

bash

obbackup restore --cluster=obcluster --database=dbname --backup_dest=oss://backup-bucket/ob-backup --backup_set_name=full_backup_20231001 --restore_path=/data/ob-recovery

恢复示例

bash

# 全量恢复数据库
obbackup restore --cluster=obcluster --database=employees --backup_dest=oss://backup-bucket/ob-backup --backup_set_name=employees_full_backup_20231001 --restore_path=/data/ob-recovery --parallel=16

增量恢复

恢复命令

bash

obbackup restore --cluster=obcluster --database=dbname --backup_dest=oss://backup-bucket/ob-backup --backup_set_name=incr_backup_20231002 --base_backup_set=full_backup_20231001 --restore_path=/data/ob-recovery

恢复示例

bash

# 增量恢复数据库
obbackup restore --cluster=obcluster --database=employees --backup_dest=oss://backup-bucket/ob-backup --backup_set_name=employees_incr_backup_20231002 --base_backup_set=employees_full_backup_20231001 --restore_path=/data/ob-recovery --parallel=16

PITR 恢复

恢复命令

bash

obbackup restore --cluster=obcluster --database=dbname --backup_dest=oss://backup-bucket/ob-backup --backup_set_name=full_backup_20231001 --recovery_time='2023-10-02 14:30:00' --restore_path=/data/ob-recovery

恢复示例

bash

# PITR 恢复数据库到指定时间点
obbackup restore --cluster=obcluster --database=employees --backup_dest=oss://backup-bucket/ob-backup --backup_set_name=employees_full_backup_20231001 --recovery_time='2023-10-02 14:30:00' --restore_path=/data/ob-recovery --parallel=16

# PITR 恢复数据库到指定 LSN
obbackup restore --cluster=obcluster --database=employees --backup_dest=oss://backup-bucket/ob-backup --backup_set_name=employees_full_backup_20231001 --recovery_lsn=1500000000 --restore_path=/data/ob-recovery --parallel=16

逻辑恢复

恢复前准备

检查备份文件

bash

# 检查备份文件完整性
md5sum employees_backup.sql
md5sum employees_backup.sql.md5

# 查看备份文件大小
du -h employees_backup.sql

检查目标环境

bash

# 检查目标数据库是否存在
obclient -h127.0.0.1 -P2881 -uroot -p -c -A oceanbase -e "SHOW DATABASES LIKE 'employees';"

# 如果数据库不存在，创建数据库
obclient -h127.0.0.1 -P2881 -uroot -p -c -A oceanbase -e "CREATE DATABASE IF NOT EXISTS employees;"

# 授予权限
obclient -h127.0.0.1 -P2881 -uroot -p -c -A oceanbase -e "GRANT ALL PRIVILEGES ON employees.* TO 'user'@'%';"

全量恢复

恢复命令

bash

obclient -h127.0.0.1 -P2881 -uroot -p -c -A employees < employees_backup.sql

恢复示例

bash

# 全量恢复数据库
obclient -h127.0.0.1 -P2881 -uroot -p -c -A employees < employees_full_backup_20231001.sql

# 使用 mysql 客户端恢复
mysql -h127.0.0.1 -P2881 -uroot -p -c -A employees < employees_full_backup_20231001.sql

增量恢复

恢复命令

bash

# 恢复全量备份
obclient -h127.0.0.1 -P2881 -uroot -p -c -A employees < employees_full_backup_20231001.sql

# 恢复增量备份
obclient -h127.0.0.1 -P2881 -uroot -p -c -A employees < employees_incr_backup_20231002.sql

恢复示例

bash

# 恢复全量备份
obclient -h127.0.0.1 -P2881 -uroot -p -c -A employees < employees_full_backup_20231001.sql

# 恢复二进制日志
mysqlbinlog binlog.000001 | obclient -h127.0.0.1 -P2881 -uroot -p -c -A employees

恢复后验证

数据完整性验证

sql

-- 检查表行数
SELECT COUNT(*) FROM employees.employees;

-- 检查索引完整性
SELECT * FROM INFORMATION_SCHEMA.STATISTICS WHERE TABLE_SCHEMA = 'employees';

-- 检查数据一致性
SELECT * FROM employees.employees WHERE employee_id = 1;

数据库状态验证

sql

-- 检查数据库状态
SHOW DATABASES LIKE 'employees';

-- 检查表状态
SHOW TABLES FROM employees;

-- 检查数据库权限
SHOW GRANTS FOR 'user'@'%';

业务功能验证

执行业务查询，验证数据正确性
执行业务更新，验证数据库可写
执行业务删除，验证数据库功能正常
执行业务插入，验证数据库功能正常

恢复最佳实践

恢复策略设计

物理恢复策略

恢复时间目标（RTO）：根据业务需求设置，一般要求在 4 小时内完成恢复
恢复点目标（RPO）：根据业务需求设置，一般要求在 15 分钟内
备份集保留：保留至少 7 天的全量备份和 30 天的增量备份
恢复测试：每月执行一次恢复测试，验证备份集可用性

逻辑恢复策略

恢复时间目标（RTO）：根据业务需求设置，一般要求在 8 小时内完成恢复
恢复点目标（RPO）：根据业务需求设置，一般要求在 1 小时内
备份集保留：保留至少 7 天的逻辑备份
恢复测试：每周执行一次恢复测试，验证备份集可用性

恢复性能优化

物理恢复优化

bash

# 使用并行恢复
obbackup restore --cluster=obcluster --database=employees --backup_dest=oss://backup-bucket/ob-backup --backup_set_name=employees_full_backup_20231001 --restore_path=/data/ob-recovery --parallel=16

# 使用直接恢复
obbackup restore --cluster=obcluster --database=employees --backup_dest=oss://backup-bucket/ob-backup --backup_set_name=employees_full_backup_20231001 --restore_path=/data/ob/data --direct

逻辑恢复优化

bash

# 使用 --quick 参数
obclient --quick -h127.0.0.1 -P2881 -uroot -p -c -A employees < employees_backup.sql

# 使用 --max-allowed-packet 参数
obclient --max-allowed-packet=1G -h127.0.0.1 -P2881 -uroot -p -c -A employees < employees_backup.sql

# 使用 mysqlimport 导入数据
mysqlimport --local -h127.0.0.1 -P2881 -uroot -p employees employees_data.txt

恢复脚本自动化

物理恢复脚本

bash

#!/bin/bash

# 配置参数
CLUSTER=obcluster
DATABASE=employees
BACKUP_DEST=oss://backup-bucket/ob-backup
BACKUP_SET=employees_full_backup_20231001
RESTORE_PATH=/data/ob-recovery
PARALLEL=16

# 日志文件
LOG_FILE=/home/oceanbase/restore.log

# 开始恢复
echo "$(date +"%Y-%m-%d %H:%M:%S") 开始恢复数据库 $DATABASE" >> $LOG_FILE

# 执行恢复
obbackup restore --cluster=$CLUSTER --database=$DATABASE --backup_dest=$BACKUP_DEST --backup_set_name=$BACKUP_SET --restore_path=$RESTORE_PATH --parallel=$PARALLEL >> $LOG_FILE 2>&1

# 检查恢复结果
if [ $? -eq 0 ]; then
    echo "$(date +"%Y-%m-%d %H:%M:%S") 数据库 $DATABASE 恢复成功" >> $LOG_FILE
else
    echo "$(date +"%Y-%m-%d %H:%M:%S") 数据库 $DATABASE 恢复失败" >> $LOG_FILE
    exit 1
fi

# 验证恢复结果
echo "$(date +"%Y-%m-%d %H:%M:%S") 开始验证数据库 $DATABASE" >> $LOG_FILE
obclient -h127.0.0.1 -P2881 -uroot -p -c -A $DATABASE -e "SELECT COUNT(*) FROM employees;" >> $LOG_FILE 2>&1

if [ $? -eq 0 ]; then
    echo "$(date +"%Y-%m-%d %H:%M:%S") 数据库 $DATABASE 验证成功" >> $LOG_FILE
else
    echo "$(date +"%Y-%m-%d %H:%M:%S") 数据库 $DATABASE 验证失败" >> $LOG_FILE
    exit 1
fi

echo "$(date +"%Y-%m-%d %H:%M:%S") 数据库 $DATABASE 恢复完成" >> $LOG_FILE

逻辑恢复脚本

bash

#!/bin/bash

# 配置参数
DATABASE=employees
BACKUP_FILE=employees_full_backup_20231001.sql
USER=root
PASSWORD=password
HOST=127.0.0.1
PORT=2881

# 日志文件
LOG_FILE=/home/oceanbase/restore.log

# 开始恢复
echo "$(date +"%Y-%m-%d %H:%M:%S") 开始恢复数据库 $DATABASE" >> $LOG_FILE

# 执行恢复
obclient --quick --max-allowed-packet=1G -h$HOST -P$PORT -u$USER -p$PASSWORD -c -A $DATABASE < $BACKUP_FILE >> $LOG_FILE 2>&1

# 检查恢复结果
if [ $? -eq 0 ]; then
    echo "$(date +"%Y-%m-%d %H:%M:%S") 数据库 $DATABASE 恢复成功" >> $LOG_FILE
else
    echo "$(date +"%Y-%m-%d %H:%M:%S") 数据库 $DATABASE 恢复失败" >> $LOG_FILE
    exit 1
fi

# 验证恢复结果
echo "$(date +"%Y-%m-%d %H:%M:%S") 开始验证数据库 $DATABASE" >> $LOG_FILE
obclient -h$HOST -P$PORT -u$USER -p$PASSWORD -c -A $DATABASE -e "SELECT COUNT(*) FROM employees;" >> $LOG_FILE 2>&1

if [ $? -eq 0 ]; then
    echo "$(date +"%Y-%m-%d %H:%M:%S") 数据库 $DATABASE 验证成功" >> $LOG_FILE
else
    echo "$(date +"%Y-%m-%d %H:%M:%S") 数据库 $DATABASE 验证失败" >> $LOG_FILE
    exit 1
fi

echo "$(date +"%Y-%m-%d %H:%M:%S") 数据库 $DATABASE 恢复完成" >> $LOG_FILE

恢复案例

案例一：物理恢复

场景：数据库服务器磁盘损坏，需要将数据库恢复到新服务器

步骤：

安装 OceanBase 集群
配置备份存储
执行物理恢复
验证恢复结果
恢复业务

结果：恢复时间 2 小时，数据完整性 100%，业务中断时间 2.5 小时

案例二：逻辑恢复

场景：误删除表数据，需要将表恢复到指定时间点

步骤：

恢复全量备份
恢复增量备份
恢复二进制日志到指定时间点
验证恢复结果
恢复业务

结果：恢复时间 30 分钟，数据完整性 100%，业务中断时间 45 分钟

常见问题（FAQ）

Q1: 物理恢复和逻辑恢复有什么区别？

A1: 物理恢复和逻辑恢复的主要区别：

恢复速度：物理恢复速度快，逻辑恢复速度慢
适用场景：物理恢复适合大规模数据库，逻辑恢复适合小规模数据库
恢复粒度：物理恢复是数据库级恢复，逻辑恢复可以是表级恢复
恢复灵活性：逻辑恢复更灵活，可以选择性恢复表或数据

Q2: 如何选择合适的恢复方式？

A2: 选择恢复方式的依据：

数据库大小：TB 级以上数据库建议使用物理恢复
恢复时间要求：要求恢复时间短的场景使用物理恢复
恢复灵活性要求：要求选择性恢复的场景使用逻辑恢复
备份集类型：只有物理备份集时使用物理恢复，只有逻辑备份集时使用逻辑恢复

Q3: 恢复过程中遇到错误怎么办？

A3: 恢复过程中遇到错误的处理方法：

查看错误信息
分析错误原因
修复错误
重新执行恢复
如果无法修复，尝试使用其他备份集

Q4: 如何提高恢复速度？

A4: 提高恢复速度的方法：

使用并行恢复
使用高性能存储
优化恢复参数
减少恢复数据量
使用增量恢复

Q5: 恢复后数据库无法启动怎么办？

A5: 恢复后数据库无法启动的处理方法：

查看数据库日志
分析启动失败原因
修复数据库配置
重新启动数据库
如果无法修复，重新执行恢复

Q6: 如何验证恢复结果？

A6: 验证恢复结果的方法：

检查表行数
检查索引完整性
执行业务查询
执行业务更新
检查数据库状态

Q7: 恢复过程中需要注意什么？

A7: 恢复过程中需要注意的事项：

确保备份集完整有效
确保目标环境符合要求
执行恢复前备份当前数据
监控恢复进度
验证恢复结果
恢复后更新数据库统计信息

Q8: 如何实现自动化恢复？

A8: 实现自动化恢复的方法：

编写恢复脚本
使用 crontab 定时执行
使用监控工具触发恢复
使用 OCP 自动恢复功能

Q9: 恢复后数据库性能下降怎么办？

A9: 恢复后数据库性能下降的处理方法：

更新数据库统计信息
重建索引
优化数据库配置
分析慢查询
调整资源分配

Q10: 如何避免恢复失败？

A10: 避免恢复失败的方法：

定期验证备份集
提前测试恢复流程
准备详细的恢复计划
确保目标环境符合要求
监控恢复过程
准备回滚计划

恢复工具对比

OBR vs ODUMP

工具	类型	适用场景	恢复速度	灵活性
OBR	物理恢复工具	大规模数据库恢复	快	低
ODUMP	逻辑恢复工具	小规模数据库恢复	慢	高

选择建议

大规模数据库：使用 OBR 进行物理恢复
小规模数据库：使用 ODUMP 进行逻辑恢复
选择性恢复：使用 ODUMP 进行逻辑恢复
快速恢复：使用 OBR 进行物理恢复

恢复注意事项

恢复前备份当前数据，以便在恢复失败时回滚
选择合适的恢复方式，根据数据库大小和恢复要求
监控恢复过程，及时发现并解决问题
验证恢复结果，确保数据完整性和一致性
恢复后更新数据库统计信息，优化查询性能
恢复后重建索引，提高查询效率
恢复后监控数据库性能，确保正常运行
记录恢复过程，总结经验教训，持续优化恢复流程

OceanBase 数据库级恢复 ​

物理恢复 ​

恢复前准备 ​

检查备份集 ​

检查目标环境 ​

全量恢复 ​

恢复命令 ​

恢复示例 ​

增量恢复 ​

恢复命令 ​

恢复示例 ​

PITR 恢复 ​

恢复命令 ​

恢复示例 ​

逻辑恢复 ​

恢复前准备 ​

检查备份文件 ​

检查目标环境 ​

全量恢复 ​

恢复命令 ​

恢复示例 ​

增量恢复 ​

恢复命令 ​

恢复示例 ​

恢复后验证 ​

数据完整性验证 ​

数据库状态验证 ​

业务功能验证 ​

恢复最佳实践 ​

恢复策略设计 ​

物理恢复策略 ​

逻辑恢复策略 ​

恢复性能优化 ​

物理恢复优化 ​

逻辑恢复优化 ​

恢复脚本自动化 ​

物理恢复脚本 ​

逻辑恢复脚本 ​

恢复案例 ​

案例一：物理恢复 ​

案例二：逻辑恢复 ​

常见问题（FAQ） ​

Q1: 物理恢复和逻辑恢复有什么区别？ ​

Q2: 如何选择合适的恢复方式？ ​

Q3: 恢复过程中遇到错误怎么办？ ​

Q4: 如何提高恢复速度？ ​

Q5: 恢复后数据库无法启动怎么办？ ​

Q6: 如何验证恢复结果？ ​

Q7: 恢复过程中需要注意什么？ ​

Q8: 如何实现自动化恢复？ ​

Q9: 恢复后数据库性能下降怎么办？ ​

Q10: 如何避免恢复失败？ ​

恢复工具对比 ​

OBR vs ODUMP ​

选择建议 ​

恢复注意事项 ​

OceanBase 数据库级恢复

物理恢复

恢复前准备

检查备份集

检查目标环境

全量恢复

恢复命令

恢复示例

增量恢复

恢复命令

恢复示例

PITR 恢复

恢复命令

恢复示例

逻辑恢复

恢复前准备

检查备份文件

检查目标环境

全量恢复

恢复命令

恢复示例

增量恢复

恢复命令

恢复示例

恢复后验证

数据完整性验证

数据库状态验证

业务功能验证

恢复最佳实践

恢复策略设计

物理恢复策略

逻辑恢复策略

恢复性能优化

物理恢复优化

逻辑恢复优化

恢复脚本自动化

物理恢复脚本

逻辑恢复脚本

恢复案例

案例一：物理恢复

案例二：逻辑恢复

常见问题（FAQ）

Q1: 物理恢复和逻辑恢复有什么区别？

Q2: 如何选择合适的恢复方式？

Q3: 恢复过程中遇到错误怎么办？

Q4: 如何提高恢复速度？

Q5: 恢复后数据库无法启动怎么办？

Q6: 如何验证恢复结果？

Q7: 恢复过程中需要注意什么？

Q8: 如何实现自动化恢复？

Q9: 恢复后数据库性能下降怎么办？

Q10: 如何避免恢复失败？

恢复工具对比

OBR vs ODUMP

选择建议

恢复注意事项