MySQL高可用架构实战：17年运维经验谈自动容灾

　　MySQL高可用架构实战：17年运维经验谈自动容灾——这标题不是我拍脑袋想的，是去年暑假在杭州某城商行做RPO压测时，现场白板上随手写的，后来贴在机房值班台玻璃上三年没撕，字迹都泛黄了。

文章配图，仅供参考

　　去年暑假那场故障真实得像段bug录像：7月22日凌晨3:17，杭州数据中心主库节点因电源模块老化导致IO hang，备库同步延迟从800ms瞬间飙到37秒——但Switchover触发只用了6.3秒，业务订单系统连重试都没走完。我们用的是MGR单主模式+自研心跳探针，探测间隔设成800ms（比官方推荐值少200ms），这个数字是2021年东莞某厂产线数据库宕机后我们用tcpdump抓包反复调出来的——快200ms，就能卡在MySQL内部binlog写入完成但relay log还没刷盘的窗口期，避免二次脑裂。

　　新技术。

　　但去年暑假那次成功切换背后，其实压着三个没公开的失败案例：2023年4月绍兴某医保平台升级MGR 8.0.32后，GTID_PURGED字段在跨版本重建备库时被错误截断17位，导致从库复制线程 silently 跳过11条关键DDL；2022年11月宁波某物流系统误将proxySQL的slow_query_log阈值设为500ms（实际业务P95是423ms），结果主库崩溃时路由层把重试流量全导给半同步未确认的备库，造成2.3分钟数据覆盖；最狠的是2021年6月金华某政务云环境——他们抄了网上某篇“零配置MHA”教程，在/etc/hosts里手写了一组IP别名，结果K8s节点漂移后etcd同步延迟，hosts文件没刷新，MHA监控脚本持续ping错地址达14分钟，等发现时主库磁盘已满。这些坑，文档里一个字不提，培训视频里永远只有绿框框的success弹窗。

　　我自己掏钱在阿里云买了三台ECS搭过127个不同参数组合的MGR集群——2020年用5.7.28试过disable_log_bin=ON启动从库，结果INSERT…SELECT语句在GTID下直接报错ER_GTID_MODE_ON；2023年拿8.0.33跑sysbench-tpcc压测时发现，当innodb_flush_log_at_trx_commit=2且sync_binlog=1000时，模拟断电重启后，有0.7%的概率出现binlog和redo日志页头Lsn不一致——这不是理论风险，是我用hexdump逐块对比过的物理扇区。别人写文章总说“建议开启semi-sync”，可没人告诉你semi-sync超时参数timeout默认是10秒，而我们实测中一旦网络抖动超过830ms（浙江电信骨干网夏季峰值毛刺均值），这个超时就会让master强制降级为async，整个链路自动容灾就变成手动翻牌。

　　我觉得它优点在新技术。

　　不过上周刚遇到新问题：客户硬要上TIDB做MySQL兼容层，把原有MGR集群当后端存储池挂接——现在每天凌晨ETL跑完，TiKV Region分裂日志里固定出现7条"raft log gap"警告，查了三天才定位是MGR的group_replication_member_expel_timeout值（默认0）和TiDB PD调度器的心跳周期存在128ms对齐冲突。这事我暂时没法解，得等TiDB团队下个月补丁包。

（编辑：站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!