sync_master_info的一些说明

官网:https://dev.mysql.com/doc/refman/5.7/en/replication-options-slave.html

默认我们MySQL5.6线上环境都是

master_info_repository = TABLE  relay_log_info_repository = TABLE

官方文档上对 sync_master_info 描述如下:

The effects of this variable on a replication slave depend on whether the slaves master_info_repository is set to FILE or TABLE, as explained in the following paragraphs.

默认为10000。设置为1表示每个EVENT都要执行刷盘操作(注意不是每个事务!),为0表示有操作系统来决定何时刷盘。 对于 master_info_repository = TABLE 情况下,If the value of sync_master_info is greater than 0, the slave updates its master info repository table after every sync_master_info events. If it is 0, the table is never updated.

我们可以做个小实验 搭建一套传统复制的主从环境。

在从库执行

set global sync_master_info=1;

然后,在主库插入一条记录。再到从库去查看 select * from mysql.slave_master_info G 结果中的Master_log_pos字段值。并执行show slave status G 查看Exec_Master_Log_Pos值。 可以重复操作几次数据插入,可以发现和mysql.slave_master_info里面是一致的。

然后,在从库设置

set global sync_master_info=10000;

然后,在主库插入一条记录。再到从库去查看 select from mysql.slave_master_info G 结果中的Master_log_pos字段值。并执行show slave status G 查看Exec_Master_Log_Pos值。 可以重复操作几次数据插入,可以发现show slave status G 和mysql.slave_master_info里面对不上了。 show slave status G 展示的是基本实时的exec_master_log_pos数据。但是 select from mysql.slave_master_info G 里面却迟迟不更新。 这就是sync_master_info参数的功效。

说明:

如果set global sync_master_info=1的话,理论上复制会更安全,但是这样的话执行每个event都要去update一次 mysql.slave_master_info,就增大了磁盘IO,因此我们一般在从库也启用binlog,这样即便复制出问题了,根据从库记录下的最后的binlog信息可以重新change master到主库上。