一 前言
MySQL 主从架构已经被广泛应用,保障主从复制关系的稳定性是大家一直关注的焦点。MySQL 5.6 针对主从复制稳定性提供了新特性: slave 支持 crash-safe。该功能可以解决之前版本中系统异常断电可能导致 relay_log.info 位点信息不准确的问题。
本文将从原理,参数,新的问题等几个方面对该特性进行介绍。
二 crash-unsafe
在了解 slave crash-safe 之前,我们先分析 MySQL 5.6 之前的版本出现 slave crash-unsafe 的原因。我们知道在一套主从结构体系中,slave 包含两个线程:即 IO thread 和 SQL thread。两个线程的执行进度(偏移量)都保存在文件中。
IO thread 负责从 master 拉取 binlog 文件并保存到本地的 relay-log 文件中。
SQL thread 负责执行重复 sql,执行 relay-log 记录的日志。
crash-unsafe 情况下 SQL_thread 的 的工作模式:
START TRANSACTION; Statement 1 ... Statement N COMMIT; Update replication info files (master.info, relay_log.info)
IO thread 的执行状态信息保存在 master.info 文件, SQL thread 的执行状态信息保存在 relay-log.info 文件。slave 运行正常的情况下,记录位点没有问题。但是每当系统发生 crash,存储的偏移量可能是不准确的(需要注意的是这些文件被修改后不是同步写入磁盘的)。因为应用 binlog 和更新位点信息到文件并不是原子操作,而是两个独立的步骤。比如 SQL thread 已经应用 relay-log.01 的4个事务
trx1(pos:10) trx2(pos:20) trx3(pos:30) trx4(pos:40)
但是 SQL thread 更新位点 (relay-log.01,30) 到 relay-log.info 文件中,slave 实例重启的时候 sql thread 会重复执行事务 trx4,于是乎,大家就看到比较常见的复制报错 error 1062,error 1032。
MySQL 5.5 通过两个参数来缓解该问题,使用 sync_master_info=1 和sync_replay_log_info=1 来保证 Slave 的两个线程每次写一个事务就分别向两个文件同步一次 IO thread 和