MySQL---4.主从

目录

1.主从切换流程

2.主从同步流程

3.binlog的三种格式

4.主从同步延迟

---

1.主从切换流程

readonly设置对super权限用户是无效的，而用于同步更新的线程，就拥有super权限

2.主从同步流程

slave B拿到binlog后，写入到本地文件，称为中转日志（relay log）

sql_thread读取中转日志，解析日志中的命令，并执行，后面sql_thread演变成多线程，提高SQL语句的执行效率

3.binlog的三种格式

①statement

记录的是SQL语句的原文

注：当delete语句中含有limit，可能会导致主从数据出现不一致的情况。

原因：主从delete语句使用的索引不同，导致执行计划不同，从而删除不同的数据

注：

当主库语句A先获取id=1，然后语句B再获取id=2；接着语句B提交，写binlog，语句A再写binlog，

如果从库获取语句后，会不会发生语句B获取id=1，而语句A获取id=2的情况？

不会，在insert语句之前，还有一句set insert_id=1，这个命令的意思是，这个线程里下一次需要用到自增值的时候，不论当前表的自增值是多少，固定用1这个值

因此，即使两个insert语句在主备库的执行顺序不同，自增主键字段的值也不会不一致

②row

记录的是数据的变化

注：当主执行delete语句，binlog中会记录真实删除行的主键id，这样传到从库的时候，就肯定会删除正确的数据，不会出现不一致的情况

优点：

1）恢复数据

当执行delete，row格式的binlog也会把被删除的行的整行信息保存起来，所以如果执行完delete，想要恢复，则直接可以把binlog中的delete语句转成insert

当执行insert，同上，将insert转成delete语句

当执行update，binlog会记录修改前的整行数据及修改后的整行数据，当想要恢复，只需要对调两行信息，再去数据库执行一下，就可以恢复

2）不易出现主从数据不一致的情况               

③mixed

问：为什么会存在mixed这种binlog形式？

答：1）有些statement格式的binlog可能会导致数据不一致，所以要使用row格式

       2）但是row的缺点是很占空间，比如用delete语句删除10万条数据，用statement的话，就是一个SQL语句记录到binlog中，如果用row，会将10万条数据写到binlog，耗费大量IO，影响执行速度

       3）所以，MySQL会自己判断这条SQL语句是否有可能引起主从不一致，如果可能，则使用row格式，否则使用statement格式

 

4.主从同步延迟

①同步时间点

1）主库A执行完一个事务，写入binlog，此时为T1时刻

2）主库A将binlog传递给从库B，B接收完的时刻为T2时刻

3）从库B执行完成这个事务，此时为T3时刻

在网络正常的情况下，T2-T1的时间间隔非常小，延迟的主要来源是T2-T3之间的时间差，所以说，最直接的表现是，从库消费relay log的速度，小于主库生产binlog的速度

②延迟的来源

1）从库机器配置较低、性能较差

2）从库的压力比较大

从库一般提供一些读能力，或者是运营后台需要的分析语句，不能影响正常业务，所以在备库上跑

3）大事务

如果主库上执行语句花费了10分钟，则很可能导致从库延迟10分钟；大表DDL

（不要一次性用delete语句删除太多数据-------大事务）

4）从库没有索引

主库利用索引修改数据，从库没有索引只能全表扫描

5）从库的并行复制能力

在5.6版本之前，MySQL只支持单线程复制，由此在主库并发高、TPS高时就会出现严重的主从延迟问题