relay_log_recovery

• 控制从库挂掉之后如何恢复复制及其relay log
  • 当开启时，从库重启或者崩溃恢复时，将读取SQL线程重放对应的主库binlog的位置，把当前没有重放完的relay log全部清理掉，以这个位置为准重新连接主库并把这个位置之后的binlog从主库上拉过来重新创建relay log。这样就可以忽略sync_master_info参数的设置，而只需要把sync_relay_log_info参数设置为1即可（即只需要保证SQL线程重放每个事务或每个events时实时把SQL线程的信息保存到磁盘即可，IO线程的位置信息是否存盘无需关注，因为重新生成relay log时，IO线程的位置自然就有了）
  • 当关闭时，要保证主从数据的一致性，建议设置sync_master_info=1、sync_relay_log_info=1把IO线程和SQL线程的信息在每个事务（或者events）写入relay log、从relay log中重放时实时落盘，但这样做会导致频繁刷盘消耗磁盘IO能力
  • 全局变量，只读变量(5.6.6开始的5.6.x版本为只读，5.6.6之前的5.6.x版本可以动态修改，在5.7.x版本中为只读变量)，默认值为false，布尔型
  • 注意：
    • 当开启GTID复制时，如果使用了master_auto_positon=1，则其他与崩溃主备数据一致性相关的参数不管如何设置都不会影响到从库的崩溃恢复保障性，当没有开启GTID复制时，需要设置sync_relay_log=1,relay_log_info_repository=TABLE,relay_log_recovery=1(从库使用单线程复制时，可以忽略sync_relay_log参数设置，多线程复制在不使用GTID复制时，必须设置为1，否则OS挂掉之后不保证从库崩溃恢复安全性)
    • 当relay_log_recovery启用并且同时启用了多线程模式，在运行时遇到的错误而停止了从库复制时，如果日志中存在任何间隙，则无法重新执行CHANGE MASTER TO。 从MySQL 5.6.6开始，可以使用START SLAVE UNTIL SQL_AFTER_MTS_GAPS语句来切换回单线程模式，启动复制处理完所有的间隙之后，再执行stop slave；CHANGE MASTER TO..；start slave语句。另外，要注意，SQL_AFTER_MTS_GAPS语句对IO线程没有影响，该语句也不能与IO_THREAD一起使用。
  • 参考链接：https://dev.mysql.com/doc/refman/5.6/en/start-slave.html

START SLAVE UNTIL SQL_AFTER_MTS_GAPS;
SET @@GLOBAL.slave_parallel_workers = 0;  #设置为单线程
START SLAVE SQL_THREAD;
stop slave;
SET @@GLOBAL.slave_parallel_workers = number;  # 设置为多线程
change master to ...
start slave;

---

上一篇：sync_relay_log_info | 下一篇：sync_binlog