印刻数据库

外观

GaussDB 全量恢复 ​

物理全量恢复 ​

工具介绍 ​

  • gs_basebackup：用于从物理备份恢复数据库
  • gs_probackup：专业备份恢复工具，支持全量恢复、增量恢复和PITR恢复
  • gs_ctl：数据库控制工具，用于启动、停止和管理数据库服务

使用gs_basebackup备份进行物理全量恢复 ​

恢复步骤 ​

  1. 停止数据库服务

    bash
    gs_ctl stop -D /data/gaussdb/data

  2. 清理或重命名现有数据目录

    bash
    mv /data/gaussdb/data /data/gaussdb/data_old
mkdir -p /data/gaussdb/data

  3. 从备份目录恢复数据文件

    bash
    # 假设备份文件存储在/backup/gaussdb/full_backup_20230101_120000
cp -r /backup/gaussdb/full_backup_20230101_120000/* /data/gaussdb/data/

  4. 恢复WAL日志（如果需要）

    bash
    # 复制归档的WAL日志到pg_xlog目录
cp /archive/wal/* /data/gaussdb/data/pg_xlog/

  5. 修改恢复配置文件

    bash
    # 创建recovery.conf文件
touch /data/gaussdb/data/recovery.conf

# 添加恢复配置
echo "restore_command = 'cp /archive/wal/%f %p'" >> /data/gaussdb/data/recovery.conf
echo "recovery_target_timeline = 'latest'" >> /data/gaussdb/data/recovery.conf

  6. 启动数据库服务

    bash
    gs_ctl start -D /data/gaussdb/data

  7. 验证恢复状态

    bash
    gs_ctl status -D /data/gaussdb/data

使用gs_probackup进行物理全量恢复 ​

恢复步骤 ​

  1. 停止数据库服务

    bash
    gs_ctl stop -D /data/gaussdb/data

  2. 清理现有数据目录

    bash
    rm -rf /data/gaussdb/data/*

  3. 执行恢复操作

    bash
    # 查看可用备份
gs_probackup show -B /backup/gaussdb/probackup

# 执行恢复，使用备份ID
gs_probackup restore -B /backup/gaussdb/probackup -D /data/gaussdb/data --instance instance_name --backup backup_id

  4. 启动数据库服务

    bash
    gs_ctl start -D /data/gaussdb/data

  5. 验证恢复结果

    bash
    gsql -h 127.0.0.1 -p 5432 -U postgres -c "SELECT version();"

逻辑全量恢复 ​

工具介绍 ​

  • psql：用于执行SQL脚本，恢复SQL格式的备份
  • pg_restore：用于恢复自定义格式的逻辑备份
  • createdb：用于创建数据库

恢复SQL格式的逻辑备份 ​

恢复步骤 ​

  1. 创建目标数据库

    bash
    createdb -h 127.0.0.1 -p 5432 -U postgres mydb

  2. 执行SQL脚本进行恢复

    bash
    psql -h 127.0.0.1 -p 5432 -U postgres -d mydb -f /backup/gaussdb/mydb_full_20230101_120000.sql

  3. 验证恢复结果

    bash
    gsql -h 127.0.0.1 -p 5432 -U postgres -d mydb -c "\dt"

恢复自定义格式的逻辑备份 ​

恢复步骤 ​

  1. 创建目标数据库

    bash
    createdb -h 127.0.0.1 -p 5432 -U postgres mydb

  2. 使用pg_restore进行恢复

    bash
    # 基本恢复
pg_restore -h 127.0.0.1 -p 5432 -U postgres -d mydb /backup/gaussdb/mydb_full_20230101_120000.dump

# 并行恢复（提高恢复速度）
pg_restore -h 127.0.0.1 -p 5432 -U postgres -d mydb -j 4 /backup/gaussdb/mydb_full_20230101_120000.dump

# 只恢复特定表
pg_restore -h 127.0.0.1 -p 5432 -U postgres -d mydb -t mytable /backup/gaussdb/mydb_full_20230101_120000.dump

  3. 验证恢复结果

    bash
    gsql -h 127.0.0.1 -p 5432 -U postgres -d mydb -c "SELECT count(*) FROM mytable;"

恢复前准备 ​

环境检查 ​

  • 确认目标服务器的硬件配置与源服务器兼容
  • 检查目标服务器的操作系统版本和补丁级别
  • 确认GaussDB版本与备份文件兼容
  • 检查目标服务器的磁盘空间，确保有足够的空间存储恢复后的数据

备份文件准备 ​

  • 确认备份文件的完整性和可用性
  • 验证备份文件的校验和，确保文件没有损坏
  • 确认备份文件的版本与目标数据库兼容
  • 准备好所有必要的备份文件，包括全量备份和相关的WAL日志

恢复计划制定 ​

  • 制定详细的恢复计划，包括恢复步骤、时间窗口和回滚方案
  • 通知相关人员，确保恢复操作不会影响正常业务
  • 准备好必要的工具和脚本
  • 设置恢复过程中的监控和告警机制

恢复过程监控 ​

日志监控 ​

  • 实时查看数据库日志，了解恢复进度和状态

    bash
    tail -f /data/gaussdb/data/pg_log/gaussdb-$(date +%Y-%m-%d).log

  • 检查恢复过程中是否有错误或警告信息

  • 记录恢复开始时间和结束时间

资源监控 ​

  • 监控CPU使用率，确保恢复过程不会导致系统过载
  • 监控磁盘IO，确保恢复过程中的IO操作不会影响其他业务
  • 监控内存使用情况，避免内存不足导致恢复失败
  • 监控网络流量（如果恢复数据来自远程服务器）

进度监控 ​

  • 使用gs_probackup的恢复进度显示功能
  • 记录恢复过程中的关键里程碑
  • 定期向相关人员报告恢复进度

恢复后验证 ​

数据库状态验证 ​

  • 检查数据库是否正常启动

    bash
    gs_ctl status -D /data/gaussdb/data

  • 验证数据库连接是否正常

    bash
    gsql -h 127.0.0.1 -p 5432 -U postgres -c "SELECT 1;"

  • 检查数据库日志，确认没有错误信息

数据完整性验证 ​

  • 检查关键表的行数是否与预期一致

    bash
    gsql -h 127.0.0.1 -p 5432 -U postgres -d mydb -c "SELECT count(*) FROM critical_table;"

  • 验证关键数据的准确性，如总和、平均值等

  • 检查索引是否正常工作

  • 验证约束是否完整

功能验证 ​

  • 执行基本的DML操作，如插入、更新、删除
  • 执行复杂查询，验证查询计划和性能
  • 验证存储过程、函数和触发器是否正常工作
  • 验证备份和恢复功能是否正常

恢复最佳实践 ​

物理恢复最佳实践 ​

  • 使用gs_probackup工具进行备份和恢复，支持更丰富的功能
  • 定期测试恢复流程，确保备份文件可以正常恢复
  • 恢复前清理目标数据目录，避免数据残留导致恢复失败
  • 恢复后验证数据库的完整性和一致性
  • 保留恢复日志和报告，便于后续分析和审计

逻辑恢复最佳实践 ​

  • 对于大型数据库，使用自定义格式备份和并行恢复，提高恢复速度
  • 恢复前创建新的数据库，避免覆盖现有数据
  • 恢复后重建索引和统计信息，提高查询性能
  • 对于选择性恢复，使用pg_restore的表级恢复功能
  • 验证恢复后的数据完整性和一致性

通用最佳实践 ​

  • 制定详细的恢复计划，并定期测试
  • 恢复操作应在业务低峰期进行，避免影响正常业务
  • 恢复过程中密切监控系统资源和日志
  • 恢复后进行全面的验证，确保数据库正常运行
  • 记录恢复过程和结果，便于后续分析和改进

常见问题（FAQ） ​

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

A1: 物理恢复是直接恢复数据库的物理文件，恢复速度快，适合大规模数据库；逻辑恢复是恢复数据库的逻辑结构和数据，恢复速度慢，但跨版本兼容性好，支持选择性恢复。

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

A2: 恢复过程中遇到错误时，应：

  • 查看详细的错误日志，了解错误原因
  • 根据错误信息进行针对性修复
  • 如果无法解决，考虑使用其他备份进行恢复
  • 记录错误信息，便于后续分析和改进

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

A3: 提高恢复速度的方法包括：

  • 使用物理恢复替代逻辑恢复
  • 使用并行恢复，提高恢复并行度
  • 使用高速存储设备存储备份文件和恢复目标
  • 关闭不必要的数据库功能，如审计、日志等
  • 调整恢复参数，如增加缓冲区大小

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

A4: 恢复后数据库性能下降可能是由于：

  • 索引和统计信息需要重建
  • 数据库缓存需要重新预热
  • 恢复过程中产生的碎片

解决方法包括：

  • 重建索引和统计信息
  • 执行数据库真空操作
  • 预热数据库缓存
  • 调整数据库参数

Q5: 如何验证恢复后的数据完整性？ ​

A5: 验证恢复后的数据完整性可以通过：

  • 比较关键表的行数与预期一致
  • 验证关键数据的准确性，如总和、平均值等
  • 执行数据一致性检查
  • 运行应用程序的功能测试
  • 使用数据库自带的验证工具

Q6: 恢复过程中需要停止其他业务吗？ ​

A6: 恢复过程中不需要停止其他业务，但应注意：

  • 恢复操作会占用系统资源，可能影响其他业务的性能
  • 恢复操作应在业务低峰期进行，避免影响正常业务
  • 对于生产环境，建议在维护窗口内执行恢复操作

Q7: 如何制定有效的恢复计划？ ​

A7: 制定有效的恢复计划应包括：

  • 详细的恢复步骤和时间窗口
  • 恢复过程中的监控和告警机制
  • 回滚方案，以防恢复失败
  • 相关人员的职责和联系方式
  • 恢复后的验证和测试计划

Q8: 恢复后需要做哪些后续操作？ ​

A8: 恢复后需要做的后续操作包括：

  • 验证数据库的完整性和一致性
  • 重建索引和统计信息
  • 调整数据库参数，优化性能
  • 执行数据库真空操作
  • 备份恢复后的数据库，确保数据安全
  • 记录恢复过程和结果，便于后续分析和改进