MySQL5.6新特性之crash-safe

最新推荐文章于 2024-08-08 10:21:36 发布

crpp0902

最新推荐文章于 2024-08-08 10:21:36 发布

阅读量424

点赞数

分类专栏： mysql 文章标签： mysql

mysql 专栏收录该内容

15 篇文章 0 订阅

订阅专栏

MySQL5.6新特性之crash-safe

一介绍
MySQL 5.6 针对复制功能提供了新特性: slave支持crash-safe. 该功能可以解决之前版本中系统异常断电可能导致的SQL thread 信息不准确的问题。本文从原理方面对该特性进行介绍。
二原理
在了解crash-safe slave 之前，我们先分析一下MySQL 5.6 之前的版本出现 crash-unsafe 的原因。在slave上,复制包含两个线程:即replication中的IO thread和SQL thread。
IO thread负责从master拷贝binlog文件并保存到本地,拷贝过来的binlog称为relay-log.
SQL thread负责执行relay-log.
两个线程的执行进度(偏移量)都保存在文件中.IO thread的执行状态信息保存在master.info文件,SQL thread的执行状态信息保存在relay-log.info文件。系统运行正常的情况下，这种模式到目前为止还没有问题。需要注意的是这些文件被修改后不是同步写入磁盘的,每当系统发生crash,存储的偏移量可能都不准确.MySQL 5.5通过两个参数修复了该问题,使用sync_master_info=1和sync_replay_log_info=1 来保证Slave 的两个线程每次写一个事务就分别向两个文件同步一次 IO thread和SQL thread当前执行的信息。当然同步操作不是免费的,频繁更新磁盘文件需要消耗性能,如果你的RAID设备的IO策略设置为WRITEBACK 模式,那么这种方法便可以接受的。
但是,即使设置了sync_master_info=1和sync_relay_info=1, 问题还是会出现，因为复制信息是在transactions提交后写入的,如果crash发生在事务提交和OS写文件之间，那么relay-log.info就可能是错误的。当slave从新启动的时候,最后那个事务可能会被执行两次.具体的影响取决于事务的具体操作.复制可能会继续运行比如update/delete,或者报错比如insert操作，此时主从数据的一致性可能会被破坏。
MySQL 5.6版本通过将复制信息存放到表中来解决此问题.通过配置两个参数 relay_log_info_repository=TABLE，master_info_repository=TABLE，relay log info 会存放到 mysql.slave_relay_log_info表中，master info 会存放mysql.slave_master_info表中。就是把SQL线程执行事务和更新mysql.slave_replay_log_info的语句看成一个事务处理,这样就会一直同步的.
我们可以通过伪代码来了解crash-safe 的原理
crash-unsafe情况下 SQL_thread 的的工作模式

 
    START TRANSACTION;
 
  Statement 1
 
   ...
 
  Statement N
 
  COMMIT;
 
 Update replication info files

crash-safe情况下 SQL_thread 的的工作模式

 
    START TRANSACTION;
 
   Statement 1
 
   ...
 
   Statement N
 
   Update replication info
 
 COMMIT

crash-safe就是将relay-info.log的信息保存在InnoDB的事务表中，这时执行relay log中的事务和写relay info在一个事务中，就能得到原子性保证。从而避免已执行的binlog位点和写入relay log info 的位点信息不一致的情况发生。看到这里也请各位读者思考一下，现在的这种方案是否完美，有哪些问题？
从上面的改变解决了SQL thread记录执行状态可能导致不一致的风险，但是对于IO thread 依然存在问题。IO thread 从master上拷贝binlog写入 relay log中,每个二进制日志由多个log event组成，所以每接收到一个log event就需要更新master-info.log而且该是写入操作系统缓存。从IO thread的工作原理来看，它没有办法将写入master info和拉取binlog放到同一个事务中而保持原子操作，因此IO thread 的行为是会对数据一致性会产生影响，设想一个log event传送到了relay log中两次的情形。如何解决呢？
方案一通过参数sync_master_info可以控制fdatasync的时间。默认值是10000,表示IO线程的偏移量每10000个事务更新一次，通过设置其为1，每写一次事务便同步到master.info 。
方案二通过MySQL 5.5版本开始提供的参数relay_log_recovery ，当slave发生crash后重启之后重连master时，slave不根据master-info.log的信息进行重连，而是根据relay-info中执行到master的位置信息重新开始拉master上的日志数据。

三如何使用
1 停止slave的mysql实例
2 my.cnf文件中添加
master-info-repository=TABLE
relay-log-info-repository=TABLE
relay-log-recovery
3 重启slave的mysql实例
注意:
如果是MySQL 5.6.5 或者更早期。slave_master_info 和 slave_relay_log_info 表默认使用MyISAM 引擎。所以还得修改成innodb，如下：

ALTER TABLE mysql.slave_master_info ENGINE=InnoDB;
ALTER TABLE mysql.slave_relay_log_info ENGINE=InnoDB

四 relay-log-recovery参数设置后可能的问题：

有时候，我们希望将 MySQL 的 relay log 多保留一段时间，比如用于高可用切换后的数据补齐，于是就会设置 relay_log_purge=0，禁止 SQL 线程在执行完一个 relay log 后自动将其删除。但是在官方文档关于这个设置有这么一句话：

Disabling purging of relay logs when using the --relay-log-recovery option risks data consistency and is therefore not crash-safe.

究竟是什么样的风险呢？查找了一番后，基本上明白了原因。

首先，为了让从库是 crash safe 的，必须设置 relay_log_recovery=1，这个选项的作用是，在 MySQL 崩溃或人工重启后，由于 IO 线程无法保证记录的从主库读取的 binlog 位置的正确性，因此，就不管 master_info 中记录的位置，而是根据 relay_log_info 中记录的已执行的 binlog 位置从主库下载，并让 SQL 线程也从这个位置开始执行。MySQL 启动时，相当于执行了 flush logs ，会新开一个 relay log 文件，新的 relay log 会记录在新的文件中。如果默认情况 relay_log_purge=1 时，SQL 线程就会自动将之前的 relay log 全部删除。而当 relay_log_purge=0 时，旧的 relay log 则会被保留。虽然这并不会影响从库复制本身，但还是会有地雷：

由于崩溃或停止 MySQL 时，SQL 线程可能没有执行完全部的 relay log，最后一个 relay log 中的一部分数据会被重新下载到新的文件中。也就是说，这部分数据重复了两次。
如果 SQL 跟得很紧，则可能在 IO 线程写入 relay log ，但还没有将同步到磁盘时，就已经读取执行了。这时，就会造成新的文件和旧的文件中少了一段数据。

如果我们读取 relay log 来获取数据，必须注意这一点，否则就会造成数据不一致。而保留 relay log 的目的也在于此。因此，在处理 relay log 时必须格外小心，通过其中 binlog 头信息来确保正确性。