风哥教程参考DB2官方文档High Availability Disaster Recovery Guide、Database Administration等内容，详细介绍DB2 HADR的切换方式、故障转移操作、故障恢复流程以及在生产环境中的最佳实践。更多视频教程www.fgedu.net.cn
目录大纲
- Part01-HADR切换与故障转移基础概念
- Part02-生产环境HADR切换策略与规划
- Part03-生产环境HADR故障转移实施方案
- Part04-HADR故障转移生产案例与实战讲解
- Part05-风哥经验总结与分享
Part01-HADR切换与故障转移基础概念
DB2 HADR支持以下切换类型：
- 计划内切换：正常维护时的主动切换
- 故障转移：主服务器故障时的被动切换
- 手动切换：管理员手动执行的切换操作
- 自动切换：通过外部监控系统触发的自动切换
故障转移通常在以下情况下触发：
- 主服务器硬件故障
- 主服务器软件故障
- 主服务器网络故障
- 主服务器数据损坏
- 计划内维护需要
完整的故障转移流程包括：
- 故障检测：检测主服务器状态
- 决策制定：确定是否需要故障转移
- 执行切换：将备服务器提升为主服务器
- 客户端重连：应用程序连接到新的主服务器
- 原主服务器恢复：将原主服务器重新加入HADR
Part02-生产环境HADR切换策略与规划
在生产环境中，应制定以下切换策略：
- 计划内切换：选择低峰期执行，提前通知相关方
- 故障转移：建立自动检测和触发机制
- 回切策略：制定明确的回切流程和条件
- 切换频率：定期进行切换测试，确保机制正常
- 备份当前数据库状态
- 检查HADR状态，确保同步正常
- 通知相关业务方和运维团队
- 准备回滚方案
- 测试客户端重连机制
- 数据一致性风险：确保所有事务已同步
- 应用程序连接风险：确保客户端能正确重连
- 性能风险：评估切换对系统性能的影响
- 回滚风险：制定详细的回滚计划
Part03-生产环境HADR故障转移实施方案
$ su – db2inst1
# 检查HADR状态
$ db2 “GET SNAPSHOT FOR DATABASE ON fgedb | grep -A 20 HADR”
# 执行故障转移
$ db2 “TAKE OVER HADR ON DATABASE fgedb”
# 验证新主服务器状态
$ db2 “GET SNAPSHOT FOR DATABASE ON fgedb | grep -A 10 HADR role”
HADR role = PRIMARY
HADR state = PEER
# 检查数据库是否可访问
$ db2 “CONNECT TO fgedb”
$ db2 “SELECT * FROM fgedu_order”
ORDER_ID USER_ID ORDER_AMOUNT ORDER_STATUS CREATE_TIME
———– ———– ——————– ——————– ————————–
1 101 1000.00 已完成 2026-01-01-12.00.00.000000
2 102 2000.00 已完成 2026-01-01-12.00.00.000000
2 record(s) selected.
$ su – db2inst1
$ db2 “TAKE OVER HADR ON DATABASE fgedb BY FORCE”
# 注意：强制故障转移可能导致数据不一致，仅在紧急情况下使用
# 验证强制故障转移后的状态
$ db2 “GET SNAPSHOT FOR DATABASE ON fgedb | grep -A 15 HADR”
HADR role = PRIMARY
HADR state = REMOTE_CATCHUP
HADR log gap (bytes) = 10240
# 检查数据一致性
$ db2 “SELECT * FROM fgedu_order”
ORDER_ID USER_ID ORDER_AMOUNT ORDER_STATUS CREATE_TIME
———– ———– ——————– ————————–
1 101 1000.00 已完成 2026-01-01-12.00.00.000000
2 102 2000.00 已完成 2026-01-01-12.00.00.000000
2 record(s) selected.
$ su – db2inst1
# 检查原主服务器状态
$ db2 “GET DATABASE CONFIGURATION FOR fgedb | grep -A 10 HADR role”
# 启动为备服务器
$ db2 “START HADR ON DATABASE fgedb AS STANDBY”
# 验证状态
$ db2 “GET SNAPSHOT FOR DATABASE ON fgedb | grep -A 10 HADR role”
HADR role = STANDBY
HADR state = PEER
# 检查同步状态
$ db2 “SELECT HADR_ROLE, HADR_STATE, HADR_CONNECT_STATUS FROM SYSIBMADM.DB_HADR”
HADR_ROLE HADR_STATE HADR_CONNECT_STATUS
———- ———- ——————-
STANDBY PEER CONNECTED
Part04-HADR故障转移生产案例与实战讲解
# 1. 检查HADR状态
$ db2 “GET SNAPSHOT FOR DATABASE ON fgedb | grep -A 20 HADR”
# 2. 确认HADR处于PEER状态
HADR state = PEER
HADR log gap (bytes) = 0
# 3. 在备服务器上执行切换
$ db2 “TAKE OVER HADR ON DATABASE fgedb”
# 4. 验证新主服务器状态
$ db2 “GET SNAPSHOT FOR DATABASE ON fgedb | grep -A 10 HADR role”
# 5. 通知应用程序切换到新主服务器
# 6. 监控系统运行状态
# 7. 将原主服务器作为备服务器启动
$ db2 “START HADR ON DATABASE fgedb AS STANDBY”
# 8. 验证双向同步状态
$ db2 “SELECT HADR_ROLE, HADR_STATE FROM SYSIBMADM.DB_HADR”
HADR_ROLE HADR_STATE
———- ———-
PRIMARY PEER
STANDBY PEER
# 1. 在主服务器上模拟故障
$ su – db2inst1
$ db2 “DEACTIVATE DATABASE fgedb”
$ db2 “FORCE APPLICATION ALL”
# 2. 在备服务器上检测故障
$ su – db2inst1
$ db2 “GET SNAPSHOT FOR DATABASE ON fgedb | grep -A 15 HADR”
HADR state = DISCONNECTED
HADR connection status = DISCONNECTED
# 3. 执行故障转移
$ db2 “TAKE OVER HADR ON DATABASE fgedb”
# 4. 验证故障转移成功
$ db2 “GET SNAPSHOT FOR DATABASE ON fgedb | grep -A 10 HADR role”
HADR role = PRIMARY
HADR state = PEER
# 5. 恢复原主服务器
$ su – db2inst1
$ db2 “START HADR ON DATABASE fgedb AS STANDBY”
# 6. 验证系统恢复正常
$ db2 “SELECT HADR_ROLE, HADR_STATE FROM SYSIBMADM.DB_HADR”
HADR_ROLE HADR_STATE
———- ———-
PRIMARY PEER
STANDBY PEER
Part05-风哥经验总结与分享
- 定期进行故障转移演练，确保机制正常
- 建立完善的监控和告警机制
- 制定详细的故障转移流程文档
- 确保应用程序支持自动重连
- 记录每次故障转移的详细信息
- 切换失败：检查HADR状态和配置
- 数据不一致：使用强制故障转移后进行数据校验
- 客户端重连失败：检查网络配置和连接字符串
- 性能下降：优化HADR参数和网络配置
- 使用自动化工具进行故障检测和转移
- 配置适当的HADR_TIMEOUT值
- 实施多级监控和告警
- 定期备份HADR配置和状态
- 建立故障转移演练计划
学习交流加群风哥微信: itpux-com
更多视频教程www.fgedu.net.cn
from:www.itpux.com.qq113257174.wx:itpux-com
本文由风哥教程整理发布,仅用于学习测试使用,转载注明出处:http://www.fgedu.net.cn/10327.html
联系我们
在线咨询：
微信号：itpux-com
工作日：9:30-18:30，节假日休息
