印刻数据库

外观

DB2 HADR 故障切换 ​

HADR 故障切换概述 ​

DB2 HADR（High Availability Disaster Recovery）提供了两种主要的故障切换方式：自动故障切换和手动故障切换。故障切换是指将数据库服务从主数据库转移到备用数据库的过程，以确保业务连续性。

故障切换类型 ​

1. 自动故障切换 ​

自动故障切换（Automatic Failover）是指当主数据库发生故障时，备用数据库自动接管主数据库角色，无需人工干预。

实现条件：

  • 配置了HADR自动故障切换
  • 使用了第三方集群管理器（如IBM Tivoli System Automation for Multiplatforms）
  • 或者使用DB2 pureScale with HADR

自动故障切换流程：

  1. 集群管理器检测到主数据库故障
  2. 集群管理器向备用数据库发送故障切换命令
  3. 备用数据库接管主数据库角色
  4. 应用程序自动连接到新的主数据库

2. 手动故障切换 ​

手动故障切换（Manual Failover）是指由数据库管理员手动执行故障切换操作，将备用数据库转换为主数据库。

手动故障切换类型：

  • HADR接管（Takeover）：正常情况下的角色切换，用于计划性维护
  • HADR强制接管（Takeover with Force）：主数据库故障时的应急切换

手动故障切换操作 ​

1. 正常接管（Takeover） ​

正常接管用于计划性维护，需要主数据库和备用数据库之间的连接正常。

操作步骤：

sql
-- 在备用数据库上执行接管操作
db2 takeover hadr on database <database_name>

-- 验证接管结果
db2 get snapshot for database on <database_name> | grep -i "hadr role"

预期输出：

HADR role                          = PRIMARY

2. 强制接管（Takeover with Force） ​

强制接管用于主数据库故障时的应急切换，无需主数据库确认。

操作步骤：

sql
-- 在备用数据库上执行强制接管操作
db2 takeover hadr on database <database_name> with force

-- 验证接管结果
db2 get snapshot for database on <database_name> | grep -i "hadr role"

注意：强制接管可能导致数据丢失，应谨慎使用。

3. 接管后的操作 ​

接管完成后，需要执行以下操作：

sql
-- 重新配置原主数据库为备用数据库
-- 1. 在原主数据库上停止HADR
db2 deactivate database <database_name>
db2 stop hadr on database <database_name>

-- 2. 在新主数据库上更新HADR配置
db2 update db cfg for <database_name> using hadr_target_list <new_standby_host>:<new_standby_port>

-- 3. 在原主数据库上启动HADR作为备用数据库
db2 start hadr on database <database_name> as standby

-- 4. 验证HADR状态
db2 get snapshot for database on <database_name> | grep -i "hadr"

HADR 故障切换配置 ​

1. 配置自动故障切换 ​

使用IBM Tivoli System Automation for Multiplatforms (TSAMP)配置自动故障切换：

bash
# 创建HADR资源组
samctrl -addresourcegroup hadr_rg

# 添加主数据库资源
samctrl -addresource -resourcegroup hadr_rg -resourcename primary_db -resourcetype IBM.Application -attr "Name=db2_primary,StartCommand='/opt/IBM/db2/V11.5/bin/db2start',StopCommand='/opt/IBM/db2/V11.5/bin/db2stop'"

# 添加备用数据库资源
samctrl -addresource -resourcegroup hadr_rg -resourcename standby_db -resourcetype IBM.Application -attr "Name=db2_standby,StartCommand='/opt/IBM/db2/V11.5/bin/db2start',StopCommand='/opt/IBM/db2/V11.5/bin/db2stop'"

# 配置故障切换关系
samctrl -addrelationship -source primary_db -target standby_db -relationshipname hadr_relationship -relationshipType Dependency

2. 配置客户端自动重连 ​

配置客户端自动重连到新的主数据库：

JDBC连接字符串配置：

java
String url = "jdbc:db2://primary_host:50000/SAMPLE:clientRerouteAlternateServerName=standby_host;clientRerouteAlternatePortNumber=50000;enableSeamlessFailover=1;";

CLI/ODBC配置： 在db2dsdriver.cfg文件中添加：

xml
<databases>
  <database name="SAMPLE" host="primary_host" port="50000">
    <parameter name="EnableSeamlessFailover" value="1" />
    <alternateserverlist>
      <server name="standby_host" port="50000" />
    </alternateserverlist>
  </database>
</databases>

HADR 故障切换最佳实践 ​

1. 故障切换前的准备 ​

  • 定期测试故障切换流程，确保在实际故障时能够快速响应
  • 保持HADR配置文档的更新，包括主机名、端口、配置参数等
  • 确保备用数据库与主数据库保持同步
  • 配置适当的HADR超时参数

2. 故障切换期间的注意事项 ​

  • 故障切换前，尽可能收集主数据库的故障信息
  • 对于强制接管，评估可能的数据丢失风险
  • 确保应用程序能够自动连接到新的主数据库
  • 监控故障切换过程，及时处理可能出现的问题

3. 故障切换后的验证 ​

  • 验证新主数据库的HADR角色
  • 验证数据库连接是否正常
  • 验证应用程序是否正常运行
  • 检查数据库日志，确保没有错误
  • 重新配置HADR环境，准备下一次故障切换

4. 性能优化 ​

  • 配置适当的HADR同步模式，平衡性能和数据一致性
  • 优化网络连接，减少HADR同步延迟
  • 配置适当的HADR日志缓冲区大小
  • 定期清理HADR日志文件

HADR 故障切换监控 ​

1. 监控HADR状态 ​

sql
-- 查看HADR状态
db2 get snapshot for database on <database_name> | grep -i "hadr"

-- 查看HADR统计信息
db2 get snapshot for database on <database_name> | grep -i "hadr statistics"

-- 查看HADR日志传输状态
db2pd -db <database_name> -hadr

2. 配置HADR告警 ​

使用DB2的健康监控功能配置HADR告警：

sql
-- 启用健康监控
db2 update dbm cfg using health_mon on

-- 配置HADR心跳告警
db2 update alert cfg for database on <database_name> using HADR_HEARTBEAT_MISSED threshold alert_level warning

故障切换场景分析 ​

场景1：主数据库服务器崩溃 ​

处理步骤：

  1. 确认主数据库服务器崩溃
  2. 在备用数据库上执行强制接管
  3. 重新配置应用程序连接
  4. 恢复原主数据库并重新加入HADR

场景2：主数据库网络故障 ​

处理步骤：

  1. 确认主数据库网络故障
  2. 评估故障持续时间
  3. 如故障持续时间较长，执行强制接管
  4. 故障恢复后，重新配置HADR环境

场景3：计划性维护 ​

处理步骤：

  1. 提前通知业务部门
  2. 在备用数据库上执行正常接管
  3. 对原主数据库进行维护
  4. 维护完成后，重新配置HADR环境

版本差异 ​

版本HADR故障切换特性变化
DB2 9.x引入基本的HADR故障切换功能
DB2 10.x增强了自动故障切换支持
DB2 11.1引入了多备用数据库支持
DB2 11.5增强了云环境下的HADR故障切换
Db2 12.x引入了智能故障切换和预测功能

常见问题（FAQ） ​

Q1: 自动故障切换和手动故障切换有什么区别？ ​

A1: 区别如下：

  • 自动故障切换：无需人工干预，由集群管理器自动完成，恢复时间短
  • 手动故障切换：需要DBA手动执行，恢复时间较长，但可以更精细地控制切换过程
  • 自动故障切换需要额外的集群管理软件
  • 手动故障切换适用于简单的HADR配置

Q2: 强制接管会导致数据丢失吗？ ​

A2: 是的，强制接管可能导致数据丢失：

  • 强制接管时，备用数据库不会等待与主数据库的最后一次同步
  • 未传输到备用数据库的日志可能丢失
  • 应仅在主数据库确实无法恢复时使用强制接管
  • 建议配置同步或近同步模式，减少数据丢失风险

Q3: 如何测试HADR故障切换？ ​

A3: 测试方法包括：

  • 执行计划性的正常接管，验证切换过程
  • 模拟主数据库故障，测试强制接管
  • 测试应用程序的自动重连功能
  • 测试故障切换后的业务连续性
  • 定期进行全面的故障切换演练

Q4: HADR故障切换需要多长时间？ ​

A4: 故障切换时间取决于多个因素：

  • HADR同步模式
  • 网络延迟
  • 数据库大小和负载
  • 自动故障切换配置
  • 一般情况下，自动故障切换可在秒级完成，手动故障切换可能需要分钟级

Q5: 如何优化HADR故障切换性能？ ​

A5: 优化方法包括：

  • 配置适当的HADR同步模式
  • 优化网络连接，减少延迟
  • 配置足够的HADR日志缓冲区
  • 使用快速存储设备
  • 配置适当的HADR超时参数
  • 定期清理HADR日志文件

Q6: 故障切换后，如何重新配置HADR环境？ ​

A6: 重新配置步骤：

  1. 恢复原主数据库
  2. 停止原主数据库的HADR
  3. 更新新主数据库的HADR目标列表
  4. 启动原主数据库作为备用数据库
  5. 验证HADR状态

Q7: 如何监控HADR故障切换过程？ ​

A7: 监控方法：

  • 使用DB2快照监控HADR状态
  • 使用db2pd工具查看HADR详细信息
  • 配置HADR告警
  • 查看数据库诊断日志
  • 使用第三方监控工具

Q8: HADR支持多个备用数据库的故障切换吗？ ​

A8: 是的，从DB2 11.1开始支持多个备用数据库：

  • 可以配置最多3个备用数据库
  • 每个备用数据库可以配置不同的同步模式
  • 故障切换时，需要指定要接管的备用数据库
  • 多备用数据库配置提供了更高的可用性和灵活性

Q9: 如何配置HADR客户端自动重连？ ​

A9: 配置方法：

  • JDBC连接字符串中添加clientRerouteAlternateServerName和clientRerouteAlternatePortNumber参数
  • CLI/ODBC配置文件中添加alternateserverlist
  • 启用EnableSeamlessFailover参数
  • 测试客户端自动重连功能

Q10: HADR故障切换与DB2 pureScale有什么区别？ ​

A10: 区别在于：

  • HADR：基于日志复制的主备架构，故障切换需要秒级到分钟级
  • DB2 pureScale：基于共享磁盘的集群架构，故障切换可以在毫秒级完成
  • HADR提供灾难恢复能力，支持异地部署
  • DB2 pureScale提供更高的可用性，但部署复杂度更高
  • 可以结合使用HADR和DB2 pureScale，提供更高的可用性和灾难恢复能力