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

推荐：使用innodb_force_recovery解决MySQL崩溃无法重启问题
这篇文章主要介绍了使用innodb_force_recovery解决MySQL崩溃无法重启问题,这只一个成功案例,并不是万能的解决方法,需要酌情考虑,需要的朋友可以参考下 一 背景 某一创业的朋友的主机因为磁盘阵列损坏机器crash,重启MySQL服务时 报如下错误: 代码如下: InnoDB: Reading

 　　这篇文章主要介绍了MySQL slave_net_timeout参数解决的一个集群问题案例,问题日志请见正文,本文使用slave_net_timeout参数解决了这个问题,需要的朋友可以参考下

　　【背景】

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

　　复制代码 代码如下:

　　2015-02-03 15:44:51 19633 [Warning] Storing MySQL user name or password information in the master info repository is not secure and is therefore not recommended. Please consider using the USER and PASSWORD connection options for START SLAVE; see the \'START SLAVE Syntax\' in the MySQL Manual for more information.

　　数据库业务压力 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 。

　　复制代码 代码如下:

　　set global slave_net_timeout = 25

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

分享：MySQL replace into 语句浅析（二）
这篇文章主要介绍了MySQL replace into 语句浅析(二),本文着重给出了几个特殊案例分析,需要的朋友可以参考下 一 介绍 上一篇文章介绍了replace into的基本原理。本章内容通过一个例子说明 replace into 带来的潜在的数据质量风险,当涉及replace into操作的表含有自增主