开发者社区> zysql> 正文
阿里云
为了无法计算的价值
打开APP
阿里云APP内打开

myrocks crash safe特性

简介: myrocks crash safe 特性
+关注继续查看

title: MySQL · myrocks · myrocks crash safe 特性

author: 张远

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也没有即时发送到备库的情况。

image

这部分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       /*!< high 4 bytes of the offset                                           within that file */
#define TRX_SYS_MYSQL_LOG_OFFSET_LOW    8       /*!< low 4 bytes of the offset within that file */
#define TRX_SYS_MYSQL_LOG_NAME          12      /*!< MySQL log file name */
#define TRX_SYS_MYSQL_GTID              (TRX_SYS_MYSQL_LOG_NAME + TRX_SYS_MYSQL_LOG_NAME_LEN)

对于rocksdb,每次提交时会在数据字典BINLOG_INFO_INDEX_NUMBER中存储binlog 位点和gtid, 参考Rdb_binlog_manager::update

BINLOG_INFO_INDEX_NUMBER
key: Rdb_key_def::BINLOG_INFO_INDEX_NUMBER (0x4)
value: version, {binlog_name,binlog_pos,binlog_gtid}

master crash safe

myrocks可以做到主库crash safe。前面讲过如果直接启动主库,多出来的那部分binlog可能导致不一致。如果我们能够把这部分binlog去掉,那么启动时,prepare的事务就可以回滚了,从而主备又可以一致了。事实上facebook就是这样做的,主库crash时,备库io线程会终止,同时会在errorlog中记录拉取主库binlog的位点信息。取到这位点后,将主库的binlog从此位点truncate掉。

以下图片来自facebook

主库crash
master crash .png

truncate binlog 后
facebook.png

前面提到engine层也保存了位点信息,那么我们为什么不使用这个位点,而是从备库errorlog中获取呢。
engine层位点前的事务在engine 层都是已提交的。
主库crash时,prepare的事务的binlog有可能部分传到了备库,而这些prepare的事务重启动时是应该提交的。而如果用engine层位点来truncate binlog会导致这部分事务回滚。
因此,从备库获取的位点信息才是准确的。

slave crash safe

myrocks可以做到备库库crash safe,这里需考虑两种情况

  • binlog落后于engine层,也就是存在engine 层提交了但binlog没有落盘的情况。

针对此种情况,Facebook mysql增加了新的系统表专门保存每个db最后提交的gtid信息。之所以保存的是db的gtid信息,是因为并行复制还是库级别并发的,不得不吐槽下。

CREATE TABLE `slave_gtid_info` (
  `Id` int(10) unsigned NOT NULL,
  `Database_name` varchar(64) NOT NULL,
  `Last_gtid` varchar(56)DEFAULT NULL,
  PRIMARY KEY (`Id`)
) DEFAULT CHARSET=utf8 STATS_PERSISTENT=0

此gtid信息,在每个事务提交时都会更新。

备库启动时,这部分未落盘事务会重新拉取部分到备库apply, sql线程apply的过程中会根据系统表中的gtid信息来判断此gtid是否应该跳过,这些需跳过的事务只需要记录binlog不需要真正执行。参考Gtid_info::skip_event .

  • binlog超前于engine层,也就是存在binlog落盘了但engine层没有提交(非prepare)的情况。

实例启动时gtid_executed是从binlog中读取的。对于此种情况,先从engine层读取位点信息,更新gtid_executed信息时只读取binlog的到此位点,然后rotate binlog,用新的gtid_executed信息重新拉取binlog就不会不一致了。参考read_gtids_from_binlog。

slave_gtid_info表优化

每个事务提交时都要更新slave_gtid_info表。最初的时候,这个操作是server层提交时由server层更新slave_gtid_info表,后来将这个操作下沉到engine直接由engine层来执行。从而省去了server层接口调用的开销,这个优化对于rocksdb insert 场景有30%左右的提升。详情参考这里。不过,如果需要混用innodb和rocksdb,建议禁用此优化。

关于gtid_execute表

mysql5.7已经支持gtid_executed表(myrocks是基于mysql5.6的), 结构如下

CREATE TABLE `gtid_executed` (
  `source_uuid` char(36) NOT NULL COMMENT 'uuid of the source where the transaction was originally executed.',
  `interval_start` bigint(20) NOT NULL COMMENT 'First number of interval.',
  `interval_end` bigint(20) NOT NULL COMMENT 'Last number of interval.',
  PRIMARY KEY (`source_uuid`,`interval_start`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 STATS_PERSISTENT=0

此表保存了所有已执行的gtid信息,与slave_gtid_info不同,slave_gtid_info只是保存了每个db最后执行的gtid信息。如果将slave_gtid_info换成gtid_executed表,整个代码逻辑将更加清晰,同时gtid_executed表对以后支持表级或事务级的并行复制来说更加便利。

总结

myrocks的crash safe 特性可以帮助我们快速安全的恢复实例,重新建立复制关系,恢复高可用。crash safe 可以解决大多数主备环境下由于实例crash导致的主备不一致问题。然而,前面提到的主库crash safe是在semisync没有退化为异步的情况下才成立,要想真正的做到高可用,可使用mysql5.7.17刚GA的group replication 特性。当然,myrocks理论上也是支持group relication的,rocksdb只是mysql的一个engine而已。另外,业界已经有比较成熟的基于rocksdb的高可用分布式数据库,例如TiDBcockroachDB

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

相关文章
MySQL 的 crash-safe 原理解析
MySQL作为当下最流行的开源关系型数据库,有一个很关键和基本的能力,就是必须能够保证数据不会丢。那么在这个能力背后,MySQL是如何设计才能保证不管在什么时间奔溃,恢复后都能保证数据不会丢呢?有哪些关键技术支撑了这个能力?本文将为我们一一揭晓。
884 0
MySQL · myrocks · collation 限制
背景 MyRocks中的数据是按索引列以memcmp方式进行排序的。对于一些数字类型,需要进行转化才能直接通过memcmp进行比较, 例如有符号数在计算机中是用补码表示的,那么如果负数和正数直接按字节比较,结果负数会比正数大,实际存储时会将符号会反转存储,读取时再转化回来。
1380 0
MyRocks事务锁分析
# 概述 MyRocks中RocksDB作为基于快照的事务引擎,其在事务支持上有别于InnoDB,有其自身的特点。在早期的月报[[myrocks之事务处理]](http://mysql.taobao.org/monthly/2016/11/02/) 中,我们对锁的实现有过简单的分析,本文会以一些例子来介绍MyRocks是如果来加锁解锁的。 # 锁类型 MyRocks早期只支持排他锁,
13580 0
MySQL · myrocks · 事务锁分析
概述 MyRocks中RocksDB作为基于快照的事务引擎,其在事务支持上有别于InnoDB,有其自身的特点。在早期的月报[myrocks之事务处理] 中,我们对锁的实现有过简单的分析,本文会以一些例子来介绍MyRocks是如果来加锁解锁的。
1772 0
MySQL · myrocks · myrocks写入分析
写入流程 myrocks的写入流程可以简单的分为以下几步来完成 将解析后的记录(kTypeValue/kTypeDeletion)写入到WriteBatch中 将WAL日志写入log文件 将WriteBatch中的内容写到memtable中,事务完成 其中第2,3步在提交时完成 WriteBatch与Myrocks事务处理密切相关,事务中的记录提交前都以字符串的形式存储在W
2232 0
MySQL · myrocks · myrocks之事务处理
前言 mysql目前支持的事务引擎有innodb,tokudb。 rocksdb加入mysql阵营后,mysql支持的事务引擎增长至3个。 myrocks目前支持的事务隔离级别有read-committed和repeatable-read。 同innodb一样,myrocks也支持MVCC机制。 可以说,myrocks提供了很好的事务支持,能够满足的一般业务的事务需求。 sequence n
2294 0
MySQL · 特性分析 · MyRocks简介
RocksDB是facebook基于LevelDB实现的,目前为facebook内部大量业务提供服务。经过facebook大量工作,将RocksDB作为MySQL的一个存储引擎移植到MySQL,称之为MyRocks。 经过两年的发展,MyRocks已经比较成熟(RC阶段),现已进入了facebook MySQL的主分支了。MyRocks是开源的,参见git 。 下面对MyRocks做一个简单介绍,
2450 0
MySQL · myrocks · myrocks统计信息
概述 mysql查询优化主要是在代价统计分析的基础上进行的。合理的代价模型和准确的代价统计信息决定了查询优化的优劣。myrocks基于mysql5.6, 目前的代价模型依赖的主要因素是IO和CPU,mysql5.7及以上的版本代价模型做了较多改进,具体可以参考这里 IO主要跟数据量和缓存相关,而CPU主要跟参与排序比较的记录数相关。 因此mysql5.6的统计信息的指标主要是数据量和记录数。例
1476 0
myrocks之事务处理
--- title: MySQL · myrocks · myrocks之事务处理 author: 张远 --- # 前言 mysql目前支持的事务引擎有innodb,tokudb. rocksdb加入mysql阵营后,mysql支持的事务引擎增长至3个。 myrocks目前支持的事
2935 0
+关注
zysql
张远 MySQL/MyRocks
文章
问答
文章排行榜
最热
最新
相关电子书
更多
俞航翔|基于Log的通用增量Checkpoint
立即下载
PostgresChina2018_赖思超_PostgreSQL10_hash索引的WAL日志修改版final
立即下载
低代码开发师(初级)实战教程
立即下载