stop slave后，正在执行的事务是完成了还是回滚了rollback

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)

可看到，数量又恢复到开始复制前的数量。

也就是说，事务回滚了。