0

mysql复制对事务的处理

刘伟 2019-07-18
25
摘要:从innodb开始,mysql的事务引擎越来越强,mysql最重要的复制特性也就需要对事务的支持。

众所周知,mysql的最原始实现myisam是不支持事务的,在innodb出现之前,复制的处理很简单,任何执行的语句全部发送给slave就可以了,没有事务那么多事情,但是从innodb开始,mysql的事务引擎越来越强,mysql最重要的复制特性也就需要对事务的支持,但以现在的目光来看,直到gtid实现之前,只能说是在无事务的实现上套了一个事务的壳子,下面要介绍的,就是这个壳子。

首先从mysql的处理线程开始说。

mysql对于所有客户端的连接,都有一个服务端的处理线程对应,这个线程的实现是在sql_class.h里面的THD类,复制的一部分最基础的数据结构及方法都在这个类里面。

复制事务实现最重要的结构之一,event缓存会在受到任何触发event产生的动作之后,调用初始化函数生成该线程独有的复制event缓存,一般而言,当线程所属会话首次发起事务的时候,这个缓存就会被创建,可以参见THD类的

binlog_start_trans_and_stmt方法。如果是row格式的复制,在之后还会初始化table_map。

如果一切正常,当事务中执行事务语句(DML)的时候,所以这些语句形成的event都会被记录到缓存里面,等到commit事务以后,这个缓存的数据会立即被刷入磁盘上的binlog文件里面,之后通过slave请求发送到slave,在slave重复执行。

顺便提一下,mysql的binlog里面的事务都是相互独立按顺序排列的。

现在开始假设意外的发生。

正常意外一:事务执行中rollback了。

如果在一个事务中,所有执行的语句都是在innodb表上执行(对于多个事务引擎如tokudb等并用尚未测试),直接执行rollback,会导致mysql直接清除缓存,不会写入任何event记录到binlog。

正常意外二:事务执行中使用了非事务表(myisam),然后rollback了。

在一个事务中,即有事务表,也有非事务表,如果正常执行,则没有任何问题,当如果在非事务表上的修改执行了,复制设置为statement的时候,binlog会把所有执行的event全部记录下来写入日志,包括事务与非事务语句,然后在最后面加上rollback。如果复制格式设置为row,那么所有事务表相关的数据都会被清理掉,而非事务表上的数据会被标记为已提交事务写入binlog。

正常意外三:事务执行顺序如下:事务语句1-》非事务语句2-》save point -》事务语句3 -》 rollback to savepoint -》 事务语句4 -》提交

对于上面的情况,statement情况下,所有执行的语句包括savepoint与rollback都会按顺序被记录到binlog。row情况下,非事务语句与事务语句是分别记录到binlog中,非事务执行event会全部被记录,事务执行event会连带savepoint与rollback都记录下来。

正常意外四:事务执行顺序如下:事务语句1-》savepoint-》非事务语句2-》事务语句3-》rollback to savepoint-》事务语句4 -》 commit

同上。

异常意外一:master正常提交了,但是在slave执行失败了。

master执行完成,提交之后,slave接收到relay然后执行,执行期间由于意外原因失败了。这个时候,statement格式下,mysql会重新回到事务begin处重新执行,如果再次失败的话就会报错。row模式下情况类似,区别在于,如果是包含非事务表执行的事务,非事务表上的event不会被重新执行。

「喜欢文章,快来给作者赞赏墨值吧」

评论

0
0
MySQL
订阅
欢迎订阅MySQL频道,订阅之后可以获取最新资讯和更新通知。
墨值排行
今日本周综合
近期活动
全部
相关课程
全部