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)
可看到，数量又恢复到开始复制前的数量。
也就是说，事务回滚了。