MySQL从库 crash-safe 问题（单线程回放）

一、从库 crash safe 解决历程

MySQL 数据库的成功离不开其复制功能，相对于 Oracle DG 和 Microsoft SQL Server Log Shipping 来说，其简单易上手，基本上 1，2 分钟内根据手册就能完成环境的搭建。然而，随着使用的深入，复制功能自身的问题会慢慢显露，其中非 crash safe 的特性使得许多 DBA 感到头疼，甚至不能理解其所发问题的原因。简单来说，crash safe 是指当 master/slave 任何一个节点发生宕机等意外情况下，服务器重启后 master/slave 的数据依然能够保证一致性。下面主要介绍 slave crash safe 是如何保证的。

slave crash safe 的情况就有些复杂，而这可能是 DBA 更为常见的问题。例如 slave 不断的报 1062 错误，或者发现主从数据不一致（特别是表没有主键的情况）。而这时 DBA 的选择通常也很无奈，基本就是全库重建了。所以说，当你有运维超过 200 台以上的 MySQL 服务器的经验时，就会发现这是一个很大的问题。

导致不能实现 slave crash safe 有两方面的原因，即复制中的 sql thread 和 io thread。

在一个从节点上，同步涉及到 2 个线程：把主节点的二进制日志（binary log）复制到本地并写入中继日志（relay log）的 IO 线程，和执行中继日志中的语句/事件的 SQL 线程。每个线程执行的当前的位置都存储在文件中：IO 线程拉取 master binlog position 信息存在 master.info 文件，SQL 线程执行 relay log position 信息存在 relay-log.info 文件。当从节点重启后可以根据 master.info 文件中记录的 position 信息继续同步主库 binlog，而 sql 线程则继续根据 relay-log.info 文件中记录的 position 信息继续执行 relay log。看上去一切很美好。

Note

master.info 是在 io_thread 向 master 发送 request_dump 时被使用，然后写 relay log 后文件被更新，因此 master.info 记录代表了 io_thread 读取的 master binlog 信息的位置。

relay-log.info 是在 sql_thread 读取未执行的 event 时使用并更新，所以 relay-log.info 代表的是当前 sql_thread 执行到 relay log 的位置。

目前为止，还不错。现在第一个问题来了，这些文件不是每次写入都同步到磁盘：如果发生崩溃，写入到文件中的位置很可能都是不准确的。MySQL 5.5 对这个进行了修复，提供了 sync_master_info & sync_relay_log_info 两个参数，你可以设置 sync_master_info=1 来确保 io thread 每读取主库一个 event 后就进行同步 master.info 信息到磁盘；同时可以设置 sync_relay_log_info=1 来确保 sql thread 每执行一个 transaction 后进行同步 relay-log.info 信息到磁盘，这两个参数默认值都是 10000，因为磁盘实时同步对性能损耗非常大。

但是，等等，尽管设置了 sync_master_info=1 和 sync_relay_log_info=1，还是可能会出现问题。io thread 拉取 master binlog 和写 master.info 是两个步骤，并不是原子的；sql thread 更新数据库操作和 relay-log.info 文件也是两个步骤，也并不是原子的。所以，如果出现数据库宕机就可能会出现 master.info 和 relay-log.info 信息不准确，从而导致数据不一致，甚至复制报错。

master_info_repository 和 relay_log_info_repository

从 MySQL 5.6 开始提供了 slave crash safe 的功能，意思是说在 slave crash 后，把 slave 重新拉起来可以继续从 master 进行复制，不会出现复制错误，也不会出现数据不一致。MySQL 5.6 采用了一种方法，就是将复制信息保存在 InnoDB 的事务表中，而不是之前的日志文件中，来解决这个问题。

新增加了两个参数：

• 参数 master_info_repository 可设置 slave io thread 拉取 master binlog 信息是存储在 master.info 文件还是 slave_master_info 表；设置为 FILE 表示记录为文件，设置为 TABLE 表示记录为数据库表。
• 参数 relay_log_info_repository 可设置 slave sql thread 执行 relay log 的信息是存储在 relay-log.info 文件还是存储在 slave_relay_log_info 表；设置为 FILE 表示记录为文件，设置为 TABLE 表示记录为数据库表。

当 relay_log_info_repository=TABLE 时，会创建 mysql.slave_relay_log_info 表，当 master_info_repository=TABLE 时，会创建 mysql.slave_master_info 表。这时两个操作都是数据库操作，在一个事务中就能得到原子性。想法很简单，我们可以把复制信息的更新包含在事务当中，确保它和数据同步/一致。

然而，这并没有看起来那么简单。对于 sql thread 而言，可以把对 relay log 回放的操作与复制信息的更新（update slave_relay_log_info）放在同一个事务中，使得 sql thread 的位置与数据保持一致。事实上在 5.6.0-5.6.5 的版本，slave_relay_log_info 表默认使用的是 MyISAM 引擎，之后的版本才改为 InnoDB，不过再考虑到 MySQL 5.6.10 才 GA，这个坑踩过的人应该不多。

但对于 IO 线程而言，接收 event 写 relay log 与更新 slave_master_info 表是两个维度的操作，一个是系统层面，一个是数据库层面，没办法是一个原子的操作，所以还是存在 slave_master_info 表记录跟 relay log 不一致的情况，后面再说怎么解决这个问题的。先看 slave_relay_log_info 表，存储 slave sql thread 的工作位置。

在从库启动的时候时，读取 slave_relay_log_info 表信息到内存中，并把值传给 show slave status 命令中输出的 Relay_Log_File、Relay_Log_Pos 字段，当 start slave 是从这个位置开始继续回放 relay log。

slave_relay_log_info 表存储的是持久化的状态、show slave status 命令输出的是内存中的状态：

• 两者输出的位置可能不一样
• stop slave 或者正常关闭 mysqld，都会将内存中的状态持久化到磁盘上（slave_relay_log_info 表中）
• 启动 mysqld 时会读取磁盘状态，初始化给内存状态
• start slave 时生效的是内存状态

但是同一个事务在从库 relay log 中的 position 和主库 binlog 中的 position 是不相等的，slave_relay_log_info 表通过 Master_log_name、Master_log_pos 这两个字段记录了 relay log 中事务对应在主库 binlog 中的 position。通过 show slave status 查看复制信息时 Relay_Master_Log_File、Exec_Master_Log_Pos 字段就是读取的 Master_log_name、Master_log_pos 记录的信息，我们才知道当前从库回放到主库的对应位置是什么，这很重要。

我们知道如果 slave io thread 重复、遗漏的读取主库 binlog 写入到 relay log 中，sql thread 也会重复、遗漏地回放这些 relay log。也就是说从库的数据是否正确，io thread 的位置是否正确也非常重要。

回到 io thread，上面说了对于 IO 线程而言，读取 master binlog event 写 relay log 与更新 slave_master_info 表是两个维度的操作，一个是系统层面，一个是数据库层面，没办法是一个原子的操作，所以还是存在 slave_master_info 表记录跟 relay log 不一致的情况。我们最多可以做的就是调整 sync_master_info & sync_relay_log 参数，默认值都是 10000，可以都调整为 1，表示 IO 线程会每接收 1 个事件就会更新一次 slave_master_info 表和 relay log 日志。

如果设置 master_info_repository=TABLE & sync_master_info=1 & sync_relay_log=1 会导致写放大很严重，性能损耗大。但就算能够容忍损耗点性能，但由于读取 master binlog event 写 relay log 与更新 slave_master_info 表不是原子的，所以还是会有不一致的问题。为此，MySQL 又引入了另一个更加优雅的解决方法，那就是开启 relay_log_recovery 参数，但它要求重启 MySQL 服务。

relay_log_recovery

当启用 relay_log_recovery 参数后，从库启动恢复过程会以 sql thread 的位置创建一个新的 relay log 文件，并初始化 io thread 和 sql thread 的位置，表现为：

• io thread：直接使用 slave_relay_log_info 内存结构中的 Master_log_name 和 Master_log_pos 覆盖 slave_master_info 内存结构中的 Master_log_name 和 Master_log_pos。
• sql_thread：将 slave_relay_log_info 表内存结构中的 Relay_Log_Name 值更新为最新的日志名，Relay_Log_Pos 值更新为一个固定值 4（应该是头部固定信息占 4个偏移量）。

io thread 这个位置的初始化思路就是：既然以前记录的位置不确定是否准确，那就直接不要了，sql thread 回放到哪，我就从哪开始重新拉取主库的 binlog，重新执行，这样一定能保证正确性。

一个事务在 relay log 中的 position 对应到主库 binlog 的 position 是这样来确定的：

• slave_relay_log_info 表中的 Relay_log_name 与 Master_log_name，Relay_Log_Pos 与 Master_Log_Pos 始终一一对应，代表同一个事务的位置。

所以，即使 sync_master_info 表的持久化无法保证，relay_log_recovery 也会将 io_thread 需要的信息重置到已经回放的那个位置。因此，你只需要开启 relay_log_info_repository=TABLE & relay_log_recovery=ON 就能保证 slave crash safe。所以也可以不设置 master_info_repository=TABLE & sync_master_info=1 了。但最好不管是 io thread 还是 sql thread 都设置为 TABLE 是有必要的，对性能有提升作用。

安全&性能都高的配置建议：

但在使用 MTS（multi-threaded slave）时，为保证 slave crash safe，在基于 position 模式的复制时还需要设置 sync_relay_log=1 & log_slave_updates=ON & sync_binlog=1，因为从库在 crash 恢复时必须先通过读取 relay log 补齐 MTS 导致的事务空洞。具体后面会介绍。

另外，relay_log_recovery 的另一个作用是防止 relay log 的损坏，因为默认 relay log 是不保证持久化的（也不推荐设置 sync_relay_log=1），当操作系统或者 mysqld crash 后，sql thread 可能会因为 relay log 的损坏、丢失导致错误。

细说 FILE 和 TABLE

所以到这里我们基本弄清楚了 master_info 和 relay_log_info 的来龙去脉。下面我们细看一下这些信息被存储在 TABLE 中和 FILE 中的区别在哪？实际上这个区别可以认为是文件系统和数据库事务的区别。

master info 会通过 mi->flush_info 方法更新到 FILE 或者 TABLE，relay log info 通过 rli->flush_info 更新 FILE 或 TABLE。

在 FILE 的实现中，实际上每次执行 flush_io_cache 都会写文件，我们读文件可以看到已经被更新了，但是新的写入并不会立马同步到磁盘，在 sync_period（也就是参数 sync_master_info/sync_relay_log_info）次后 MySQL 会通过 fdatasync 写到磁盘。那么这样就存在的问题就在于如果系统宕机，那么还没有持久化到磁盘的信息就会丢失，当然我们可以把 sync_period 设置为 1，那么每次写操作都会进行 sync，但是系统的 sync 操作并不是一个高效的行为，这样势必会牺牲一些性能。

而 TABLE 方式是依赖数据库事务实现的，如果 relay log 表支持事务，上述 relay log 进行 flush_info 操作会在事务 commit 时一同提交，这里就可以保证 relay log info 中存储的点和当前真正执行事务的点是一致的。如果服务宕掉或者系统宕机，如果设置了 relay_log_recover=1 参数，recovery 时就会创建新的 relay log，重新初始化 sql_thread 和 io_thread 从真正执行的点开始执行，从而保证复制的正确。

到这里，我们可以看出 master_info_repository 和 relay_log_info_repository 默认值被设置为TABLE（默认 InnoDB），主要还是从安全的方面考虑，依赖数据库的事务，可以保证 relay_log_info_repository 存储的点和数据库真正执行的点一致，这一点 FILE 方式是无法做到的。同时在性能上，和文件系统的直接交互会增加 io，而写 table 是直接写内存中的 buffer pool，在性能上也能有一定的提升。

注意到上面 sync_period 在 master info 和 relay log info 中分别是代表了 event 和 transaction，这是因为 io_thread 是按照 event 来一个一个读取后 flush_info，而 sql_thread 虽然也是以 event 为单位执行的，但是会等待事务 commit 时才会 flush_info，否则如果事务没有提交已经刷新了 relay log info，然后 recovery 时会把未 commit 的事务 rollback 。此时重新从 relay log info 的 pos 开始执行就会出错。

基于 5.6 GTID auto_position 的复制

在 gtid 模式下，开启 master_auto_position=1 后，从库可以根据 Retrieved_Gtid_Set 发送到主库自动确认 binary log 的拉取位置。此时，意味着从库不在依赖 relay log info 信息了。怎么拿到 Retrieved_Gtid_Set 值呢？

在 MySQL 启动时，如果 relay_log_recovery 参数没有开启，初始化时就需要从 relay log 文件中获取已接收的 gtid set 并更新 Retrieved_Gtid_Set，并且 sql 线程也需要从宕机前的位置继续读取 relay log 继续应用。因此就需要保证 relay log 文件的完整性，设置 sync_relay_log=1，性能会严重下降，不推荐。

开启 relay_log_recovery 是推荐的做法，这种方式避免了上面一种方式的缺点，首先 Retrieved_Gtid_Set 不需要初始化了，只需要 Executed_Gtid_Set 的值就可以了，这个很容易观察到，设置--skip-slave-start后重启 MySQL 实例，观察 show slave status 中的 Retrieved_Gtid_Set 是否有值就可以了。有了 Executed_Gtid_Set 后，主库 dump 线程将把 Executed_Gtid_Set 之后的全部事务发送给从库，这也符合使用执行位置重新拉取 binlog 的理念，这种情况下 relay log 和 slave_master_info 都不重要了。

但对于 Executed_Gtid_Set 的获取，在 MySQL 5.6 和 MySQL >= 5.7 是有不同的表现的。

在基于 5.6 GTID 的复制下，由于 gtid_executed 变量是一个内存值，没有持久化。所以在从库重启后，它自己没办法知道自己执行了哪些 GTID 事务，需要从自身的 binlog 中解析 gtid_executed。从库就需要记录 binlog 信息了，并且 binlog 必须和 InnoDB 存储引擎的数据保持一致。要保持数据一致，就需要把 sync_binlog & innodb_flush_log_at_trx_commit 都设置为 1，即所谓的”双1″。

这样，对于基于 5.6 GTID 的复制，安全&性能最高的配置建议（小于 MySQL 5.7 版本设置）：

关于如何设置以确保 slave crash safe，官方文档有明确记载，见 17.3.2 Handling an Unexpected Halt of a Replication Slave。

基于 5.7 GTID auto_position 的复制

由于 MySQL 5.7 已经将已执行的 gtid set 信息实时记录到系统表 mysql.gtid_executed 中，而 mysql.gtid_executed 表中的记录是和用户事务一起提交的，因此可以保证和实际数据的一致。所以可以关闭 log_slave_updates（也就是不需要记录 binlog 了）参数了。

关于 relay_log_recovery 参数当然也是需要开启的，不然就会有上面同样的问题。

安全&性能较高的配置建议：

如果是异常宕机，且宕机后丢失了 master info 或者 relay log info 信息，重启时 io_thread 可能会拉取到重复的 relay log，sql_thread 可能会重复执行同一个事务，这样就会导致复制出错。但是开启 GTID 就可以避免这个问题，虽然 io_thread 和 sql_thread 的动作是一样的，但是如果事务的 gtid 是已经存在，ev->apply_event 时就会忽略这个事务。因此不会重复执行同一个事务。

这里思考一个问题：开启 master_auto_position 后，还需要 slave_relay_log_info、slave_master_info 表中记录的位点信息吗？

其实 slave_relay_log_info 和 slave_master_info 表依然发挥作用：

• 当第一次或者 reset slave 后，执行 start slave，io thread 将从库的 Executed_Gtid_Set 发往主库，获取到对应的 File、Position，之后更新到从库的 slave_relay_log_info、slave_master_info 表中。
• 当 slave_relay_log_info、slave_master_info 表中存在位置信息后，此后无论是重启复制还是重启 mysqld，都是直接从这两个地方获取 File、Position，并从这里开始读取 binlog 和回放 relay log。

以上都是对于从库单线程配置下的 crash safe 演进，下一篇说说多线程回放（MTS）下是如何保证 crash safe 的。

<参考>

slave_relay_log_info 表认知的一些展开

与MySQL传统复制相比，GTID有哪些独特的复制姿势?

从源码入手，详解参数master_info_repository和relay_log_info_repository

喜欢 (0)赏

[资助本站您就扫码 谢谢]

分享 (0)