MTU值的调整导致MySQL复制异常
今天的故事简单有趣,你绝对没有遇到过。当我们把网卡的MTU值从默认的1500,调整为3000/6000/9000后,复制十分诡异,搞得我云里来雾里去的,先记录下:
以下命令可以动态修改MTU值及时生效,和查看状态的一些命令:
shell> ifconfig eth1 mtu 3000 up (永久生效可以增加MTU=XXXX到配置文件ifcfg-ethN中)
shell> ip link list eth1
shell> ethtool
shell> ping -s xxxx IP (当增大MTU后,-s值大于1500的ping都会失败)
增大MTU后,复制正常,但scp发生stalled.
增大MTU后,复制异常,scp发生stalled.
异常表现为:
1. 从库只复制过去了一条建库与语句;
2. show processlist和show slave status查看主从状态均正常,但是,当停止主库,show slave status时从库没有异常反应,只有当stop slave,再start slave,从库io_thread_running变为No;
3. 主库show processlist时观察到有Writing to net状态出现,然后该线程被关闭,从库各状态无任何异常。
4. 其中一次在6000复制失败后,将MTU值恢复为1500,突然发现从库有语句被复制过来并执行。
—-
MTU (Maximum Transfer Unit) — 最大传输单元,之所以调整,是考虑到当有大数据量传输时,减少数据包的分段操作,以提高传输速度。后来发现,不能单方面调整,还需要考虑整个网络环境中各个interface的MTU,都需要保持一致才行,否则丢包是难免的。


何必呢,调整MTU之前就要知道MTU工作原理。
你说的没错。
如果对自己将要用的东西,不是十分了解,就凭着自己看上去合理的分析认为这样可行,于是就去作出改变,那么必然遇到的就是:何苦呢,就像这里调整的MTU。其实,这是一个我们普遍都存在的问题,一个新的东西,或是从别人那里听到,在或是自己翻了几篇BLOG,就以为自己了解了,认为就是这样哦,然后就去做了,当最后的结果,如果没有出现任何问题,那么就认为,原来真是这样哦;但当最后的结果,如同上面blog一样,那么这时我们才会重新认真仔细的思考这其中的原因,试图真的把它弄明白,可惜这篇blog中的问题对我依然还是一个问题。