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