[MySQL]主从复制延迟案例一

现象

测试环境一套主从环境，开始了多线程复制，具体配置如下：

master_info_repository=TABLE
relay_log_info_repository=TABLE
slave_parallet_type=LOGICAL_CLOCK
slave_parallel_workers=4
slave_preserve_commit_order=on

在用tpcc工具进行测试时，特别是通过如下命令进行数据装载时，主库很快就完成数据装载，但从库会卡住，具体表现为：

• Slave_io_state长期处于Queueing master event to the relay log状态
• slave_sql_running_state长期处于Reading event from the relay log状态
• Iotop -oP命令观察磁盘写入情况，只有mysqld进程有写IO产生，2mb/s左右
• relaylog文件大小持续在增长，但增长特别缓慢

原因

后来发现当前库的这三个参数配置如下：

sync-master-info=1
sync-relay-log=1
sync-relay-log-info=1

官网解释如下:

sync-master-info

此处的master-info包括主库的binlog文件名，binlog中事件的位点等信息。此参数可在线修改，默认值10000

• master_info_repository = FILE 时，此参数等于0则从库不负责master-info的刷盘，由OS完成从内存缓冲区到文件的落盘；此参数大于0则从库在处理每sync-master-info个binlog event后进行刷盘，等于1则表示每个event都进行刷盘
• master_info_repository = TABLE 时，此参数等于0则从库不负责mysql.slave_master_info的数据更新；此参数大于0则从库在处理每sync-master-info个binlog event后进行mysql.slave_master_info的数据更新

可知，此参数大于0时且不设置为1时，会造成master-info的文件或表中的数据更新不及时，和show slave status\G中的数据会有不一致的情况。

sync-relay-log

控制relay-log的落盘策略，默认值10000

• 参数=0，由OS决定relaylog数据从内存到磁盘文件的落盘
• 参数>0，从库在处理每个binlog event后都将relaylog同步至磁盘。可见：sync-relay-log=1是最安全的，crash时relaylog最多丢1个event，但也是性能最慢的，会消耗更多的IO。

个人觉得没必要设1，配合半同步复制策略，从库可以做到不丢事务。

sync-relay-log-info

控制relay-log-info的落盘或者落表策略，默认值10000

• Sync-relay-log-info=0

  • relay_log_info_repository=FILE，由OS决定何时刷盘
  • relay_log_info_repository=TABLE，mysql.slave_relay_log_info为事务引擎比如innodb时，则每个事务之后再更新表数据；非事务引擎时，mysql.slave_relay_log_info从不会更新

• Sync-relay-log-info>0

  • relay_log_info_repository=FILE，N个事务之后刷盘
  • relay_log_info_repository=TABLE，mysql.slave_relay_log_info为事务引擎比如innodb时，每个事务之后都更新表；非事务引擎时，N个事务后更新表

解决

从上述解释来看，sync_relay_log和sync_relay_log_info都没必要显示设定。

尝试保留sync_master_info=1，tpcc装载数据过程中发现延迟依旧比较严重，但relaylog日志文件的增长提升很多。在线调整sync_master_info为默认值10000后主从复制延迟几乎不存在。

个人觉得可以保留这三个参数为默认值10000。