在上一期的月报中,我们分析了 MySQL 5.6 并行复制是如何实现的,介绍了主要数据结构、Coordinator 线程的分发、Worker 线程的执行和checkpoint过程,读者朋友可以[回顾下](http://mysql.taobao.org/monthly/2015/08/09/ "5.6 并行复制实现分析"),本篇将对恢复逻辑进行介绍。 在并行复制之前,SQL线程的恢复很简单,从 relay-log.info 中取得上次执行到的位点,然后从这个位点开始执行即可。有了并行复制之后,情况就变得稍微复杂了些,worker 线程各自执行自己队列的事务,在`stop slave`或者 mysqld crash的时候,队列中的事务很可能没有执行完,比如crash时GAQ的状态如下图1所示,中间存在空隙(gap),先分发给 worker a 的事务还未完成,而后分发给 worker b 的事务已经完成,对应就是 relay log 中间有一部分event没执行。我们知道,SQL执行或者分发是顺序读relay log的,如果恢复时从 2 开始执行,3 和 4就会重复执行,如果从4开始执行,2就会被跳过,都不行。并行复制恢复的逻辑就是把 2 找出来执行,把空隙给填上,然后SQL线程就可以 5 开始愉快地跑下去了。 ![GAQ中的空隙](https://oss.showapi.com/doc/2096/139/907f1893-f054-4618-b294-ba6ba76950ba.png) 图1\. GAQ中的空隙 ## 信息持久化 恢复离不开信息的持久化,每个worker线程对应一个worker.info,定期将执行位点信息刷入worker.info。类似于relay-log.info,worker.info 可以存在表中,也可以存在文件中,取决于配置`relay_log_info_repository`,刷写频率由 `sync_relay_log_info` 控制。 下面是relay-log.info中存的信息: ~~~ Number_of_lines: 后面有多少行(文件)或字段(表) Relay_log_name: 执行到的relay log 的文件名 Relay_log_pos: 执行到的relay log 的位置 Master_log_name: 执行到的对应在主库 binlog 的文件名 Master_log_pos: 执行到的对应在主库 binlog 的位置 Sql_delay: SQL线程必须落后master的时间,通过 CHANGE MASTER TO MASTER_DELAY=X 指定 Number_of_workers: worker线程个数 Id: 内部用的 ~~~ 下面是worker.info中存的信息: ~~~ Id: worker 的 id Relay_log_name: 执行到的relay log 的文件名 Relay_log_pos: 执行到的relay log 的位置 Master_log_name: 执行到的对应在主库 binlog 的文件名 Master_log_pos: 执行到的对应在主库 binlog 的位置 Checkpoint_relay_log_name: 上次 checkpoint 后,分发到的第一个 group 所在的 relay log 文件名 Checkpoint_relay_log_pos: 同上,对应 relay log 中的位置 Checkpoint_master_log_name: 同上,对应在主库 binlog 的文件名 Checkpoint_master_log_pos: 同上,对应在主库 binlog 中的位置 Checkpoint_seqno: 当前执行到事务序列,从上次checkpoint后开始算 Checkpoint_group_size: checkpoint_group_bitmap 的长度,多少个BYTE Checkpoint_group_bitmap: 从上次 checkpoitn 执行事务的标记 ~~~ 每个字段对应Slave_worer类的一个成员(Checkpoint_group_size除外),这其中比较重要的就是 Checkpoint_group_bitmap,记录哪些事务是执行过的,下面会介绍对bitmap的操作。 ## bitmap 记录执行事务 本节介绍对 `Slave_worker::group_executed` 这个bitmap的操作,在此之前需要介绍另一个变量 `Relay_log_info::checkpoint_seqno`,对 Coordinator 线程来说,表示从上次checkpoint调整后,下一个分发的事务编号,同时对应GAQ中事务(Slave_job_group)的个数,我们在上期介绍过,GAQ中存的是Coordinator 线程分发的、尚未被checkpoint出队的事务(可能已经被worker执行完了);对woker线程来说,这个对应当前worker执行到的事务编号。 Coordinator 线程每分发一个事务,checkpoint_seqno 加 1;每次checkpoint后,会将 checkpoint_seqno 减去cnt(cnt为checkpoint时GAQ中出队的事务的个数)。worker 线程每执行完一个事务,会将 group_executed 的 checkpoint_seqno 位置1;如果遇到checkpoint,会将bitmap向左移位。 如下图所示,GAQ中第0、2、5个事务分发给了worker a,第0个已经执行完成,所以 worker a 的 bitmap 中,第0位置1;worker b 和 worker c 的 bitmap 同理,标识已经执行的事务。 ![worker线程的bitmap](https://oss.showapi.com/doc/2096/139/061c7dbf-a4cc-4125-a2fa-020e16694b8e.png) 图2\. worker的bitmap 假设这个时候 Coordinator 线程做了一次 checkpoint,将队列头部2个已经完成的事务出队,然后将`rli->checkpoint_seqno`减2,同时将2累加到每个 `worker->bitmap_shifted` 中,当Coordinator 线程将新的事务分给worker的时候,会将 `worker->bitmap_shifted` 取出,存人当前`Slave_job_group.shifted` 中,当worker执行到这个group,就开始对 group_executed 进行偏移,偏移量就是`Slave_job_group.shitfed` (再一次说明了GAQ中的Slave_job_group,充当了Coordinator 线程和worker线程通信的角色)。bitmap的变化就如下图所示,checkpoint后,原来的0和1出队,然后新的4、5、6加入进来,新分发给worker b 和 worker c 的 4 和 6 已经执行完成,所以bitamp和上图相比,已经向左路偏移了2位,而新分发worker a的5并示执行,所以worker a 的bitmap还未偏移。 ![checkpoint后worker线程的bitmap](https://oss.showapi.com/doc/2096/139/5648d348-ece9-4055-86da-922b2d62a903.png) 图3\. checkpoint后worker的bitmap group_executed bitmap的长度和GAQ大小一样,由配置`slave_checkpoint_group`决定。 ## 恢复逻辑 恢复的主要逻辑是`mts_recovery_groups()` 这个函数。 在启动slave的时候,如果relay-log.info中存的Number_of_workers不为0,就说明之前是并行复制,然后调用 `mts_recovery_groups()`,进入恢复逻辑。如前所述,`mts_recovery_groups()` 的目的就是根据 slave_worker_info 和 slave_info 中信息,把空隙事务找出来。 首先会创建 Number_of_workers 个 worker,依次把每个worker.info的信息读出来,然后把worker执行位点信息和relay-log.info中记录的位点信息(低水位)相比,如果比后者小,说明崩溃前已经被checkpoint出队,不可能造成空隙,直接跳过;如果比后者大,就把worker存入 `above_lwm_jobs` 数组。 `above_lwm_jobs`收集完成后,初始化bitmap `rli->recovery_groups`,用来汇总每个worker的bitmap。对 `above_lwm_jobs` 中的每个worker,设置一个计数器`recovery_group_cnt`,从低水位位点开始扫relay log,每扫完一个事务,`recovery_group_cnt`加1,直到扫到worker.info中记录的位点为止,之后把worker的bitmap汇总到`rli->recovery_groups`中,其间会统计一个最大的 `recovery_group_cnt`,记入`rli->mts_recovery_group_cnt`,这个对应高水位。 bitmap 汇总逻辑如下: ~~~ sql/rpl_slave.cc:8965 for (uint i= (w->checkpoint_seqno + 1) - recovery_group_cnt, j= 0; i <= w->checkpoint_seqno; i++, j++) { if (bitmap_is_set(&w->group_executed, i)) { DBUG_PRINT("mts", ("Setting bit %u.", j)); bitmap_fast_test_and_set(groups, j); } } ~~~ 之后SQL线程就可以从低水位往高水位扫relay log,对于每个事务,如果 `rli->recovery_groups` 对应bit为1,说明崩溃前已经执行过,就跳过;反之,就对事务中的每个event调用 `do_apply_event()`执行。扫描到高水位后整个恢复逻辑结束,后面SQL线程就进入正常的执行逻辑,执行(串行)或者分发(并行)event。