MySQL slave_net_timeout参数解决的一个集群问题案例
【背景】
对一套数据库集群进行5.5升级到5.6之后,alter.log报warning异常。
2015-02-0315:44:5119633[Warning]StoringMySQLusernameorpasswordinformationinthemasterinforepositoryisnotsecureandisthereforenotrecommended.PleaseconsiderusingtheUSERandPASSWORDconnectionoptionsforSTARTSLAVE;seethe\'STARTSLAVESyntax\'intheMySQLManualformoreinformation.
数据库业务压力 qps1tps几乎为0 4-10秒或者更久会有写入操作。
【分析】
1主从复制信息主机地址，端口，复制用户，binlog文件位置等信息是存储在master.info中的，5.6版本在安全性上做了很多改善，不建议在执行changemaster的时候指定密码。如果在搭建主从时制定密码，5.6MySQL会提示上述warning信息。这也是该集群在5.5版本时不报错的原因。
2MySQLReplication的重连机制
在一个已经建立主从复制关系的系统里面,正常情况下,由从库向主库发送一个COM_BINLOG_DUMP命令后,主库有新的binlogevent，会向备库发送binlog。但是由于网络故障或者其他原因导致主库与从库的连接断开或者主库长时间没有向从库发送binlog。例如该例子中数据库集群10s左右还没有写入的情况，超过slave_net_timeout设置的4s，从库会向主库发起重连请求。5.6版本slave发起重连请求时，MySQL都会判断有没有用明文的用户名密码,如果有则发出上述信息到error.log。
【解决方法】
在本案例中可以尝试将slave_net_timeout调整大一些设置为25。slave_net_timeout是设置在多少秒没收到主库传来的BinaryLogsevents之后,从库认为网络超时,SlaveIO线程会重新连接主库。该参数的默认值是3600s，然而时间太久会造成数据库延迟或者主备库直接的链接异常不能及时发现。将slave_net_timeout设得很短会造成Master没有数据更新时频繁重连。一般线上设置为5s。
setglobalslave_net_timeout=25
当然也可以和业务方沟通，对于几乎没有访问量的业务线进行下线，为公司节省资源。