印刻数据库

外观

DB2 远程灾难恢复 ​

灾难恢复概述 ​

1. 什么是灾难恢复？ ​

灾难恢复（Disaster Recovery，DR）是指在发生自然灾害、硬件故障、人为错误或网络攻击等灾难事件后，恢复数据库系统正常运行的过程。远程灾难恢复则是指在主数据中心之外的远程站点实施灾难恢复，以确保在主数据中心发生灾难时，业务能够快速恢复。

2. 灾难恢复目标 ​

  • 恢复时间目标（RTO）：从灾难发生到系统恢复正常运行的最大允许时间
  • 恢复点目标（RPO）：灾难发生后，允许丢失的数据量或时间范围
  • 恢复级别目标（RLO）：恢复后系统需要达到的功能和性能级别

3. 灾难恢复策略类型 ​

策略类型描述RTORPO成本
备份恢复定期备份数据到远程站点，灾难发生后恢复数小时到数天取决于备份频率低
异步复制异步将数据复制到远程站点数分钟到数小时数分钟到数小时中
同步复制同步将数据复制到远程站点数秒到数分钟接近零高
多活数据中心多个数据中心同时运行，灾难发生后无缝切换秒级零很高

DB2 灾难恢复技术 ​

1. HADR（高可用性灾难恢复） ​

1.1 概述 ​

HADR（High Availability Disaster Recovery）是DB2提供的内置灾难恢复技术，用于在主数据库和备用数据库之间进行数据复制。HADR支持同步和异步复制模式，可以在本地或远程站点部署。

1.2 架构 ​

  • 主数据库（Primary）：处理所有读写操作
  • 备用数据库（Standby）：接收主数据库的日志，并应用到本地数据库
  • 日志传输：通过TCP/IP协议传输日志
  • 自动故障转移：支持自动或手动故障转移

1.3 配置方法 ​

bash
# 在主数据库上配置HADR
db2 update db cfg for <dbname> using HADR_LOCAL_HOST <primary_host> HADR_LOCAL_SVC 50001
db2 update db cfg for <dbname> using HADR_REMOTE_HOST <standby_host> HADR_REMOTE_SVC 50002
db2 update db cfg for <dbname> using HADR_REMOTE_INST <standby_instance> HADR_SYNCMODE <sync_mode>
db2 update db cfg for <dbname> using HADR_TARGET_LIST <standby_host>:50002
db2 update db cfg for <dbname> using LOGINDEXBUILD ON

# 在备用数据库上恢复主数据库的备份
db2 restore database <dbname> from <backup_path> taken at <timestamp> replace existing
db2 rollforward database <dbname> to end of logs and stop hadr on pending
db2 update db cfg for <dbname> using HADR_LOCAL_HOST <standby_host> HADR_LOCAL_SVC 50002
db2 update db cfg for <dbname> using HADR_REMOTE_HOST <primary_host> HADR_REMOTE_SVC 50001
db2 update db cfg for <dbname> using HADR_REMOTE_INST <primary_instance> HADR_SYNCMODE <sync_mode>
db2 update db cfg for <dbname> using HADR_TARGET_LIST <primary_host>:50001
db2 update db cfg for <dbname> using LOGINDEXBUILD ON

# 启动HADR
# 在备用数据库上执行
db2 start hadr on database <dbname> as standby
# 在主数据库上执行
db2 start hadr on database <dbname> as primary

# 验证HADR状态
db2pd -db <dbname> -hadr

1.4 同步模式 ​

  • SYNC（同步）：主数据库等待备用数据库确认已将日志写入磁盘后，才提交事务
  • NEARSYNC（近同步）：主数据库等待备用数据库确认已将日志写入内存后，才提交事务
  • ASYNC（异步）：主数据库不等待备用数据库确认，直接提交事务
  • SUPERASYNC（超级异步）：主数据库将日志放入发送队列后，立即提交事务

2. 远程备份和恢复 ​

2.1 概述 ​

远程备份和恢复是指将数据库备份到远程存储设备，灾难发生后从远程备份恢复数据库。这种方法适用于对RTO和RPO要求不太高的场景。

2.2 实施方法 ​

bash
# 将备份直接写入远程存储
db2 backup database <dbname> to '//remote_server/backup_share' compress

# 使用管道和SSH将备份发送到远程服务器
db2 backup database <dbname> to - compress | ssh user@remote_server 'cat > /backup/<dbname>_$(date +%Y%m%d_%H%M%S).001'

# 从远程备份恢复数据库
db2 restore database <dbname> from '//remote_server/backup_share' taken at <timestamp> replace existing
db2 rollforward database <dbname> to end of logs and stop

# 使用管道和SSH从远程服务器恢复
db2 restore database <dbname> from - taken at <timestamp> replace existing < <(ssh user@remote_server 'cat /backup/<dbname>_<timestamp>.001')

3. DB2 PureScale 灾难恢复 ​

3.1 概述 ​

DB2 PureScale提供了内置的灾难恢复功能，可以与HADR结合使用，实现高可用性和灾难恢复。PureScale集群可以部署在主站点，备用站点部署单个DB2实例或PureScale集群作为HADR备用数据库。

3.2 配置方法 ​

bash
# 在PureScale主集群上配置HADR
db2 update db cfg for <dbname> using HADR_LOCAL_HOST <primary_member> HADR_LOCAL_SVC 50001
db2 update db cfg for <dbname> using HADR_REMOTE_HOST <standby_host> HADR_REMOTE_SVC 50002
db2 update db cfg for <dbname> using HADR_REMOTE_INST <standby_instance> HADR_SYNCMODE NEARSYNC

# 在备用数据库上配置HADR
db2 update db cfg for <dbname> using HADR_LOCAL_HOST <standby_host> HADR_LOCAL_SVC 50002
db2 update db cfg for <dbname> using HADR_REMOTE_HOST <primary_member> HADR_REMOTE_SVC 50001
db2 update db cfg for <dbname> using HADR_REMOTE_INST <primary_instance> HADR_SYNCMODE NEARSYNC

# 启动HADR
db2 start hadr on database <dbname> as standby # 在备用数据库上执行
db2 start hadr on database <dbname> as primary # 在主数据库上执行

4. 日志归档到远程存储 ​

4.1 概述 ​

将DB2日志归档到远程存储，可以确保在主站点发生灾难时，能够使用最新的日志进行恢复，减少数据丢失。

4.2 配置方法 ​

bash
# 配置日志归档到远程存储
db2 update db cfg for <dbname> using LOGARCHMETH1 'DISK://remote_server/log_archive'
db2 update db cfg for <dbname> using LOGARCHMETH2 'TSM' # 可选，使用TSM作为第二归档目标

# 手动归档当前日志
db2 archive log for database <dbname>

# 验证日志归档
db2 get db cfg for <dbname> | grep -i logarch
ls -la //remote_server/log_archive/

灾难恢复实施步骤 ​

1. 规划阶段 ​

1.1 风险评估 ​

  • 识别潜在的灾难类型和影响范围
  • 评估业务关键程度和恢复优先级
  • 确定RTO和RPO目标

1.2 技术选型 ​

  • 根据RTO和RPO要求选择合适的灾难恢复技术
  • 评估硬件、软件和网络需求
  • 制定灾难恢复架构设计

1.3 制定灾难恢复计划 ​

  • 详细的灾难恢复步骤和流程
  • 角色和职责分配
  • 通信计划
  • 测试计划
  • 维护计划

2. 实施阶段 ​

2.1 搭建灾难恢复环境 ​

  • 部署备用数据库服务器
  • 配置网络连接
  • 安装和配置DB2软件
  • 配置存储系统

2.2 配置灾难恢复技术 ​

  • 配置HADR或其他复制技术
  • 配置远程备份
  • 配置日志归档
  • 配置监控和告警

2.3 配置自动故障转移 ​

bash
# 配置HADR自动故障转移
db2 update db cfg for <dbname> using HADR_AUTO_FAILOVER ON
db2 update db cfg for <dbname> using HADR_PEER_WINDOW 300

# 配置TSA（Tivoli System Automation）进行自动故障转移
# 安装TSA
tar -xzf TSA_*.tar.gz
cd TSA_install
./install.sh

# 配置TSA集群
mkcluster -c dr_cluster -i eth0
addrpnode -m <primary_node> -p <standby_node>
addrsrc -s <primary_db> -t DB2
addrsrc -s <standby_db> -t DB2

# 配置资源组和依赖关系
mkrsrcgrp -g dr_rg
addrsrc -g dr_rg -s <primary_db>
addrsrc -g dr_rg -s <standby_db>
addrsrcdep -s <standby_db> -d <primary_db> -t "depends_on"

# 启用自动故障转移
chrsrc -c IBM.Application -a AutoStart=true Name=<primary_db>
chrsrc -c IBM.Application -a AutoStart=true Name=<standby_db>

3. 测试阶段 ​

3.1 灾难恢复测试类型 ​

  • 桌面演练：模拟灾难场景，讨论恢复流程
  • 功能测试：验证单个灾难恢复组件的功能
  • 集成测试：验证整个灾难恢复流程
  • 全面测试：模拟真实灾难场景，测试完整的恢复流程

3.2 测试步骤 ​

  1. 制定测试计划和测试用例
  2. 通知相关人员和业务部门
  3. 执行测试
  4. 记录测试结果和问题
  5. 分析测试结果，优化灾难恢复计划
  6. 更新灾难恢复文档

3.3 测试示例 ​

bash
# 手动触发HADR故障转移
db2 takeover hadr on database <dbname> by force

# 验证备用数据库已接管为主数据库
db2pd -db <dbname> -hadr

# 执行业务验证测试
# 连接到新的主数据库
# 执行关键业务查询和事务
# 验证数据完整性

# 故障恢复后，重新建立HADR关系
db2 start hadr on database <dbname> as standby # 在原主数据库上执行
db2 start hadr on database <dbname> as primary # 在原备用数据库上执行

4. 维护阶段 ​

4.1 定期备份和恢复测试 ​

  • 定期测试从备份恢复数据库
  • 验证备份的完整性和可用性
  • 更新备份策略和流程

4.2 定期灾难恢复测试 ​

  • 至少每年执行一次全面灾难恢复测试
  • 根据业务变化和技术更新调整测试计划
  • 记录和分析测试结果

4.3 定期更新灾难恢复计划 ​

  • 根据业务变化更新恢复优先级
  • 根据技术更新调整恢复流程
  • 定期培训相关人员

生产实践 ​

1. 企业级灾难恢复架构 ​

1.1 两地三中心架构 ​

两地三中心架构是指在两个地理区域部署三个数据中心：生产中心、同城灾备中心和异地灾备中心。这种架构可以提供最高级别的业务连续性保障。

  • 生产中心：处理所有业务请求
  • 同城灾备中心：使用同步或近同步复制，用于快速故障转移
  • 异地灾备中心：使用异步复制，用于灾难恢复

1.2 实施示例 ​

bash
# 配置生产中心到同城灾备中心的HADR（近同步）
db2 update db cfg for <dbname> using HADR_LOCAL_HOST prod_host HADR_LOCAL_SVC 50001
db2 update db cfg for <dbname> using HADR_REMOTE_HOST local_dr_host HADR_REMOTE_SVC 50002
db2 update db cfg for <dbname> using HADR_SYNCMODE NEARSYNC

# 配置生产中心到异地灾备中心的HADR（异步）
db2 update db cfg for <dbname> using HADR_TARGET_LIST "local_dr_host:50002,remote_dr_host:50003"
db2 update db cfg for <dbname> using HADR_SYNCMODE SUPERASYNC on remote_dr_host:50003

# 配置日志归档到异地存储
db2 update db cfg for <dbname> using LOGARCHMETH1 'DISK://prod_host/log_archive'
db2 update db cfg for <dbname> using LOGARCHMETH2 'DISK://remote_dr_host/log_archive'

2. 灾难恢复监控和告警 ​

2.1 监控内容 ​

  • HADR状态和性能
  • 备份作业状态
  • 日志归档状态
  • 网络连接状态
  • 存储系统状态
  • 服务器硬件状态

2.2 监控工具 ​

  • DB2内置工具：db2pd、db2top、snapshot监控
  • IBM Data Studio：图形化监控和管理
  • TSA（Tivoli System Automation）：集群监控和自动故障转移
  • 第三方监控工具：Zabbix、Nagios、Prometheus等

2.3 告警配置 ​

bash
# 配置DB2健康监控
db2 update alert cfg for database on <dbname> using HADR_ROLE_CHANGED SET THRESHOLDSCHECKED YES
db2 update alert cfg for database on <dbname> using HADR_PEER_WINDOW_VIOLATION SET THRESHOLDSCHECKED YES
db2 update alert cfg for database on <dbname> using LOG_FULL SET THRESHOLDSCHECKED YES

# 配置邮件告警
db2 update alert cfg for database on <dbname> using SMTP_SERVER 'smtp.company.com'
db2 update alert cfg for database on <dbname> using FROM_ADDRESS 'db2-alert@company.com'
db2 update alert cfg for database on <dbname> using TO_ADDRESS 'dba@company.com'

# 测试告警
db2 send alert test to 'dba@company.com' subject 'Test Alert' message 'This is a test alert from DB2'

3. 灾难恢复自动化 ​

3.1 自动备份脚本 ​

bash
#!/bin/bash
# DB2 自动远程备份脚本

DB_NAME="PRODDB"
BACKUP_PATH="//remote_server/backup"
LOG_FILE="/var/log/db2_backup.log"
EMAIL_RECIPIENTS="dba@company.com"

# 记录备份开始时间
echo "$(date +'%Y-%m-%d %H:%M:%S') - 开始备份数据库 $DB_NAME" >> $LOG_FILE

# 执行远程备份
db2 backup database $DB_NAME to $BACKUP_PATH compress 2>&1 >> $LOG_FILE

BACKUP_RESULT=$?

# 记录备份结果
if [ $BACKUP_RESULT -eq 0 ]; then
    echo "$(date +'%Y-%m-%d %H:%M:%S') - 数据库 $DB_NAME 备份成功" >> $LOG_FILE
    SUBJECT="DB2 备份成功 - $DB_NAME"
    BODY="数据库 $DB_NAME 已成功备份到 $BACKUP_PATH"
else
    echo "$(date +'%Y-%m-%d %H:%M:%S') - 数据库 $DB_NAME 备份失败" >> $LOG_FILE
    SUBJECT="DB2 备份失败 - $DB_NAME"
    BODY="数据库 $DB_NAME 备份失败，请查看日志文件 $LOG_FILE"
fi

# 发送邮件通知
echo "$BODY" | mail -s "$SUBJECT" $EMAIL_RECIPIENTS

# 清理7天前的备份文件
find $BACKUP_PATH -name "${DB_NAME}*.001" -mtime +7 -delete >> $LOG_FILE 2>&1
echo "$(date +'%Y-%m-%d %H:%M:%S') - 已清理7天前的备份文件" >> $LOG_FILE

3.2 灾难恢复自动测试脚本 ​

bash
#!/bin/bash
# DB2 HADR 自动测试脚本

DB_NAME="PRODDB"
LOG_FILE="/var/log/hadr_test.log"
EMAIL_RECIPIENTS="dba@company.com"

# 记录测试开始时间
echo "$(date +'%Y-%m-%d %H:%M:%S') - 开始HADR故障转移测试" >> $LOG_FILE

# 连接到主数据库
db2 connect to $DB_NAME

# 记录当前HADR状态
echo "$(date +'%Y-%m-%d %H:%M:%S') - 测试前HADR状态:" >> $LOG_FILE
db2pd -db $DB_NAME -hadr >> $LOG_FILE

# 插入测试数据
echo "$(date +'%Y-%m-%d %H:%M:%S') - 插入测试数据" >> $LOG_FILE
db2 "INSERT INTO test_table VALUES (1, 'test_data', CURRENT TIMESTAMP)"
TEST_DATA_ID=$?

# 获取当前主数据库名称
PRIMARY_HOST=$(db2pd -db $DB_NAME -hadr | grep -i "Primary Host" | awk '{print $3}')

# 触发HADR故障转移
echo "$(date +'%Y-%m-%d %H:%M:%S') - 触发HADR故障转移" >> $LOG_FILE
db2 takeover hadr on database $DB_NAME by force
TAKEOVER_RESULT=$?

if [ $TAKEOVER_RESULT -eq 0 ]; then
    echo "$(date +'%Y-%m-%d %H:%M:%S') - HADR故障转移成功" >> $LOG_FILE
    
    # 验证新的主数据库状态
    echo "$(date +'%Y-%m-%d %H:%M:%S') - 测试后HADR状态:" >> $LOG_FILE
db2pd -db $DB_NAME -hadr >> $LOG_FILE
    
    # 验证测试数据是否存在
    echo "$(date +'%Y-%m-%d %H:%M:%S') - 验证测试数据" >> $LOG_FILE
db2 "SELECT * FROM test_table WHERE id = 1" >> $LOG_FILE
    
    # 清理测试数据
db2 "DELETE FROM test_table WHERE id = 1"
    
    # 发送成功通知
    SUBJECT="HADR 故障转移测试成功 - $DB_NAME"
    BODY="HADR故障转移测试已成功完成，请查看日志文件 $LOG_FILE"
else
    echo "$(date +'%Y-%m-%d %H:%M:%S') - HADR故障转移失败" >> $LOG_FILE
    
    # 发送失败通知
    SUBJECT="HADR 故障转移测试失败 - $DB_NAME"
    BODY="HADR故障转移测试失败，请查看日志文件 $LOG_FILE"
fi

# 发送邮件通知
echo "$BODY" | mail -s "$SUBJECT" $EMAIL_RECIPIENTS

db2 connect reset

4. 灾难恢复演练案例 ​

4.1 案例：某银行DB2灾难恢复演练 ​

  • 背景：某银行使用DB2作为核心业务数据库，采用HADR实现灾难恢复
  • 目标：验证RTO和RPO是否符合要求（RTO < 30分钟，RPO < 5分钟）
  • 演练步骤：
    1. 停止主数据库服务器
    2. 等待自动故障转移完成
    3. 验证备用数据库接管为主数据库
    4. 更新应用连接字符串
    5. 启动应用系统
    6. 执行业务验证测试
    7. 记录RTO和RPO
    8. 恢复HADR关系
  • 结果：
    • RTO：15分钟，符合要求
    • RPO：2分钟，符合要求
    • 所有业务功能正常
  • 改进措施：
    • 优化自动故障转移配置
    • 简化应用切换流程
    • 增加测试频率

灾难恢复最佳实践 ​

1. 设计原则 ​

  • 简单性：灾难恢复设计应尽可能简单，减少复杂性
  • 可靠性：选择成熟可靠的技术和产品
  • 可测试性：灾难恢复流程应易于测试
  • 自动化：尽可能实现自动化，减少人为错误
  • 文档化：详细记录灾难恢复计划和流程

2. 日常维护 ​

  • 定期测试灾难恢复流程
  • 定期更新灾难恢复计划
  • 定期培训相关人员
  • 定期检查和更新备份
  • 定期检查和更新复制配置
  • 定期检查和更新监控和告警

3. 灾难恢复注意事项 ​

  • 确保灾难恢复站点的独立性
  • 确保网络连接的可靠性和带宽
  • 确保存储系统的兼容性和性能
  • 确保备份和恢复的安全性
  • 确保灾难恢复计划的保密性
  • 确保相关人员的可用性

版本差异 ​

版本灾难恢复特性
DB2 9.x支持HADR、远程备份和恢复
DB2 10.x增强HADR功能，支持自动故障转移
DB2 11.1引入HADR只读备用数据库、增强TSA集成
DB2 11.5增强HADR性能、支持更多复制模式
Db2 12.x增强云原生支持、优化灾难恢复管理

常见问题（FAQ） ​

Q1: HADR和远程备份恢复有什么区别？ ​

A1: HADR是实时数据复制技术，RTO和RPO较低，适用于对业务连续性要求高的场景；远程备份恢复是基于定期备份的恢复技术，RTO和RPO较高，适用于对业务连续性要求不太高的场景。

Q2: 如何选择合适的HADR同步模式？ ​

A2: 选择HADR同步模式需要权衡RTO、RPO和性能影响：

  • 对RPO要求高的场景，选择SYNC或NEARSYNC模式
  • 对性能要求高的场景，选择ASYNC或SUPERASYNC模式
  • 通常推荐使用NEARSYNC模式，在性能和数据安全性之间取得平衡

Q3: 如何验证HADR是否正常工作？ ​

A3: 可以使用以下命令验证HADR状态：

bash
db2pd -db <dbname> -hadr
db2 get db cfg for <dbname> | grep -i hadr

正常情况下，HADR状态应显示为PEER（同步模式）或REMOTE_CATCHUP（异步模式）。

Q4: 灾难恢复测试应该多久执行一次？ ​

A4: 灾难恢复测试频率取决于业务关键程度和合规要求：

  • 对于核心业务系统，建议每季度执行一次功能测试，每年执行一次全面测试
  • 对于非核心业务系统，建议每半年执行一次功能测试，每两年执行一次全面测试
  • 每次重大变更后，应执行一次灾难恢复测试

Q5: 如何优化灾难恢复的RTO？ ​

A5: 优化灾难恢复RTO的方法包括：

  • 使用自动化故障转移技术（如HADR自动故障转移、TSA）
  • 预配置灾难恢复环境
  • 优化恢复流程
  • 定期测试和优化恢复脚本
  • 确保灾难恢复站点的资源充足

Q6: 如何确保灾难恢复数据的安全性？ ​

A6: 确保灾难恢复数据安全性的方法包括：

  • 加密传输中的数据（如使用SSL/TLS加密HADR通信）
  • 加密存储中的数据（如使用透明数据加密TDE）
  • 实施严格的访问控制
  • 定期备份和恢复测试
  • 审计和监控数据访问

Q7: 多活数据中心和传统灾难恢复有什么区别？ ​

A7: 多活数据中心是指多个数据中心同时运行，业务请求可以分发到任何一个数据中心；传统灾难恢复是指备用数据中心处于待命状态，只有在主数据中心发生灾难时才接管业务。多活数据中心的RTO和RPO更低，但成本更高，复杂性更大。

Q8: 如何处理灾难恢复中的网络延迟问题？ ​

A8: 处理网络延迟问题的方法包括：

  • 选择合适的HADR同步模式（如ASYNC或SUPERASYNC）
  • 优化网络配置，增加带宽
  • 使用CDN或边缘计算节点
  • 考虑使用云服务提供商的区域内复制

总结 ​

DB2远程灾难恢复是确保业务连续性的重要组成部分，需要根据业务需求和恢复目标选择合适的技术和策略。HADR是DB2提供的强大灾难恢复技术，支持多种同步模式，可以满足不同的RTO和RPO要求。远程备份和恢复则适用于对RTO和RPO要求不太高的场景。

实施灾难恢复需要经过规划、实施、测试和维护等阶段，需要定期测试和更新灾难恢复计划，确保在真正发生灾难时能够快速恢复业务。同时，需要配置监控和告警机制，及时发现和处理灾难恢复中的问题。

在实际生产环境中，建议采用两地三中心等高级架构，结合多种灾难恢复技术，确保在各种灾难场景下都能快速恢复业务，满足RTO和RPO要求。