第20节：从库MTS多线程并行回放（二） - 简书.pdf

张鹏

10页

0次

2024-04-12

免费下载

第20节：从库MTS多线程并行回放（二）

本节包含一个笔记如下：

https://www.jianshu.com/p/e920a6d33005

这一节会先描述MTS的工作线程执行Event的大概流程。然后重点描述一下MTS中检查点的概念。在后面的第

25节我们可以看到，MTS的异常恢复很多情况下需要依赖这个检查点，从检查点位置开始扫描relay log做恢复

操作，但是在GTID AUTO_POSITION MODE模式且设置了recovery_relay_log=1的情况下这种依赖将会弱

化。

一、工作线程执行Event

前面我们已经讨论了协调线程分发Event的规则，实际上协调线程只是将Event分发到了工作线程的执行队列

中。那么工作线程执行Event就需要从执行队列中拿出这些Event，然后进行执行。整个过程可以参考函数

slave_worker_exec_job_group。因为这个流程比较简单，因此就不需要画图了，但是我们需要关注一些点如

下：

（1）从执行队列中读取Event。注意这里如果执行队列中没有Event那么就进入空闲等待，也就是工作线程处于

无事可做的状态，等待状态为‘Waiting for an event from Coordinator’。

（2）如果执行到XID_EVENT那么说明事务已经结束了那么需要完成内存信息更新操作。可参考

Slave_worker::slave_worker_exec_event和Xid_apply_log_event::do_apply_event_worker函数。更新内存相

关信息可参考函数commit_positions函数。下面是一些更新的信息，我们可以看到和slave_worker_info表中的

信息基本一致，如下：

1、更新当前信息

strmake(group_relay_log_name, ptr_g->group_relay_log_name,

sizeof(group_relay_log_name) - 1);

group_relay_log_pos= ev->future_event_relay_log_pos;

set_group_master_log_pos(ev->common_header->log_pos);

set_group_master_log_name(c_rli->get_group_master_log_name());

2、将检查点信息进行写入：

strmake(checkpoint_relay_log_name, ptr_g-

>checkpoint_relay_log_name,sizeof(checkpoint_relay_log_name) - 1);

checkpoint_relay_log_pos= ptr_g->checkpoint_relay_log_pos;

strmake(checkpoint_master_log_name, ptr_g-

>checkpoint_log_name,sizeof(checkpoint_master_log_name) - 1);

checkpoint_master_log_pos= ptr_g->checkpoint_log_pos;

3、设置GAQ序号：

checkpoint_seqno= ptr_g->checkpoint_seqno;

更新整个BITMAP，可能已经由检查点进行GAQ出队：

for (uint pos= ptr_g->shifted; pos < c_rli->checkpoint_group; pos++)

//重新设置位图因为checkpoint已经

{

//ptr_g->shifted是GAQ中出队的事务个数

if (bitmap_is_set(&group_shifted, pos))

//这里就需要偏移掉出队的事务，恢复已经不需要了

bitmap_set_bit(&group_executed, pos - ptr_g->shifted);

}

4、设置位图：

bitmap_set_bit(&group_executed, ptr_g->checkpoint_seqno);

//在本次事务相应的位置设置为1

（3）如果执行到XID_EVENT那么说明事务已经结束了那么需要完成内存信息的持久化，即强制刷内存信息持久

化到slave_worker_info表中（relay_log_info_repository设置为TABLE）。可参考函数commit_positions函

数，如下：

if ((error= w->commit_positions(this, ptr_group,

w->is_transactional())))

（4）如果执行到XID_EVENT还需要进行事务的提交操作，也就是进行Innodb层事务的提交。

从上面我们可以看到MTS中每次事务的提交并不会更新slave_relay_log_info表，而是进行slave_worker_info

表的更新，将最新的信息写入到slave_worker_info表中。

我们前面也说过SQL线程已经蜕变为协调线程，那么slave_relay_log_info表什么时候更新呢？下面我们就能看

到slave_relay_log_info表的更新实际上由协调线程在做完检查点之后更新。

二、MTS中检查点中的重要概念

总的说来MTS中的检查点是MTS进行异常恢复的起点。实际上就是代表到这个位置之前（包含自身）事务都是

已经在从库执行过了，但之后的事务可能执行完成了也可能没有执行完成。检查点由协调线程进行。

（1）协调线程的GAQ队列

前面我们已经知道MTS中为每个工作线程维护了一个Event的分发队列。除此之外协调线程还维护了一个非常的

重要的队列GAQ，它是一个环形队列。下面是源码中的定义：

master-binlog ordered queue of Slave_job_group descriptors of groups

that are under processing. The queue size is @c checkpoint_group. Group assigned

Slave_committed_queue *gaq;

每次协调线程分发事务的时候都会将事务记录到GAQ队列中，因此GAQ中事务的顺序总是和relay log文件中事

务的顺序一致的。检查点正是作用在GAQ队列上的，每次检查点的位置称为LWM，还记得上一节我叫大家先忽

略的LWM吗？就是这个。源码中定义也正是如此，它在GAQ队列中进行维护。如下：

The last checkpoint time Low-Water-Mark

Slave_job_group lwm;

of 10

免费下载

mtsc

关注

评论