13年运维实战：MySQL高可用架构设计

　　13年运维实战：MySQL高可用架构设计——这标题不是包装，是我去年十二月在杭州萧山机房凌晨三点盯着Percona XtraDB Cluster脑裂日志时，用冻僵的手指敲进监控告警系统的备注字段。

　　去年十二月，某电商大促前48小时，我们把运行了7年的MySQL 5.7主从+MHA架构，切到自研的“双写+Binlog回溯仲裁”模式，节点数从3台压到2台物理机（Dell R740，64G内存，NVMe RAID1），延迟从平均87ms降到12ms±3ms——但第七次全量数据校验失败，checksum差值卡在139条记录，查了36小时才发现是TiDB同步服务在UTC+8时区下对TIMESTAMP(6)微秒字段多截了两位。

　　13年运维实战：MySQL高可用架构设计。我认为它优点在新技术。

　　2021年我亲手拆过阿里云RDS HA切换日志，发现其proxy层在vip漂移时有1.8~2.3秒黑洞窗口，而去年十二月我们在绍兴集群上线的Go语言编写的轻量级failover agent，通过监听binlog position+心跳包+OS进程存活三重判定，把故障感知压缩到217毫秒内——可它会在MySQL 8.0.28的clone plugin开启状态下误判备库为“半同步中断”，这个bug直到我们抓到第17次tcpdump包才定位到是clone期间临时关闭了replica threads导致heartbeat socket超时。现在想想，当时要是多测一个clone+semi-sync并发场景就好了？

文章配图，仅供参考

　　失败案例必须说清楚：今年三月，某政务系统上线基于MGR的单主模式，8节点集群，我们认为quorum安全阈值设为5足够稳妥——结果在一次机柜PDU跳闸中，恰好4台机器掉电且网络分区，剩下4台里3台认定自己是primary，1台坚持认为自己被踢出组——最终产生两个独立写入分支，数据覆盖冲突发生在身份证号字段上，恢复花了11小时27分钟，靠比对公民身份信息登记系统的API回写时间戳人工缝合。MGR文档里写的“自动处理网络分区”？呵，它只处理理论模型里的分区。

　　我见过最反直觉的细节：InnoDB redo log写入速度，在戴尔SSD和Intel Optane混合存储池上，当innodb_log_file_size设为2GB时吞吐最高；但一旦启用Linux内核4.19的io_uring支持，最优值立刻变成128MB——因为io_uring batch提交会与redo log group commit机制抢锁，反而拖慢。这个数字没人提，连Percona Toolkit的check-upgrade都不扫这一项。

　　去年十二月，我把MySQL配置文件里wait_timeout从28800改成120，线上连接数没变，但三天后某支付回调接口开始报“Lost connection to MySQL server during query”，查出来是Spring Boot 2.3.12默认用HikariCP，其connection-test-query走的是SELECT 1，而MySQL在wait_timeout触发kill前会把连接状态置为KILLED but not yet closed——此时SELECT 1能成功，但真实业务UPDATE卡在lock wait。改回28800不是妥协，是向现实低头。

　　新技术确实快。但我现在宁可多花两天写测试用例，也不信任何白皮书里写的“无缝切换”。

　　手头还压着三个未复现的case：一个是MySQL 8.0.33在ARM64虚拟机上启用了cgroup v2后，线程调度抖动导致semi-sync ACK超时；另一个是ProxySQL 2.4.4的query rule cache在加载5000条正则规则后，reload期间有0.3%概率丢掉最后一条；第三个……算了，这周先跑通MySQL 8.4的instant add column在线DDL压力测试再说。

（编辑：均轻资讯网）

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