印刻数据库

外观

GaussDB 时间点恢复 ​

PITR 工作原理 ​

基于WAL日志的恢复机制 ​

  • GaussDB采用Write-Ahead Logging（WAL）机制，所有修改操作先写入WAL日志，再更新数据文件
  • WAL日志记录了数据库的所有修改操作，包括插入、更新、删除等
  • 时间点恢复通过重放WAL日志，将数据库恢复到过去某个特定时间点

恢复过程 ​

  1. 首先恢复基础备份（全量备份）
  2. 然后按顺序重放从备份结束时间到目标时间点的所有WAL日志
  3. 最终将数据库恢复到目标时间点的状态

恢复精度 ​

  • 可以恢复到任意时间点，精度取决于WAL日志的生成频率
  • 默认情况下，WAL日志在事务提交时生成，因此可以恢复到事务级别

PITR 配置要求 ​

数据库配置 ​

  1. 启用归档模式

    bash
    # 修改postgresql.conf文件
archive_mode = on
archive_command = 'cp %p /archive/wal/%f'

  2. 配置WAL级别

    bash
    # 修改postgresql.conf文件，建议设置为replica或logical
wal_level = replica

  3. 配置归档目录

    bash
    # 创建归档目录
mkdir -p /archive/wal
chown -R omm:dbgrp /archive/wal

  4. 重启数据库使配置生效

    bash
    gs_ctl restart -D /data/gaussdb/data

备份要求 ​

  1. 基础备份：需要至少一个全量备份作为恢复的起点
  2. WAL日志：需要从基础备份结束时间到目标时间点的所有WAL日志
  3. 备份完整性：确保所有必要的备份文件和WAL日志都可用且完整

使用gs_probackup进行PITR恢复 ​

准备工作 ​

  1. 确认备份和WAL日志可用性

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

# 确认WAL日志完整性
ls -la /archive/wal/

  2. 创建恢复目标目录

    bash
    mkdir -p /data/gaussdb/pitr_recovery
chown -R omm:dbgrp /data/gaussdb/pitr_recovery

执行PITR恢复 ​

按时间点恢复 ​

bash
# 恢复到特定时间点
gs_probackup restore -B /backup/gaussdb/probackup -D /data/gaussdb/pitr_recovery \
  --instance instance_name \
  --backup backup_id \
  --recovery-target-time '2023-01-01 12:00:00+08'

按事务ID恢复 ​

bash
# 恢复到特定事务ID
gs_probackup restore -B /backup/gaussdb/probackup -D /data/gaussdb/pitr_recovery \
  --instance instance_name \
  --backup backup_id \
  --recovery-target-xid '123456'

按LSN恢复 ​

bash
# 恢复到特定LSN
gs_probackup restore -B /backup/gaussdb/probackup -D /data/gaussdb/pitr_recovery \
  --instance instance_name \
  --backup backup_id \
  --recovery-target-lsn '0/12345678'

启动恢复后的数据库 ​

bash
# 启动数据库
gs_ctl start -D /data/gaussdb/pitr_recovery

# 验证恢复结果
gsql -h 127.0.0.1 -p 5432 -U postgres -c "SELECT now();"

使用基础备份和WAL日志进行PITR恢复 ​

恢复步骤 ​

  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. 创建recovery.conf文件

    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_time = '2023-01-01 12:30:00+08'" >> /data/gaussdb/data/recovery.conf
echo "recovery_target_timeline = 'latest'" >> /data/gaussdb/data/recovery.conf

  5. 启动数据库服务

    bash
    gs_ctl start -D /data/gaussdb/data

  6. 验证恢复结果

    bash
    # 查看数据库状态
gs_ctl status -D /data/gaussdb/data

# 验证数据完整性
gsql -h 127.0.0.1 -p 5432 -U postgres -c "SELECT count(*) FROM critical_table;"

PITR 恢复目标选项 ​

按时间点恢复 ​

  • 参数：recovery_target_time
  • 格式：'YYYY-MM-DD HH:MI:SS+TZ'
  • 示例：'2023-01-01 12:00:00+08'
  • 适用场景：已知数据损坏或误操作发生的具体时间

按事务ID恢复 ​

  • 参数：recovery_target_xid
  • 格式：事务ID（数字）
  • 示例：123456
  • 适用场景：已知导致问题的具体事务ID

按LSN恢复 ​

  • 参数：recovery_target_lsn
  • 格式：LSN（Log Sequence Number）
  • 示例：0/12345678
  • 适用场景：已知导致问题的具体LSN位置

按名称恢复 ​

  • 参数：recovery_target_name
  • 格式：保存点名称
  • 示例：'before_bulk_update'
  • 适用场景：之前创建了命名保存点

PITR 最佳实践 ​

备份策略 ​

  • 定期全量备份：每周执行一次全量备份，作为PITR的基础
  • 实时归档WAL日志：确保WAL日志及时归档，避免日志丢失
  • 备份验证：定期验证备份文件的完整性和可用性
  • 多副本存储：将备份文件和WAL日志存储在多个位置，避免单点故障

恢复测试 ​

  • 定期恢复测试：每月执行一次PITR恢复测试，确保恢复流程正常
  • 测试不同恢复目标：测试按时间点、事务ID和LSN恢复，确保各种恢复方式都能正常工作
  • 记录恢复时间：记录每次恢复的时间，以便优化恢复流程

性能优化 ​

  • 使用并行恢复：对于大型数据库，启用并行恢复提高恢复速度
  • 优化恢复配置：调整恢复参数，如增加max_wal_senders和wal_buffers
  • 使用高速存储：将恢复目标目录和WAL归档目录存储在高速存储设备上

监控与告警 ​

  • 监控归档状态：确保WAL日志正常归档，设置告警机制
  • 监控备份完整性：定期检查备份文件和WAL日志的完整性
  • 监控恢复过程：恢复过程中实时监控日志和资源使用情况

恢复后验证 ​

数据库状态验证 ​

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

    bash
    gs_ctl status -D /data/gaussdb/data

  • 验证数据库连接

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

  • 检查数据库日志

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

数据完整性验证 ​

  • 检查关键表的行数

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

  • 验证关键数据的准确性

    bash
    gsql -h 127.0.0.1 -p 5432 -U postgres -d mydb -c "SELECT SUM(amount) FROM orders WHERE date = '2023-01-01';"

  • 检查索引和约束

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

功能验证 ​

  • 执行基本DML操作

    bash
    gsql -h 127.0.0.1 -p 5432 -U postgres -d mydb -c "INSERT INTO test_table VALUES (1, 'test');"
gsql -h 127.0.0.1 -p 5432 -U postgres -d mydb -c "UPDATE test_table SET name = 'updated' WHERE id = 1;"
gsql -h 127.0.0.1 -p 5432 -U postgres -d mydb -c "DELETE FROM test_table WHERE id = 1;"

  • 执行复杂查询

    bash
    gsql -h 127.0.0.1 -p 5432 -U postgres -d mydb -c "SELECT * FROM orders o JOIN customers c ON o.customer_id = c.id WHERE o.date BETWEEN '2023-01-01' AND '2023-01-31' ORDER BY o.total_amount DESC LIMIT 10;"

常见问题（FAQ） ​

Q1: PITR恢复需要多长时间？ ​

A1: PITR恢复时间取决于以下因素：

  • 基础备份的大小
  • 需要重放的WAL日志量
  • 系统资源（CPU、内存、磁盘IO）
  • 恢复配置参数

一般来说，恢复时间与数据量和WAL日志量成正比。对于大型数据库，可能需要数小时甚至更长时间。

Q2: 如何确定最佳恢复时间点？ ​

A2: 确定最佳恢复时间点的方法包括：

  • 分析应用程序日志，确定问题发生的时间
  • 查看数据库日志，查找错误或异常信息
  • 与业务人员沟通，了解数据损坏的具体情况
  • 可以先恢复到一个近似时间点，然后逐步调整

Q3: PITR恢复过程中可以中断吗？ ​

A3: 不建议中断PITR恢复过程，因为这可能导致数据库处于不一致状态。如果必须中断，建议：

  • 等待当前WAL日志重放完成
  • 停止数据库服务
  • 清理恢复目录
  • 重新开始恢复过程

Q4: 如何避免WAL日志丢失？ ​

A4: 避免WAL日志丢失的方法包括：

  • 确保归档目录有足够的磁盘空间
  • 配置可靠的归档命令，如使用rsync替代cp
  • 监控归档状态，设置告警机制
  • 将WAL日志复制到多个位置，如远程服务器或云存储
  • 定期验证归档日志的完整性

Q5: PITR恢复后需要做什么？ ​

A5: PITR恢复后需要：

  • 验证数据库状态和数据完整性
  • 重建索引和统计信息，提高查询性能
  • 执行数据库真空操作，清理无效数据
  • 备份恢复后的数据库，确保数据安全
  • 分析导致数据损坏的原因，避免类似问题再次发生

Q6: 可以在生产环境直接进行PITR恢复吗？ ​

A6: 不建议直接在生产环境进行PITR恢复，因为：

  • 恢复过程中数据库不可用，影响业务
  • 恢复结果可能不符合预期
  • 可能导致数据进一步损坏

建议：

  • 在测试环境进行恢复测试
  • 确认恢复结果符合预期后，再在生产环境执行
  • 或使用备用数据库进行恢复，然后切换为主库

Q7: 如何监控PITR恢复进度？ ​

A7: 监控PITR恢复进度的方法包括：

  • 查看数据库日志，了解当前重放的WAL日志和进度

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

  • 使用gs_ctl工具查看数据库状态

    bash
    gs_ctl status -D /data/gaussdb/data

  • 监控系统资源使用情况，如CPU、内存、磁盘IO

Q8: PITR恢复支持跨版本吗？ ​

A8: PITR恢复通常不支持跨主版本恢复，因为不同主版本的WAL格式可能不兼容。建议：

  • 使用相同版本的数据库进行恢复
  • 如果需要跨版本恢复，先恢复到相同版本，然后升级到目标版本
  • 详细查阅GaussDB版本兼容性文档

Q9: 如何减少PITR恢复时间？ ​

A9: 减少PITR恢复时间的方法包括：

  • 使用增量备份替代全量备份，减少基础备份恢复时间
  • 优化恢复配置，如增加并行度和缓冲区大小
  • 使用高速存储设备，提高IO性能
  • 定期清理过期数据，减少需要恢复的数据量
  • 采用合适的备份策略，减少需要重放的WAL日志量

Q10: 可以恢复单个表或数据库吗？ ​

A10: PITR恢复是针对整个数据库集群的，不能直接恢复单个表或数据库。如果只需要恢复单个表或数据库，可以：

  • 先恢复整个集群到目标时间点
  • 然后将需要的表或数据库导出
  • 最后将导出的数据导入到生产环境

或者使用逻辑备份工具，如pg_dump，从恢复后的数据库中导出特定表或数据库。