官网: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到主库上。