标签:slaves str round 重启 sla osi 想法 ... info
MySQL 5.6 对复制功能提供了新特性:slave 支持 crash-safe,可以解决之前版本中系统异常断电可能导致的 SQL thread 信息不准确的问题。
原文:Enabling crash-safe slaves with MySQL 5.6
可以对从库进行配置 crash-safe 功能是 MySQL 5.6 关于复制的一个重大改进。然而,我们注意到对如何正确开启这个特性存在着一些困惑,那么让我们一起来理清它要怎么做。
1.停止从库 MySQL 服务
2.在配置文件 my.cnf 中添加 relay_log_info_repository = TABLE
和 relay_log_recovery = ON
3.重启 MySQL 服务
如果要在从库启用 crash-safe 功能,你需要完全理解为什么要做上面所说的配置。首先,让我们看看当从库崩溃时,同步会断开的原因。
在一个从节点上,同步涉及到 2 个线程:把主节点的二进制日志( binary log )复制到本地中继日志( relay log )的 IO 线程,和执行中继日志中的语句的 SQL 线程。
每个线程当前的位置都存储在一个文件里:IO 线程存在 master.info
文件,SQL 线程存在 relay-log.info
文件。
目前为止,还不错。第一个问题是,这些文件不是每次写入都同步到磁盘:如果发生崩溃,写入到文件中的位置很可能是不准确的。MySQL 5.5 对这个进行了修复:你可以设置 set sync_master_info = 1
和 sync_relay_log_info = 1
来确保写入两个日志文件,且在每个事物完成之后同步到磁盘。同步到磁盘是有消耗的,但如果服务器有回写缓存(write-back cache)策略,这些设置还是会起到积极作用,可以接受。
但是,等等,尽管设置了 set sync_master_info = 1
和 sync_relay_log_info = 1
,还是可能会出现问题。这是因为复制信息是在事务提交后才写到日志文件的。因此,如果在事务提交之后,复制信息更新之前,发生了崩溃,当服务重启的时候,复制信息是错的,并且一个事务会被执行两次。这个影响取决于这些事务:复制可能还可以正常运行,或者断开,或者导致数据不一致。
MySQL 5.6 通过让我们把复制信息存储在表中,而不是之前的日志文件,来解决这个问题(当 relay_log_info_repository = TABLE
时,会创建表 mysql.slave_relay_log_info,当 master_info_repository = TABLE
时,会创建表 mysql.slave_master_info)。想法很简单:我们可以把复制信息的更新包含在事务当中,确保它和数据同步/一致。
伪代码,写入到日志文件:
START TRANSACTION;
-- Statement 1
-- ...
-- Statement N
COMMIT;
-- Update replication info files
写入到表:
START TRANSACTION;
-- Statement 1
-- ...
-- Statement N
-- Update replication info
COMMIT;
然而,这并没有看起来那么简单。对于 SQL 线程而言,因为实例会在一个事务提交的同时更新表 slave_relay_log_info,所以它可以很好的工作。但对于 IO 线程而言,表的更新与事务的执行并没有关系,那么实例是如何知道什么时候去更新这个表呢?
答案是:它由 sync_master_info
控制。默认值是 10000,表示 IO 线程的位置,只会每提交 10000 个事务更新一次。这明显不利于从节点开启 crash-safe 功能。一个办法是,设置 sync_master_info = 1
,但正如前面所说,它可能会影响性能(这就是为什么默认值不是 1)。
还有一个更加优雅的解决方法,那就是设置 relay_log_recovery = ON
,但它要求重启 MySQL 服务。这个设置确保当 MySQL 服务启动时,会从表 slave_relay_log_info
恢复出最新的 IO 线程的位置。因此,你甚至不需要为了从节点要开启 crash-safe 功能而去把 IO 线程信息存储到表里面。换句话说,没有必要再去设置 master_info_repository = TABLE
。
最后再说一下,一旦设置了 relay_log_info_repository = TABLE
,因为这个表会在每个事物提交之后更新,所以 sync_relay_log_info
的设置是什么就无关紧要了。因此,你可以安全地把它从配置文件中删除。
MySQL crash-safe replication(1)
标签:slaves str round 重启 sla osi 想法 ... info
原文地址:https://www.cnblogs.com/DataArt/p/10068182.html