MySQL slave_net_timeout参数解决的一个集群问题案例
发布网友
发布时间：2022-04-21 05:39
共1个回答
热心网友
时间：2022-04-08 10:01
这篇文章主要介绍了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
当然也可以和业务方沟通，对于几乎没有访问量的业务线进行下线
，为公司节省资源
