TB 级 MySQL 5.7一主三从集群高可用实战记录：Orchestrator+ProxySQL方案

8TB MySQL 5.7一主三从集群高可用实战：Orchestrator+ProxySQL方案（基于Binlog Position）

一、背景与挑战

接手了一套8TB的MySQL 5.7集群，架构为一主三从，采用传统的binlog position复制。业务对可用性要求极高：主库故障需自动切换，应用无感知；原主库恢复后需重新加入集群并保证数据一致性。约束条件很明确：保持5.7版本，不升级，不引入GTID。

8TB的数据量意味着任何全量同步的操作都是灾难。PXC、MGR这类强一致方案在此场景下会因节点恢复时的全量数据传输而直接崩溃。我们需要的是一个轻量、灵活、能驾驭海量数据的高可用方案。

二、方案选型：Orchestrator + ProxySQL

这套组合是目前生产环境应对大规模MySQL主从架构最成熟的方案：

• Orchestrator：负责MySQL集群的拓扑管理和故障切换。支持binlog position模式，可自动调整复制关系，提供HTTP API便于集成，自身支持raft模式实现高可用。
• ProxySQL：负责流量治理。部署在应用和数据库之间，实现读写分离，并能通过Orchestrator的API动态感知主库变化，切换过程对应用透明。

两个组件均轻量级，对8TB数据量的集群无侵入，故障节点恢复时走增量复制而非全量同步。

三、核心配置详解

3.1 MySQL 5.7 基础配置（所有节点）

[mysqld] server_id = 1 # 每个节点唯一 log_bin = /data/mysql/binlog/mysql-bin binlog_format = ROW expire_logs_days = 7 max_binlog_size = 1G # 半同步复制（必须） plugin-load = "rpl_semi_sync_master=semisync_master.so;rpl_semi_sync_slave=semisync_slave.so" rpl_semi_sync_master_enabled = 1 rpl_semi_sync_master_timeout = 1000 # 1秒超时降级异步 rpl_semi_sync_slave_enabled = 1 # 中继日志配置 relay_log = /data/mysql/relaylog/relay-bin relay_log_purge = 1 skip_slave_start = 0

半同步是binlog position模式下保障数据不丢失的最后一道防线。配置1秒超时，兼顾性能与安全。

3.2 Orchestrator配置（关键：禁用GTID）

{"Debug":false,"MySQLTopologyCredentialsConfigFile":"/etc/orchestrator/credentials.json",// 禁用GTID，使用binlog文件+位置"RecoverMasterBinlogFileLocation":true,// 故障切换策略"MasterFailoverDetachSlaveMasterHost":true,"MasterFailoverDetachReplicaMasterHost":true,"FailMasterPromotionOnLag":10,// 延迟超过10秒的不考虑晋升// 切换前后钩子脚本"PreFailoverProcesses":["/usr/local/bin/orc-pre-failover.sh"],"PostMasterFailoverProcesses":["/usr/local/bin/orc-post-failover.sh"],// Orchestrator自身高可用（3节点raft）"RaftEnabled":true,"RaftDataDir":"/var/lib/orchestrator/raft","RaftBind":"192.168.1.101","DefaultRaftPort":10008,"RaftNodes":["192.168.1.101:10008","192.168.1.102:10008","192.168.1.103:10008"]}

关键在于RecoverMasterBinlogFileLocation: true，告诉Orchestrator使用传统复制协议。

3.3 ProxySQL配置

-- 配置后端服务器INSERTINTOmysql_servers(hostgroup_id,hostname,port,weight)VALUES(0,'192.168.1.101',3306,100),-- 初始主库（写组）(1,'192.168.1.102',3306,100),-- 从库1（读组）(1,'192.168.1.103',3306,100),-- 从库2(1,'192.168.1.104',3306,100);-- 从库3-- 读写分离规则INSERTINTOmysql_query_rules(rule_id,active,match_pattern,destination_hostgroup,apply)VALUES(1,1,'^SELECT .* FOR UPDATE',0,1),-- FOR UPDATE走主库(2,1,'^SELECT',1,1),-- 普通查询走从库(3,1,'.*',0,1);-- 其他写操作走主库

ProxySQL需配合Orchestrator的切换脚本动态更新主库IP。

四、故障切换流程（Binlog Position版）

4.1 故障检测与选主

Orchestrator检测到主库不可用后，执行选主逻辑：

1. 排除法：剔除复制中断、延迟超过10秒的从库
2. 对比binlog位置：检查每个从库的Exec_Master_Log_Pos，选择数据最新的节点
3. 验证中继日志完整性：确保该从库有完整的binlog事件可继续执行

4.2 执行切换

# Orchestrator内部操作序列# 1. 停止所有从库复制STOP SLAVE;# 2. 在选定从库上执行RESET SLAVE ALL;SET GLOBALread_only=0;# 3. 获取新主库的binlog位置SHOW MASTER STATUS;# 记录 File: mysql-bin.001234, Position: 98765432# 4. 配置其他从库指向新主库CHANGE MASTER TOMASTER_HOST='新主库IP',MASTER_PORT=3306,MASTER_LOG_FILE='mysql-bin.001234',MASTER_LOG_POS=98765432,MASTER_USER='repl_user',MASTER_PASSWORD='xxx';START SLAVE;

4.3 通知ProxySQL

通过PostMasterFailoverProcesses调用脚本：

#!/bin/bash# /usr/local/bin/notify-proxysql.shNEW_MASTER=$1mysql-hproxysql-host-P6032-uadmin-padmin<<EOF UPDATE mysql_servers SET hostgroup_id = 0 WHERE hostname = '${NEW_MASTER}'; UPDATE mysql_servers SET hostgroup_id = 1 WHERE hostname != '${NEW_MASTER}'; LOAD MYSQL SERVERS TO RUNTIME; SAVE MYSQL SERVERS TO DISK; EOF

整个过程约10-30秒，取决于从库数量和数据一致性检查耗时。

五、原主库恢复后的处理策略

针对8TB数据量，必须放弃"自动回切"的想法。全量回切意味着二次故障风险。正确做法是：

5.1 原主库作为新从库加入

# 原主库（假设192.168.1.101）恢复后执行mysql-h192.168.1.101-e" STOP SLAVE; RESET SLAVE ALL; CHANGE MASTER TO MASTER_HOST='新主库IP', MASTER_PORT=3306, MASTER_LOG_FILE='$(mysql -h新主库IP-e"SHOW MASTER STATUS\G"|grepFile)', MASTER_LOG_POS=4, -- 从开头同步 MASTER_USER='repl_user', MASTER_PASSWORD='xxx'; START SLAVE; SET GLOBAL read_only=1; "

5.2 ProxySQL自动将其加入读组

由于ProxySQL定期从Orchestrator同步拓扑信息，原主库作为只读节点上线后，会自动加入读流量分发组。

如需回切原主库，应在业务低峰期手动执行切换，并确保所有从库追上新主库进度。不建议自动回切。

六、8TB场景下的运维要点

6.1 半同步复制是生命线

-- 监控半同步状态SHOWSTATUSLIKE'Rpl_semi_sync%';-- 重点关注：-- Rpl_semi_sync_master_status: ON-- Rpl_semi_sync_slave_status: ON

确保每个从库都是半同步复制。如有从库因网络延迟频繁降级异步，应排查网络或增加超时时间。

6.2 binlog管理策略

-- 设置合理保留时间（根据磁盘容量）SETGLOBALexpire_logs_days=3;-- 定期备份binlog到其他存储# 每天凌晨备份binlogmysqlbinlog--read-from-remote-server --host=主库IP --raw mysql-bin.* > /backup/binlog/

切换时，新主库需要的binlog必须在原主库（故障后可能不可用）或备份中存在。否则切换后从库可能因找不到binlog而中断。

6.3 定期演练

每季度在业务低峰期执行切换演练：

1. 手动停止当前主库
2. 观察Orchestrator选主逻辑是否符合预期
3. 监控ProxySQL流量切换时间
4. 验证应用端无报错
5. 演练后按需回切或保持新拓扑

演练时需重点关注：选主时binlog位置的对比逻辑是否准确。这直接决定数据一致性。

七、方案的局限性（坦诚相告）

1. 切换时间不稳定：主库突然崩溃时，可能需要额外时间分析各从库的binlog位置，极端情况可达分钟级。
2. 手动干预门槛：如果所有从库均有较大延迟，需人工介入判断选哪个从库晋升（可能丢数据 vs. 可能长时间不可用）。
3. 回切复杂度：无法像GTID那样做到精确回切，需要人工规划回切窗口。
4. 数据丢失风险：即使配置半同步，主库瞬间crash且binlog损坏的极端场景下仍有小概率丢数据。

八、总结

这套Orchestrator+ProxySQL方案，在保留binlog position、MySQL 5.7、8TB数据的约束下，是当前最稳妥的高可用选型。它不要求改造现有架构，避免了PXC/MGR的海量数据同步风险，切换过程可控，运维成本相对较低。

关键在于：半同步配置到位、binlog妥善管理、定期演练验证。做到这三点，8TB集群的自动切换完全可以落地。