tidb教程FG113-TiDB高可用与灾备方案

本文档详细介绍TiDB高可用与灾备方案，包括高可用架构、灾备策略、故障切换等内容。风哥教程参考TiDB官方文档高可用指南、灾备指南等内容，适合DBA和架构师进行TiDB集群高可用和灾备设计。

Part01-基础概念与理论知识

1.1 高可用概述

高可用（High Availability，HA）是指系统在面对各种故障时，能够保持服务持续可用的能力。TiDB通过多副本、自动故障转移等机制实现高可用性。

TiDB高可用特点：

多副本设计：数据自动复制到多个节点
自动故障转移：节点故障时自动切换
无单点故障：所有组件均支持高可用
读写分离：支持读写分离，提高并发性能
水平扩展：支持在线水平扩展

1.2 灾备概述

灾备（Disaster Recovery，DR）是指在发生灾难时，能够快速恢复系统运行的能力。TiDB支持跨地域灾备，确保在区域级灾难发生时能够快速恢复服务。

# 灾备类型

# 1. 本地灾备
# – 同机房备份
# – 同城市不同机房备份
# – 适用于局部故障

# 2. 异地灾备
# – 跨城市备份
# – 跨省份备份
# – 跨国家备份
# – 适用于区域级灾难

# 3. 云灾备
# – 云服务提供商的灾备服务
# – 多可用区部署
# – 跨区域复制

# 4. 灾备级别
# – 热备：实时同步，快速切换
# – 温备：准实时同步，切换时间中等
# – 冷备：定期备份，切换时间较长

# 5. 灾备方式
# – 基于复制的灾备：使用TiDB Binlog或TiCDC风哥提示：
# – 基于备份的灾备：使用BR工具
# – 混合灾备：结合复制和备份

# 6. 灾备验证
# – 定期演练：测试灾备系统
# – 恢复测试：验证恢复流程
# – 性能测试：确保灾备系统性能

1.3 可用性等级

可用性等级是衡量系统可用程度的指标，通常用百分比表示。不同行业对可用性等级有不同的要求。

风哥提示：高可用和灾备是保障业务连续性的重要手段。根据业务需求和SLA要求，设计合适的高可用和灾备方案。更多视频教程www.fgedu.net.cn

Part02-生产环境规划与建议

2.1 高可用架构设计

# 高可用架构设计

# 1. 组件高可用
# – PD集群：至少3个节点，实现leader选举
# – TiKV集群：至少3个节点，实现数据多副本
# – TiDB集群：至少2个节点，实现负载均衡
# – TiFlash集群：至少2个节点（可选）

# 2. 部署架构
# – 单机房部署：适合测试环境
# – 多机房部署：适合生产环境
# – 跨可用区部署：提高可用性

# 3. 网络架构
# – 高带宽：确保节点间通信顺畅
# – 低延迟：减少节点间同步延迟
# – 冗余网络：多网络链路

# 4. 存储架构
# – 本地SSD：提高性能
# – 存储冗余：RAID配置
# – 容量规划：预留足够空间

# 5. 监控与告警
# – 实时监控：监控集群状态
# – 自动告警：及时发现问题
# – 故障自动处理：自动故障转移

# 6. 负载均衡
# – 前端负载均衡：分发客户端请求
# – 内部负载均衡：组件间通信负载均衡
# – 智能路由：根据负载情况路由请求

# 7. 高可用测试
# – 故障注入：模拟各种故障
# – 故障切换测试：测试故障转移
# – 性能测试：验证高负载下的可用性

# 8. 高可用最佳实践
# – 合理部署拓扑：多机房、多可用区
# – 充分冗余：每个组件至少3个节点
# – 监控到位：实时监控集群状态
# – 定期演练：测试故障切换流程

# 9. 高可用指标
# – 可用性：99.99%（年度 downtime < 52.6分钟） # - 响应时间：< 100ms # - 吞吐量：满足业务需求 # - 数据一致性：强一致性 # 10. 高可用挑战 # - 网络分区：脑裂问题 # - 性能与可用性平衡：冗余带来的性能开销 # - 成本控制：高可用架构的成本 # - 复杂度管理：架构复杂度增加

2.2 灾备策略设计

# 灾备策略设计

# 1. 灾备目标
# – 业务连续性：确保业务持续运行
# – 数据安全：保护数据不丢失
# – 快速恢复：缩短恢复时间
# – 最小损失：减少灾难带来的损失

# 2. 灾备级别
# – RPO（Recovery Point Objective）：数据丢失量
# – RTO（Recovery Time Objective）：恢复时间
# – SLA（Service Level Agreement）：服务级别协议

# 3. 灾备方案
# – 方案1：基于TiCDC的实时同步
# – RPO：几乎为0
# – RTO：分钟级
# – 适用：对数据一致性要求高的场景

# – 方案2：基于BR的定期备份
# – RPO：取决于备份频率
# – RTO：小时级
# – 适用：对恢复时间要求不高的场景

# – 方案3：混合灾备
# – 结合实时同步和定期备份
# – 提高灾备系统的可靠性

# 4. 灾备架构
# – 主从架构：一个主集群，一个或多个从集群
# – 多活架构：多个集群同时提供服务
# – 级联架构：主集群 → 从集群 → 灾备集群

# 5. 灾备部署
# – 地理分布：主集群和灾备集群分布在不同地域
# – 网络连接：主集群和灾备集群之间的网络连接
# – 带宽要求：根据数据量和同步频率确定

# 6. 灾备监控
# – 同步状态监控：监控数据同步状态学习交流加群风哥QQ113257174
# – 延迟监控：监控同步延迟
# – 灾备集群状态：监控灾备集群健康状态

# 7. 灾备演练
# – 定期演练：每季度至少一次
# – 演练内容：故障切换、恢复流程
# – 演练评估：评估演练结果，优化流程

# 8. 灾备文档
# – 灾备方案文档：详细描述灾备架构和流程
# – 操作手册：详细的操作步骤
# – 应急响应计划：灾难发生时的响应流程

# 9. 灾备测试
# – 功能测试：验证灾备系统功能
# – 性能测试：验证灾备系统性能
# – 恢复测试：验证恢复流程

# 10. 灾备成本
# – 硬件成本：服务器、存储等
# – 网络成本：跨地域网络带宽
# – 人力成本：运维人员
# – 软件成本：灾备软件

# 11. 灾备风险
# – 同步失败：数据同步中断
# – 网络故障：主备之间网络中断
# – 数据不一致：主备数据不一致
# – 演练失败：灾备演练失败

# 12. 灾备最佳实践
# – 定期备份：确保数据安全
# – 实时同步：减少数据丢失
# – 多地域部署：提高灾备可靠性
# – 定期演练：确保灾备系统可用
# – 监控到位：及时发现问题

2.3 RPO与RTO规划

# RPO与RTO规划

# 1. RPO（Recovery Point Objective）
# – 定义：灾难发生后，系统能够恢复到的最近时间点
# – 单位：时间（分钟、小时）
# – 影响因素：数据同步频率、备份频率

# 2. RTO（Recovery Time Objective）
# – 定义：从灾难发生到系统恢复正常运行的时间
# – 单位：时间（分钟、小时）
# – 影响因素：恢复流程、系统复杂度、人员响应速度

# 3. 不同业务的RPO/RTO要求
# – 金融行业：
# – RPO：< 1分钟 # - RTO：< 15分钟 # - 电商行业： # - RPO：< 5分钟 # - RTO：< 30分钟 # - 制造业： # - RPO：< 1小时 # - RTO：< 4小时 # - 政府部门： # - RPO：< 4小时 # - RTO：< 8小时 # 4. RPO/RTO实现方案 # - RPO=0：实时同步（TiCDC） # - RPO<5分钟：近实时同步（TiCDC，同步延迟<5分钟） # - RPO<1小时：定期备份（BR，每小时备份一次） # - RPO<4小时：定期备份（BR，每4小时备份一次） # - RTO<15分钟：自动化故障切换 # - RTO<30分钟：半自动故障切换 # - RTO<4小时：手动故障切换 # - RTO<8小时：手动恢复 # 5. RPO/RTO监控 # - RPO监控：监控数据同步延迟 # - RTO监控：监控故障切换时间 # - 告警设置：当RPO/RTO超过阈值时告警 # 6. RPO/RTO测试 # - 定期测试：每季度测试一次 # - 测试方法：模拟灾难，测量RPO和RTO # - 测试记录：记录测试结果，持续改进 # 7. RPO/RTO优化 # - 优化同步机制：减少同步延迟 # - 优化恢复流程：缩短恢复时间 # - 自动化操作：减少人工干预 # - 并行处理：提高恢复速度 # 8. RPO/RTO成本平衡 # - 低RPO/RTO：成本高 # - 高RPO/RTO：成本低 # - 根据业务需求和预算，选择合适的RPO/RTO目标 # 9. RPO/RTO文档 # - 明确定义RPO/RTO目标 # - 记录RPO/RTO测试结果 # - 制定RPO/RTO改进计划 # 10. RPO/RTO演练 # - 演练目的：验证RPO/RTO目标是否达到 # - 演练流程：模拟灾难 → 执行恢复 → 测量时间 # - 演练评估：评估演练结果，优化流程

生产环境建议：根据业务的重要性和对数据一致性的要求，制定合理的RPO和RTO目标。建议采用混合灾备方案，结合实时同步和定期备份，提高灾备系统的可靠性。学习交流加群风哥微信:
itpux-com

Part03-生产环境项目实施方案

3.1 高可用实施方案

3.1.1 多节点部署

# 多节点部署

# 1. 集群拓扑
# 节点分布：
# – PD节点：3个（192.168.1.10, 192.168.1.11, 192.168.1.12）
# – TiKV节点：3个（192.168.1.10, 192.168.1.11, 192.168.1.12）
# – TiDB节点：2个（192.168.1.13, 192.168.1.14）
# – TiFlash节点：2个（192.168.1.15, 192.168.1.16）

# 2. 部署配置
# 创建拓扑文件
cat > topology.yaml << EOF global: user: "tidb" ssh_port: 22 deploy_dir: "/tidb/deploy" data_dir: "/tidb/data" pd_servers: - host: 192.168.1.10 - host: 192.168.1.11 - host: 192.168.1.12 tikv_servers: - host: 192.168.1.10 - host: 192.168.1.11 - host: 192.168.1.12 tidb_servers: - host: 192.168.1.13 - host: 192.168.1.14 tiflash_servers: - host: 192.168.1.15 - host: 192.168.1.16 monitoring_servers: - host: 192.168.1.20 grafana_servers: - host: 192.168.1.20 alertmanager_servers: - host: 192.168.1.20 EOF # 部署集群 [root@fgedu.net.cn ~]# tiup cluster deploy fgedudb v7.5.0 topology.yaml --user root -p # 启动集群 [root@fgedu.net.cn ~]# tiup cluster start fgedudb # 3. 高可用配置 # 配置TiKV副本数 [root@fgedu.net.cn ~]# tiup ctl:v7.5.0 pd -u http://192.168.1.10:2379 config set replication.location-labels "zone,rack,host" # 配置TiKV存储池 [root@fgedu.net.cn ~]# tiup ctl:v7.5.0 pd -u http://192.168.1.10:2379 config set storage.schedule-policy "balance" # 4. 负载均衡 # 配置HAProxy cat>
/etc/haproxy/haproxy.cfg << EOF frontend tidb-frontend bind *:4000 mode tcp default_backend tidb-backend backend tidb-backend mode tcp balance roundrobin server tidb1 192.168.1.13:4000 check inter 2000 rise 2 fall 3 server tidb2 192.168.1.14:4000 check inter 2000 rise 2 fall 3 EOF # 重启HAProxy [root@fgedu.net.cn ~]# systemctl restart haproxy # 5. 监控配置 # 配置Prometheus告警规则 # 参考监控文档（略） # 6. 高可用测试 # 测试TiDB节点故障 [root@fgedu.net.cn ~]# tiup cluster stop fgedudb -R tidb-192.168.1.13 # 验证服务是否可用 [root@fgedu.net.cn ~]# mysql -h192.168.1.20 -P4000 -u root -p'root123' -e "SELECT 1;" # 测试TiKV节点故障 [root@fgedu.net.cn ~]# tiup cluster stop fgedudb -R tikv-192.168.1.10 # 验证数据是否可用 [root@fgedu.net.cn ~]# mysql -h192.168.1.20 -P4000 -u root -p'root123' -e "SELECT * FROM fgedudb.fgedu_users LIMIT 10;" # 测试PD节点故障 [root@fgedu.net.cn ~]# tiup cluster stop fgedudb -R pd-192.168.1.10 # 验证集群是否正常 [root@fgedu.net.cn ~]# tiup cluster status fgedudb # 7. 高可用验证 # 检查集群状态 [root@fgedu.net.cn ~]# tiup cluster display fgedudb # 检查PD leader [root@fgedu.net.cn ~]# tiup ctl:v7.5.0 pd -u http://192.168.1.11:2379 member # 检查TiKV副本状态 [root@fgedu.net.cn ~]# tiup ctl:v7.5.0 pd -u http://192.168.1.11:2379 store # 检查TiDB状态 [root@fgedu.net.cn ~]# tiup cluster status fgedudb | grep tidb # 8. 高可用维护 # 滚动升级 [root@fgedu.net.cn ~]# tiup cluster upgrade fgedudb v7.5.1 # 滚动重启 [root@fgedu.net.cn ~]# tiup cluster restart fgedudb --rolling # 扩容节点 [root@fgedu.net.cn ~]# tiup cluster scale-out fgedudb scale-out.yaml # 缩容节点 [root@fgedu.net.cn ~]# tiup cluster scale-in fgedudb --nodes 192.168.1.17:4000 # 9. 高可用最佳实践 # 定期检查集群状态 # 定期备份数据 # 定期进行故障演练 # 保持系统更新 # 监控到位

3.1.2 多机房部署

# 多机房部署

# 1. 部署架构
# 三机房部署：
# – 机房A：192.168.1.0/24
# – 机房B：192.168.2.0/24
# – 机房C：192.168.3.0/24

# 节点分布：
# – 每个机房1个PD节点
# – 每个机房1个TiKV节点
# – 每个机房1个TiDB节点

# 2. 网络配置
# 配置跨机房网络
# 确保机房间网络带宽充足（至少1Gbps）
# 确保机房间网络延迟低（< 10ms） # 3. 部署配置 # 创建拓扑文件 cat> multi-dc-topology.yaml << EOF global: user: "tidb" ssh_port: 22 deploy_dir: "/tidb/deploy" data_dir: "/tidb/data" pd_servers: - host: 192.168.1.10 labels: zone: "dc1" - host: 192.168.2.10 labels: zone: "dc2" - host: 192.168.3.10 labels: zone: "dc3" tikv_servers: - host: 192.168.1.11 labels: zone: "dc1" - host: 192.168.2.11 labels: zone: "dc2" - host: 192.168.3.11 labels: zone: "dc3" tidb_servers: - host: 192.168.1.12 labels: zone: "dc1" - host: 192.168.2.12 labels: zone: "dc2" - host: 192.168.3.12 labels: zone: "dc3" EOF # 部署集群 [root@fgedu.net.cn ~]# tiup cluster deploy fgedudb-multi-dc v7.5.0 multi-dc-topology.yaml --user root -p # 启动集群 [root@fgedu.net.cn ~]# tiup cluster start fgedudb-multi-dc # 4. 高可用配置 # 配置副本策略 [root@fgedu.net.cn ~]# tiup ctl:v7.5.0 pd -u http://192.168.1.10:2379 config set replication.location-labels "zone" [root@fgedu.net.cn ~]# tiup ctl:v7.5.0 pd -u http://192.168.1.10:2379 config set replication.max-replicas 3 # 配置调度策略 [root@fgedu.net.cn ~]# tiup ctl:v7.5.0 pd -u http://192.168.1.10:2379 config set storage.schedule-policy "balance" # 5. 负载均衡 # 配置多机房负载均衡 cat> /etc/haproxy/haproxy.cfg << EOF frontend tidb-frontend bind *:4000 mode tcp default_backend tidb-backend backend tidb-backend mode tcp balance roundrobin server tidb1 192.168.1.12:4000 check inter 2000 rise 2 fall 3 server tidb2 192.168.2.12:4000 check inter 2000 rise 2 fall 3 server tidb3 192.168.3.12:4000 check inter 2000 rise 2 fall 3 EOF # 重启HAProxy [root@fgedu.net.cn ~]# systemctl restart haproxy # 6. 多机房测试 # 测试单机房故障 [root@fgedu.net.cn ~]# # 模拟机房A故障，关闭所有机房A的节点 # 验证服务是否可用 [root@fgedu.net.cn ~]# mysql -h192.168.1.20 -P4000 -u root -p'root123' -e "SELECT 1;" # 验证数据是否完整 [root@fgedu.net.cn ~]# mysql -h192.168.1.20 -P4000 -u root -p'root123' -e "SELECT COUNT(*) FROM fgedudb.fgedu_users;" # 7. 多机房恢复 # 恢复机房A节点 [root@fgedu.net.cn ~]# tiup cluster start fgedudb-multi-dc -R pd-192.168.1.10,tikv-192.168.1.11,tidb-192.168.1.12 # 验证集群状态 [root@fgedu.net.cn ~]# tiup cluster status fgedudb-multi-dc # 8. 多机房最佳实践 # 确保机房间网络稳定 # 配置合理的副本策略 # 定期测试机房故障场景 # 监控跨机房网络状态 # 制定机房故障应急预案

3.2 灾备实施方案

3.2.1 基于TiCDC的灾备方案

# 基于TiCDC的灾备方案

# 1. 环境准备
# 主集群：192.168.1.0/24
# 灾备集群：192.168.2.0/24
# TiCDC版本：v7.5.0

# 2. 部署主集群
# 参考多节点部署（略）

# 3. 部署灾备集群
# 参考多节点部署（略）

# 4. 部署TiCDC
# 在主集群部署TiCDC
cat > cdc-topology.yaml << EOF global: user: "tidb" ssh_port: 22 deploy_dir: "/tidb/deploy" data_dir: "/tidb/data" cdc_servers: - host: 192.168.1.15 - host: 192.168.1.16 EOF # 部署TiCDC [root@fgedu.net.cn ~]# tiup cluster deploy fgedudb v7.5.0 topology.yaml --user root -p # 启动TiCDC [root@fgedu.net.cn ~]# tiup cluster start fgedudb -R cdc # 5. 配置TiCDC同步任务 # 创建同步任务配置文件 cat> cdc-task.yaml << EOF # 任务名称 name: "replication-task" # 源集群信息 from: host: "192.168.1.10" port: 2379 user: "root" password: "root123" # 目标集群信息 to: host: "192.168.2.10" port: 2379 user: "root" password: "root123" # 同步配置 config: # 同步模式：full（全量+增量） replication-mode: "full" # 同步的数据库 filter: rules: - database: "fgedudb" tables: - table: ".*" EOF # 创建同步任务 [root@fgedu.net.cn ~]# tiup ctl:v7.5.0 cdc changefeed create --pd=http://192.168.1.10:2379 --sink-uri="tidb://root:root123@192.168.2.13:4000/fgedudb" --config=cdc-task.yaml # 6. 监控同步状态 # 查看同步任务状态 [root@fgedu.net.cn ~]# tiup ctl:v7.5.0 cdc changefeed list --pd=http://192.168.1.10:2379 # 查看同步任务详情 [root@fgedu.net.cn ~]# tiup ctl:v7.5.0 cdc changefeed query --pd=http://192.168.1.10:2379 --changefeed-id=replication-task # 查看同步延迟 [root@fgedu.net.cn ~]# tiup ctl:v7.5.0 cdc changefeed status --pd=http://192.168.1.10:2379 --changefeed-id=replication-task # 7. 灾备测试 # 模拟主集群故障 [root@fgedu.net.cn ~]# tiup cluster stop fgedudb # 验证灾备集群数据 [root@fgedu.net.cn ~]# mysql -h192.168.2.13 -P4000 -u root -p'root123' -e " SELECT COUNT(*) FROM fgedudb.fgedu_users; SELECT * FROM fgedudb.fgedu_users ORDER BY id DESC LIMIT 10; " # 切换业务到灾备集群 # 修改应用连接地址为灾备集群 # 8. 主集群恢复 # 恢复主集群 [root@fgedu.net.cn ~]# tiup cluster start fgedudb # 重新配置同步任务（反向同步） cat> cdc-task-reverse.yaml << EOF name: "replication-task-reverse" from: host: "192.168.2.10" port: 2379 user: "root" password: "root123" to: host: "192.168.1.10" port: 2379 user: "root" password: "root123" config: replication-mode: "full" filter: rules: - database: "fgedudb" tables: - table: ".*" EOF # 创建反向同步任务 [root@fgedu.net.cn ~]# tiup ctl:v7.5.0 cdc changefeed create --pd=http://192.168.2.10:2379 --sink-uri="tidb://root:root123@192.168.1.13:4000/fgedudb" --config=cdc-task-reverse.yaml # 等待数据同步完成 # 切换业务回主集群 # 修改应用连接地址为主集群 # 9. TiCDC灾备最佳实践 # 部署多个TiCDC节点，提高可靠性 # 监控同步状态，及时发现问题 # 定期测试灾备集群，确保可用 # 制定详细的故障切换流程 # 保持主备集群版本一致 # 10. 常见问题处理 # 同步延迟：检查网络带宽，调整TiCDC配置 # 同步失败：查看TiCDC日志，分析失败原因 # 数据不一致：重新初始化同步任务 # 网络中断：网络恢复后，TiCDC会自动继续同步

3.2.2 基于BR的灾备方案

# 基于BR的灾备方案

# 1. 环境准备
# 主集群：192.168.1.0/24
# 灾备集群：192.168.2.0/24
# 备份存储：S3兼容存储

# 2. 部署主集群和灾备集群
# 参考多节点部署（略）

# 3. 配置备份存储
# 创建S3配置文件
cat > backup-config.toml << EOF [storage] backend="s3" [storage.s3] bucket="tidb-backup" prefix="fgedudb" region="us-east-1" access-key="AKI..." secret-access-key="SK..." EOF # 4. 执行全量备份 [root@fgedu.net.cn ~]# tiup br backup full --pd "192.168.1.10:2379" \ --storage "s3://tidb-backup/fgedudb/full" \ --config backup-config.toml # 5. 恢复到灾备集群 [root@fgedu.net.cn ~]# tiup br restore full --pd "192.168.2.10:2379" \ --storage "s3://tidb-backup/fgedudb/full" \ --config backup-config.toml # 6. 定期增量备份 # 创建增量备份脚本 cat> incremental-backup.sh << EOF #!/bin/bash DATE=$(date +%Y%m%d%H%M%S) # 执行增量备份 tiup br backup incremental --pd "192.168.1.10:2379" \ --storage "s3://tidb-backup/fgedudb/incremental/$DATE" \ --last-backup "s3://tidb-backup/fgedudb/full" \ --config backup-config.toml # 恢复到灾备集群 tiup br restore incremental --pd "192.168.2.10:2379" \ --storage "s3://tidb-backup/fgedudb/incremental/$DATE" \ --last-backup "s3://tidb-backup/fgedudb/full" \ --config backup-config.toml EOF # 设置定时任务 [root@fgedu.net.cn ~]# crontab -e # 添加以下行（每小时执行一次） 0 * * * * /root/incremental-backup.sh>> /var/log/backup.log 2>&1

# 7. 灾备测试
# 模拟主集群故障
[root@fgedu.net.cn ~]# tiup cluster stop fgedudb

# 验证灾备集群数据
[root@fgedu.net.cn ~]# mysql -h192.168.2.13 -P4000 -u root -p’root123′ -e ”
SELECT COUNT(*) FROM fgedudb.fgedu_users;
SELECT * FROM fgedudb.fgedu_users ORDER BY id DESC LIMIT 10;
”

# 切换业务到灾备集群
# 修改应用连接地址为灾备集群

# 8. 主集群恢复
# 恢复主集群
[root@fgedu.net.cn ~]# tiup cluster start fgedudb

# 从灾备集群备份恢复到主集群
[root@fgedu.net.cn ~]# tiup br backup full –pd “192.168.2.10:2379” \
–storage “s3://tidb-backup/fgedudb/restore” \
–config backup-config.toml

[root@fgedu.net.cn ~]# tiup br restore full –pd “192.168.1.10:2379” \
–storage “s3://tidb-backup/fgedudb/restore” \
–config backup-config.toml

# 切换业务回主集群
# 修改应用连接地址为主集群

# 9. BR灾备最佳实践
# 定期执行全量备份
# 频繁执行增量备份
# 验证备份文件的完整性
# 定期测试恢复流程
# 存储备份到多个位置

# 10. 常见问题处理
# 备份失败：检查存储连接，查看BR日志
# 恢复失败：检查备份文件，查看BR日志
# 备份时间长：调整BR并发参数，选择业务低峰期
# 存储空间不足：清理过期备份，增加存储容量

3.3 故障切换与测试

3.3.1 故障切换流程

# 故障切换流程

# 1. 故障检测
# – 监控系统检测到主集群故障
# – 人工确认故障情况
# – 评估故障影响范围

# 2. 故障切换决策
# – 确认主集群无法短时间恢复
# – 启动故障切换流程
# – 通知相关人员

# 3. 切换准备
# – 验证灾备集群状态
# – 确认灾备集群数据完整性
# – 准备应用切换

# 4. 执行切换
# – 修改DNS或负载均衡配置
# – 修改应用连接地址
# – 启动应用服务

# 5. 切换验证
# – 验证应用服务正常
# – 验证数据完整性
# – 监控系统运行状态

# 6. 故障切换脚本
# 创建故障切换脚本
cat > failover.sh << EOF #!/bin/bash # 故障切换脚本 # from:www.itpux.com.qq113257174.wx:itpux-com # web: `http://www.fgedu.net.cn` echo "开始故障切换..." # 1. 检查灾备集群状态 echo "检查灾备集群状态..." tiup cluster status fgedudb-dr # 2. 验证灾备集群数据 echo "验证灾备集群数据..." mysql -h192.168.2.13 -P4000 -u root -p'root123' -e " SELECT COUNT(*) FROM fgedudb.fgedu_users; SELECT COUNT(*) FROM fgedudb.fgedu_orders; " # 3. 修改负载均衡配置 echo "修改负载均衡配置..." sed -i 's/192.168.1.13:4000/192.168.2.13:4000/g' /etc/haproxy/haproxy.cfg systemctl restart haproxy # 4. 验证切换结果 echo "验证切换结果..." mysql -h192.168.1.20 -P4000 -u root -p'root123' -e "SELECT 1;" mysql -h192.168.1.20 -P4000 -u root -p'root123' -e "SELECT NOW();" echo "故障切换完成！" EOF # 赋予执行权限 [root@fgedu.net.cn ~]# chmod +x failover.sh # 执行故障切换 [root@fgedu.net.cn ~]# ./failover.sh # 7. 故障回切流程 # - 主集群恢复正常 # - 数据同步完成 # - 执行回切操作 # - 验证回切结果 # 8. 故障切换测试 # 定期执行故障切换测试 # 记录切换时间和结果 # 优化切换流程 # 9. 故障切换最佳实践 # 制定详细的切换流程 # 定期演练切换流程 # 自动化切换操作 # 建立切换审批机制 # 记录切换过程和结果 # 10. 切换时间优化 # 减少人工干预 # 自动化切换操作 # 优化网络配置 # 预配置切换资源

3.3.2 故障演练

# 故障演练

# 1. 演练准备
# – 制定演练计划
# – 通知相关人员
# – 准备演练环境
# – 备份数据

# 2. 演练步骤

# 步骤1：模拟主集群故障
# 停止主集群
[root@fgedu.net.cn ~]# tiup cluster stop fgedudb

# 步骤2：执行故障切换
# 运行切换脚本
[root@fgedu.net.cn ~]# ./failover.sh

# 步骤3：验证灾备集群
# 检查集群状态
[root@fgedu.net.cn ~]# tiup cluster status fgedudb-dr

# 验证业务功能
[root@fgedu.net.cn ~]# mysql -h192.168.1.20 -P4000 -u root -p’root123′ -e ”
SELECT * FROM fgedudb.fgedu_users LIMIT 10;
INSERT INTO fgedudb.fgedu_users (username, email) VALUES (‘test’,
‘test@fgedu.net.cn’);
SELECT * FROM fgedudb.fgedu_users WHERE username = ‘test’;
”

# 步骤4：恢复主集群
# 启动主集群
[root@fgedu.net.cn ~]# tiup cluster start fgedudb

# 步骤5：数据同步
# 执行反向同步
[root@fgedu.net.cn ~]# tiup ctl:v7.5.0 cdc changefeed create
–pd=http://192.168.2.10:2379
–sink-uri=”tidb://root:root123@192.168.1.13:4000/fgedudb”
–config=cdc-task-reverse.yaml

# 步骤6：回切操作
# 修改负载均衡配置
[root@fgedu.net.cn ~]# sed -i ‘s/192.168.2.13:4000/192.168.1.13:4000/g’
/etc/haproxy/haproxy.cfg
[root@fgedu.net.cn ~]# systemctl restart haproxy

# 步骤7：验证回切结果
# 检查主集群状态
[root@fgedu.net.cn ~]# tiup cluster status fgedudb

# 验证业务功能
[root@fgedu.net.cn ~]# mysql -h192.168.1.20 -P4000 -u root -p’root123′ -e ”
SELECT * FROM fgedudb.fgedu_users WHERE username = ‘test’;
”

# 3. 演练评估
# – 评估切换时间
# – 评估数据完整性
# – 评估业务影响
# – 评估演练过程中的问题

# 4. 演练报告
# 演练报告示例：
# 演练时间：2024-04-09 14:00-16:00
# 演练场景：主集群故障
# 切换时间：5分钟
# 数据完整性：100%
# 业务影响：无
# 问题发现：无
# 改进建议：无

# 5. 演练频率
# 建议每季度执行一次完整的故障演练
# 每月执行一次部分演练（如单节点故障）

# 6. 演练最佳实践
# 模拟真实故障场景
# 严格按照流程执行
# 记录演练过程和结果
# 分析问题并持续改进
# 培训相关人员

# 7. 演练工具
# 使用TiUP管理集群
# 使用监控工具观察集群状态
# 使用自动化脚本执行切换操作

# 8. 演练注意事项
# 选择业务低峰期进行演练
# 提前通知相关人员
# 准备回滚方案
# 确保数据安全
# 记录所有操作

风哥提示：故障演练是确保灾备系统有效的重要手段。通过定期演练，可以发现灾备系统的问题，优化切换流程，提高应对真实故障的能力。学习交流加群风哥QQ113257174

Part04-生产案例与实战讲解

4.1 高可用案例

# 高可用案例：金融行业TiDB集群

# 场景：金融行业核心交易系统，要求99.99%可用性

# 1. 架构设计
# – 三机房部署：
# – 机房A：北京
# – 机房B：上海
# – 机房C：深圳

# – 节点配置：
# – 每个机房2个PD节点
# – 每个机房3个TiKV节点
# – 每个机房2个TiDB节点
# – 每个机房1个TiFlash节点

# – 网络配置：
# – 机房间专线连接，带宽10Gbps
# – 网络延迟<5ms # - 多路由冗余 # 2. 高可用配置 # - 副本策略：3副本，每个机房1个副本 # - 调度策略：balance # - 负载均衡：前端F5负载均衡 # - 监控：Prometheus + Grafana + AlertManager # 3. 高可用测试 # - 单节点故障：自动故障转移，无业务影响 # - 单机房故障：系统继续运行，性能略有下降 # - 网络分区：脑裂防护，确保数据一致性 # 4. 高可用效果 # - 可用性：99.99%（年度downtime<52.6分钟） # - 响应时间：<50ms # - 吞吐量：10000 QPS # - 故障恢复：自动故障转移，无需人工干预 # 5. 经验总结 # - 多机房部署是实现高可用的关键 # - 合理的副本策略确保数据安全 # - 自动化故障转移减少人工干预 # - 完善的监控系统及时发现问题 # - 定期演练提高应对故障的能力 # 6. 最佳实践 # - 采用多机房部署架构 # - 配置合理的副本策略 # - 实施自动化故障转移 # - 建立完善的监控体系 # - 定期进行故障演练 # 7. 技术挑战 # - 跨机房网络延迟 # - 数据同步一致性 # - 故障切换时间 # - 成本控制 # 8. 解决方案 # - 优化网络配置，减少延迟 # - 使用TiCDC确保数据一致性 # - 自动化故障切换流程 # - 合理规划资源，控制成本

4.2 灾备案例

# 灾备案例：电商平台TiDB集群

# 场景：电商平台，要求RPO<1分钟，RTO<15分钟 # 1. 灾备架构 # - 主集群：华东地区 # - 灾备集群：华北地区 # - 距离：约1000公里 # - 网络：专线连接，带宽2Gbps # 2. 灾备方案 # - 基于TiCDC的实时同步 # - 全量备份 + 增量备份 # - 定期演练 # 3. 实施步骤 # - 部署主集群和灾备集群 # - 配置TiCDC同步任务 # - 配置定期备份 # - 配置监控和告警 # 4. 灾备测试 # - 演练时间：2024-04-09 22:00-23:00 # - 演练场景：主集群故障 # - 切换时间：8分钟 # - 数据丢失：0 # - 业务影响：无 # 5. 实际故障应对 # - 故障时间：2024-05-15 10:00 # - 故障原因：主集群所在机房电力中断 # - 故障处理： # 1. 10:05：发现主集群故障 # 2. 10:08：启动故障切换流程 # 3. 10:15：完成切换，业务恢复 # 4. 12:00：主集群恢复供电 # 5. 14:00：数据同步完成，回切到主集群 # 6. 灾备效果 # - RPO：<1分钟 # - RTO：7分钟 # - 数据完整性：100% # - 业务连续性：无中断 # 7. 经验总结 # - 实时同步是实现低RPO的关键 # - 自动化切换流程减少RTO # - 定期演练确保灾备系统有效 # - 完善的监控系统及时发现故障 # - 跨地域部署提高灾备可靠性 # 8. 最佳实践 # - 采用实时同步方案 # - 配置自动化切换流程 # - 定期进行灾备演练 # - 建立完善的监控体系 # - 制定详细的故障响应计划 # 9. 技术挑战 # - 跨地域网络延迟 # - 数据同步一致性 # - 切换流程复杂性 # - 成本控制 # 10. 解决方案 # - 优化网络配置，减少延迟 # - 使用TiCDC确保数据一致性 # - 自动化切换流程 # - 合理规划资源，控制成本

4.3 故障切换案例

# 故障切换案例：制造业TiDB集群

# 场景：制造业ERP系统，要求RTO<30分钟 # 1. 故障情况 # - 时间：2024-06-20 08:30 # - 地点：主集群所在机房 # - 原因：网络设备故障，导致主集群无法访问 # 2. 故障检测 # - 08:32：监控系统告警 # - 08:33：运维人员确认故障 # - 08:35：评估故障影响，决定启动故障切换 # 3. 故障切换过程 # - 08:35：启动故障切换流程 # - 08:36：验证灾备集群状态 # - 08:38：修改DNS配置，将业务流量切换到灾备集群 # - 08:40：验证业务功能 # - 08:45：业务恢复正常 # 4. 切换结果 # - RTO：15分钟 # - 数据丢失：无（基于TiCDC实时同步） # - 业务影响：最小化 # - 用户感知：无明显中断 # 5. 故障恢复 # - 09:30：网络设备修复 # - 10:00：主集群恢复正常 # - 10:30：数据同步完成 # - 11:00：回切到主集群 # - 11:10：业务恢复到主集群 # 6. 经验总结 # - 快速响应是减少业务影响的关键 # - 自动化切换流程提高效率 # - 实时同步确保数据一致性 # - 完善的监控系统及时发现故障 # - 定期演练提高应对能力 # 7. 改进措施 # - 优化网络架构，增加冗余 # - 进一步自动化切换流程 # - 加强监控，提高故障检测速度 # - 定期更新灾备方案 # 8. 切换流程优化 # - 制定详细的切换步骤 # - 明确各角色职责 # - 建立切换审批机制 # - 记录切换过程和结果 # - 定期演练和优化 # 9. 技术要点 # - 实时数据同步 # - 自动化切换 # - 网络配置优化 # - 监控告警 # - 故障演练 # 10. 最佳实践 # - 建立完善的故障响应机制 # - 定期进行故障演练 # - 自动化切换流程 # - 实时监控系统状态 # - 建立详细的切换文档

风哥提示：故障切换是灾备系统的核心功能，通过定期演练和优化，可以确保在真实故障发生时能够快速、有序地进行切换，减少业务影响。更多学习教程公众号风哥教程itpux_com

Part05-风哥经验总结与分享

5.1 高可用与灾备最佳实践

多副本设计：配置合理的副本策略，确保数据安全
多机房部署：跨机房部署，提高系统可用性
实时同步：使用TiCDC实现实时数据同步，减少数据丢失
定期备份：结合定期备份，提高数据安全性
自动化故障转移：减少人工干预，提高故障恢复速度
完善的监控：实时监控系统状态，及时发现问题
定期演练：定期进行故障演练，确保灾备系统有效
详细的文档：建立完善的运维文档，包括架构、流程、操作步骤等
持续优化：根据实际运行情况，持续优化高可用和灾备方案
培训与意识：对运维人员进行培训，提高安全意识

5.2 常见问题与解决方案

# 常见高可用与灾备问题及解决方案

# 问题1：网络分区
# 原因：
# – 网络设备故障
# – 网络配置错误
# – 自然灾害导致网络中断
# 解决方案：
# – 配置多网络链路
# – 实施脑裂防护
# – 配置合理的超时参数
# – 定期检查网络状态

# 问题2：数据同步延迟
# 原因：
# – 网络带宽不足
# – 网络延迟高
# – 数据量过大
# – TiCDC配置不当
# 解决方案：
# – 增加网络带宽
# – 优化网络配置
# – 调整TiCDC参数
# – 合理规划数据量

# 问题3：故障切换失败
# 原因：
# – 切换流程不明确
# – 灾备集群状态异常
# – 数据不一致
# – 人工操作错误
# 解决方案：
# – 制定详细的切换流程
# – 定期测试灾备集群
# – 确保数据一致性
# – 自动化切换操作

# 问题4：灾备集群性能不足
# 原因：
# – 硬件配置不足
# – 资源分配不合理
# – 配置不当
# 解决方案：
# – 合理配置硬件资源
# – 优化参数配置
# – 定期性能测试
# – 根据业务需求调整资源

# 问题5：备份失败
# 原因：
# – 存储连接失败
# – 存储空间不足
# – 备份参数配置不当
# – 系统负载过高
# 解决方案：
# – 检查存储连接
# – 确保存储空间充足
# – 优化备份参数
# – 选择业务低峰期进行备份

# 问题6：恢复时间过长
# 原因：
# – 数据量过大
# – 存储性能不足
# – 恢复参数配置不当
# – 人工操作时间长
# 解决方案：
# – 优化恢复参数
# – 使用高性能存储
# – 自动化恢复操作
# – 并行恢复处理

# 问题7：数据不一致
# 原因：
# – 同步中断
# – 同步配置错误
# – 冲突处理不当
# – 手动操作失误
# 解决方案：
# – 监控同步状态
# – 正确配置同步参数
# – 实施冲突处理机制
# – 减少手动操作

# 问题8：监控告警不足
# 原因：
# – 监控覆盖不全面
# – 告警阈值设置不当
# – 告警通知渠道不畅
# – 监控系统故障
# 解决方案：
# – 建立全面的监控体系
# – 配置合理的告警阈值
# – 多渠道告警通知
# – 监控系统高可用

# 问题9：演练效果不佳
# 原因：
# – 演练流程不明确
# – 演练准备不充分
# – 参与人员不熟悉流程
# – 演练环境与生产环境差异大
# 解决方案：
# – 制定详细的演练计划
# – 充分准备演练环境
# – 对参与人员进行培训
# – 模拟真实故障场景

# 问题10：成本控制困难
# 原因：
# – 硬件成本高
# – 网络成本高
# – 人力成本高
# – 软件成本高
# 解决方案：
# – 合理规划资源
# – 优化网络配置
# – 自动化运维
# – 选择合适的灾备方案

5.3 高可用与灾备检查清单

#!/bin/bash
# tidb-ha-dr-checklist.sh
# from:www.itpux.com.qq113257174.wx:itpux-com
# web: `http://www.fgedu.net.cn`

# TiDB高可用与灾备检查清单

echo “=== TiDB高可用与灾备检查清单 ===”

# 1. 高可用配置检查
echo “[ ] 集群节点数量是否充足？”
echo “[ ] 副本策略是否合理？”
echo “[ ] 故障转移是否自动？”
echo “[ ] 负载均衡是否配置？”
echo “[ ] 监控告警是否完善？”

# 2. 灾备配置检查
echo “[ ] 灾备集群是否部署？”
echo “[ ] 数据同步是否配置？”
echo “[ ] 备份策略是否制定？”
echo “[ ] 灾备监控是否到位？”
echo “[ ] 灾备文档是否完善？”

# 3. 网络配置检查
echo “[ ] 网络带宽是否充足？”
echo “[ ] 网络延迟是否合理？”
echo “[ ] 网络冗余是否配置？”
echo “[ ] 跨机房网络是否稳定？”
echo “[ ] 网络监控是否到位？”

# 4. 数据同步检查
echo “[ ] 同步状态是否正常？”
echo “[ ] 同步延迟是否在可接受范围？”
echo “[ ] 同步配置是否正确？”
echo “[ ] 同步监控是否到位？”
echo “[ ] 同步故障处理是否有预案？”

# 5. 备份检查
echo “[ ] 全量备份是否定期执行？”
echo “[ ] 增量备份是否配置？”
echo “[ ] 备份存储是否安全？”
echo “[ ] 备份验证是否定期进行？”
echo “[ ] 备份恢复测试是否执行？”

# 6. 故障切换检查
echo “[ ] 切换流程是否明确？”
echo “[ ] 切换脚本是否准备？”
echo “[ ] 切换测试是否定期执行？”
echo “[ ] 切换时间是否在RTO范围内？”
echo “[ ] 切换文档是否完善？”

# 7. 监控告警检查
echo “[ ] 集群状态是否监控？”
echo “[ ] 同步状态是否监控？”
echo “[ ] 备份状态是否监控？”
echo “[ ] 告警阈值是否合理？”
echo “[ ] 告警通知是否及时？”

# 8. 演练检查
echo “[ ] 故障演练是否定期执行？”

本文由风哥教程整理发布,仅用于学习测试使用,转载注明出处:http://www.fgedu.net.cn/10327.html