MySQL slave_net_timeout参数解决的一个集群问题案例

【背景】
   对一套数据库集群进行5.5升级到5.6之后,alter.log 报warning异常。
  

数据库业务压力  qps 1 tps 几乎为0  4-10 秒或者更久会有写入操作。
【分析】
  1 主从复制信息 主机地址，端口，复制用户，binlog 文件位置等信息是存储在master.info中的， 5.6 版本在安全性上做了很多改善，不建议在执行change master的时候指定密码。如果在搭建主从时制定密码，5.6 MySQL 会提示上述warning信息。这也是该集群在5.5版本时不报错的原因。
 
  2 MySQL Replication的重连机制

  在一个已经建立主从复制关系的系统里面,正常情况下,由从库向主库发送一个 COM_BINLOG_DUMP 命令后,主库有新的binlog event，会向备库发送binlog。但是由于网络故障或者其他原因导致主库与从库的连接断开或者主库长时间没有向从库发送binlog。例如该例子中数据库集群 10s 左右还没有写入的情况，超过slave_net_timeout设置的4s ，从库会向主库发起重连请求。5.6 版本slave 发起重连请求时，MySQL都会判断有没有用明文的用户名密码,如果有则发出上述信息到error.log。
 
【解决方法】
   在本案例中可以尝试将slave_net_timeout 调整大一些 设置为25 。slave_net_timeout是设置在多少秒没收到主库传来的Binary Logs events之后,从库认为网络超时,Slave IO线程会重新连接主库。该参数的默认值是3600s ，然而时间太久会造成数据库延迟或者主备库直接的链接异常不能及时发现。将 slave_net_timeout 设得很短会造成 Master 没有数据更新时频繁重连。一般线上设置为5s 。

    当然也可以和业务方沟通，对于几乎没有访问量的业务线进行下线 ，为公司节省资源。