WeChat ID A_CMUG Intro 中国MySQL用户组（ACMUG）官方公众号。 ACMUG是覆盖中国MySQL爱好者的一个技术社群，是Oracle User Group Community和MariaDB基金会共同承认的MySQL官方社区。 我们的口号：开源、开放、开心。 ACMUG征集原创技术文章。详情请添加 A_CMUG或者扫描文末二维码关注我们的微信公众号。有奖征稿，请发送稿件至：acmug@acmug.com。3306现金有奖征稿说明：知识无价，劳动有偿，ACMUG特约撰稿人有奖回报计划（修订版） 作者简介：张远 MySQL开发工程师。目前就职于阿里云RDS数据库团队，从事MySQL内核开发和运维工作。 crash safe 定义 在主备环境下，实例mysqld crash或机器宕机是常见的事情，而如何快速而安全的从异常中恢复，对高可用来说是非常重要的。常见的恢复方法是从备份集来恢复实例，重建复制关系，这种做法是安全的但一般耗时较长。另外一种方法就是等异常实例恢复，直接启动异常实例来恢复复制关系，这种做法快速但不一定是安全的，下节会详细介绍原因。 crash safe就是指在异常实例恢复后，直接启动异常实例来恢复复制关系，并且保证数据是一致的。 MyRocks 是crash safe的。 不一致原因 分为主库异常恢复和备库异常恢复两种情况，这两种情况都可能出现不一致的情况。 主库异常 在MyRocks主备环境是开启了loss-less semisync(AFTER-SYNC模式)，并且主库sync_binlog=1，innodb_flush_log_at_trx_commit=1(双1模式)。在这种情况下，主库是在sync binlog 之后，engine commit之前等待备库的ACK， 因此主库crash时，主库可能存在部分binlog已经落盘但engine层没有提交，并且这些binlog也没有即时发送到备库的情况。 这部分binlog 实际上就是比备库多出来的binlog，而主库启动恢复这部分binlog所在事务是处于prepare状态的，根据binlog XA协议，这部分事务最终会提交。从而，主库比备库会多一些事物，导致不一致。 备库异常 为了加快复制速度，备库一般会设置sync_binlog!=1，innodb_flush_log_at_trx_commit!=1(非双1模式)。这种设置，备库可能出现两种情况： binlog落后于engine层，也就是存在engine 层提交了但binlog没有落盘的情况。 binlog超前于engine层，也就是存在binlog落盘了但engine层没有提交(非prepare)的情况。 在这两种情况下直接启动备库，重建复制关系都可能导致主备不一致。 engine层的binlog信息 讨论MyRocks如何做到crash safe之前，我们先熟悉下以下背景知识。engine 层提交时会保存binlog位点信息。对于innodb， 每次提交时会在系统事务页（第5页）存储binlog 位点和gtid，参考trx_sys_update_mysql_binlog_offset #define TRX_SYS_MYSQL_LOG_OFFSET_HIGH   4       /*!