1.关于stop slave后,事务执行结果
如果从库上SQL线程正在应用relay log,或者说正在执行一个事务,此时如果stop slave,那么这个事务执行结果会是什么,完成还是未完成?
由于事务的原子性,可以这么说,事务要么执行完成,要么回滚。
先说结论,事务执行结果有两种:
- 执行完成
- 未执行完成(事务回滚)
那什么情况执行完成,什么情况事务回滚呢?
从源码层面分析,如果执行stop slave时,事务[commit] event进入执行队列,那这个事务,会一直执行,直到完成。
如果执行stop slave时,事务[commit] event尚未进入执行队列,那这个事务会回滚。
如何查看事务是否执行完成呢?
这个其实很简单。在主库上执行一条更新SQL,stop slave后,比较下主从的数据是否一致。如果一致,表示更新执行完成。否则,表示更新没有执行。
对于事务执行完成的情况,比较好观察,查看最后的主从数据就可以了。
针对事务未执行完成,也就是回滚的情况,下面做下模拟,观察下这个回滚过程。
2.观察事务回滚
如果要观察事务的回滚过程,需要将事务隔离级别调整为「读未提交」read uncommited。
基于上一篇文章,大事务的模拟过程可参考
stop slave 卡住模拟--大事务场景
,模拟回滚。
接下来,只介绍关键步骤。
2.1.设置从库的事务隔离级别
设置事务隔离级别为「读未提交」:
set global transaction isolation level read uncommitted;
退出当前会话,重建会话,查看事务隔离级别:
show variables like '%tx_isolation%';
+---------------+------------------+
| Variable_name | Value |
+---------------+------------------+
| tx_isolation | READ-UNCOMMITTED |
+---------------+------------------+
1 row in set (0.01 sec)
2.2.启动SQL thread
先说下前置操作,
从库首先只开启io thread,主库上提交大事务后,从库等relay log同步到本地,再启动SQL thread。
开启SQL thread之前,首先查看从库上的记录数:
select count(*) from apple_test;
+----------+
| count(*) |
+----------+
| 33554432 |
+----------+
1 row in set (12.76 sec)
接着,开启 SQL thread
>start slave sql_thread;
Query OK, 0 rows affected (0.00 sec)
再次查看从库上的记录数量:
> select count(*) from apple_test;
+----------+
| count(*) |
+----------+
| 38382208 |
+----------+
1 row in set (11.57 sec)
可以看到数据量在明显增长。
2.3.停止复制,查看事务执行情况
> stop slave;
停止复制后,再次查看记录数量:
> select count(*) from apple_test;
+----------+
| count(*) |
+----------+
| 33554432 |
+----------+
1 row in set (8.98 sec)
可看到,数量又恢复到开始复制前的数量。
也就是说,事务回滚了。