内行透底:GTID复制,让MySQL容灾不再靠运气
|
文章配图,仅供参考 去年十二月某个周三的凌晨,我在机房蹲到三点半,跟运维组的小周一起刷新MySQL主从状态页——那时候刚处理完一场差点让核心交易库崩掉的主从切换事故。之前跟几个同行吐槽时,有人还在说GTID复制是“玄学”,得靠运气踩坑才能调对,我当场就把手机壳拍得震了震。我原以为GTID只是官方吹的“自动定位事务”花架子,结果那天的场景给我上了实打实的一课。那天凌晨两点刚过,从库突然卡了,同步延迟跳成了十八秒——换成老的基于文件位置的复制,我们之前遇过的坑能列半页:比如主库删表时binlog位置跳乱,从库会直接锁死;主库挂了切到从库,得手动找“最后一个一致的binlog事件”,有时候找错一行,整个主从链直接断链;还有一次跨机房同步,网络波动导致binlog序号错了位,找了两小时才揪出是offset差了三个事件,那时候凌晨三点的机房连外卖热水都凉透了。 那天用GTID的从库延迟跳出来后,我点了一下“START SLAVE SQL_THREAD”,没两分钟就追上了主库。小周凑过来盯屏幕,问“真的不用输binlog文件名和位置?”我指了指状态页上的“Executed_Gtid_Set”,说你看,主库执行过的事务集合是固定的,从库只要把主库没执行的事务拉过来就行,根本不用管之前的顺序——这就是优劣势里的“优胜劣汰”,你之前踩的那些手工找位置的坑,GTID直接帮你把“找一致性”的工作给淘汰了,不用靠运维人员的经验碰运气。 不过得说句实在的,那天也不是没出岔子——我差点忘了把主从库的server_uuid和auto_increment_offset对应改,主库设了奇数步长,从库没改,结果同步时出现了重复键冲突,吓得我赶紧切回GTID的自动分配,才把问题压下去。还有个细节,那天主库重启时,我特意查了二进制日志的GTID模式,原来老的基于位置的复制是“文件+偏移”的硬绑定,GTID是“事务ID集合”的软关联,哪怕主库删了旧binlog,从库只要有完整的事务流,就能自动续上,不用再管binlog的存储周期,这对跨机房同步简直是救命的功能。 之前跟另一个同行吵架时,他说GTID会有事务重复执行的问题,我当场翻出那天的慢查询日志给他看——那次从库延迟十八秒,慢查询日志里只有三条普通查询,没有任何重复执行的事务,因为GTID的事务是唯一的,从库不会重复拉取已经执行过的事务。他后来没再反驳,但我知道他之前踩过的坑,肯定是没开GTID的“增强一致性检查”,或者是主库有非事务表导致的,不能把其他问题全算在GTID头上。 还有个我自己记不清的小细节,那天凌晨三点四十分,小周说之前有次没开GTID的主从切换,切完后订单数据少了三百七十二条,查了半天才发现是主库最后一个binlog的最后一个事件没同步完,那次要是用GTID,只要看Executed_Gtid_Set的交集,根本不会出现这种情况。那时候我突然反应过来,之前的容灾全是“靠运气”——运气好没出现主库最后一个事务没同步完,运气好没出现binlog被删了,运气好运维人员没找错binlog位置,而GTID是把这些“运气”的部分,全换成了可测量、可自动化的规则。 上个月帮一个朋友排查他们的主从复制问题,他用的还是老的基于位置的复制,主库换了磁盘后,binlog序号全乱了,从库同步时直接停在“找不到对应binlog”的状态,他说折腾了整整一天,才找到之前备份的binlog位置。我让他改成GTID,把所有主从库的server_uuid设成唯一的,auto_increment_offset设成对应步长,重启后同步直接跑了起来,延迟没超过两秒。他后来跟我说,早知道这样当初就不用遭那罪,我回了句,这就是优胜劣汰的好处,该淘汰的手工操作,就让GTID替你扛着,不用再靠人盯。 不过有个小矛盾必须说清楚,我之前以为GTID能解决所有复制问题,后来发现要是主库有跨库的事务,或者是非事务表的DML,GTID也会出问题——比如主库删了一张非事务表,从库没删,同步时就会因为表不存在而报错,这时候得手动处理,不能完全依赖自动同步。所以GTID不是万能的,但它能把你之前遇到的大部分“碰运气”的坑,都变成可处理、可自动化的异常,这就够了。 后来我跟团队说,新上线的系统全用GTID,老系统也逐步切,不用再留着老复制方式,不是不信任老方式,是老方式的容错成本太高,每次出问题都得半夜蹲机房找binlog,现在有了GTID,哪怕主库挂了,从库只要执行一下“START SLAVE”,就能自动跟上,不用再手动找位置,这对容灾来说,就是从“看运气”变成“可把控”。 上周跟小周一起复盘那次凌晨的事故,他说那天刷新状态页时,第一次觉得MySQL复制不是“玄学”,是有规则可循的——之前总觉得数据库是黑盒子,现在能通过GTID的集合来判断主从是否一致,这才是靠谱的容灾。我没说话,又翻了翻那天的状态页截图,Executed_Gtid_Set的交集那一行,至今还在我的手机相册里,算是给那次熬夜的交代,也算是给GTID的一个注脚:它不是让复制变简单,是让复制不再靠运气。 (编辑:站长网) 【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容! |


13年老炮揭秘:Linux下H5开发,MySQL配置坑到哭
GTID复制卡顿?5年实战教你秒切主从避坑
MySQL事务控制无障碍设计指南
MySQL事务实战:iOS后端性能保障指南
