一、引言
之前在部门分享主从同步延迟排查解决线上Mysql主从同步延迟排查解决_tingmailang的博客-CSDN博客的时候，同事产生了一些新问题，而且部分同事对于事务、同步、备份的了解仅限于网上的一些博客和社区，不深入也不完全正确，这里做一些分析
二、分析
比如：
1、物理备份卡住为什么会导致从库的数据不更新到磁盘和缓冲区？
2、半同步模式，从库卡住不会影响主库的事务提交吗？
3、为什么高性能Mysql推荐使用LVM逻辑备份，它是怎么实现快照镜像而不阻塞磁盘写？
1、这里简单画一下Mysql的主从模块
innodb是mysql的可配置引擎，相当于是一个插件
2、事务开始
事务开始之后，首先写入undolog，在表空间段内生成双向链表，也就是所谓的版本链，用于事务回滚以及MVCC
redolog记录所有数据页的变动，因此undolog的变动会被记录，用于保证持久化
修改缓冲区行数据，缓存区会被容量、时间频率等多种策略写入磁盘
3、事务提交
事务提交时，主库写入binlog，这个是在《Innodb存储引擎》明确提出的
写入binlog之后，由mysql的后台线程将数据传输到从库，主库根据同步模式决定是否等待ack应答，我们使用的是半同步模式
从库接收数据之后，写入relaylog，有另外一个异步线程写入缓冲区，如果开启了log_slave_update，还会写入从库的binlog
下面对几个问题进行分析
1、物理备份卡住为什么会导致从库的数据不更新到磁盘和缓冲区？
物理备份是对磁盘文件的复制，因此从库的relaylog是正常写入的，但是从relaylog改变磁盘文件会导致文件的改动，与复制互斥
2、半同步模式，从库卡住不会影响主库的事务提交吗？
其实任何一种模式，主库最终都会进行提交，默认的超时时间是10s，我们线上dba设置1s，超时即使主库没有收到ack信号也会完结这个事务
那么半同步比异步好在哪儿呢？只是降低了一种情况发生的概率，即主库发出之后，从库没有成功收到，但是主库宕机了，从库就会成为主库，这时候就会主从不一致。（异步的情况下这种可能比半同步得可能大得多）
那么如果超时主库自动结束事务了，这时候从库都没有收到，不还是不一致吗？mysql从库会把自己的gtid发给主库，主库和自己的gtid一对比，就自动从库缺少哪些，会把这些binlog再给从库发过去
3、为什么高性能Mysql推荐使用LVM逻辑备份，它是怎么实现快照镜像而不阻塞磁盘写？
LVM逻辑备份是基于Linux的CoupOnWrite机制，它备份的时候不将文件复制，如果磁盘有写入，他会将最小单位的扇形数据页通过子进程复制出来，也就是写时复制，因此几乎不会与写入冲突，即使最小单位的冲突也会很快结束（redis的rdb持久化也是基于这个机制）
三、总结
1、Mysql事务是有Innodb的undolog和redolog实现的，undolog记录行数据变化在表空间端形成双向链表用于回滚和MVCC，redolog记录数据页变化用于恢复到mysql崩溃宕机之前的情况
2、Mysql主从同步分为全同步、半同步、异步三种方式，但是不论哪一种只是决定主库是否需要等一等
3、备份分为物理备份和逻辑备份，LVM逻辑备份基于Linux的coupopwrite机制，是《高性能Mysql》推荐的