image.png

主从复制的时机：

• 当开启主从复制时，slave建立io线程连接主库。当master有写入操作导致数据变更时，在事务提交之前会将对数据的操作写入binlog。然后通知dump thread向slave发送数据变更。slave通过IO线程将数据写入relay log.在SQL线程内，读取对relay log的写入，通过SQL thread逻辑的完成数据的写入。
  https://www.hoohack.me/2017/07/11/learning-mysql-replication-detail

2.1复制模式

异步（默认）

写入到binlog之后，提交成功就返回，无需等待任何从节点的ack。

异步

半同步

将修改操作写入到binlog之后，通知dump thread将binlog的更新发送到从节点，等待从节点的ack。收到任意从节点的ack之后即可成功返回。若超时仍未收到ack，则降级为异步。

半同步

同步

全同步模式是指主节点和从节点全部执行了commit并确认才会向客户端返回成功。

2.3 why?

• 1.为什么要主从复制？他真的降低了数据库的读写压力吗？
  从常规思路来讲，不做主从复制的时候，主库承担来自客户端的读写压力。 采用主从复制和读写分离之后，主库和从库都既要写入，又要读出。似乎有点自欺欺人的感觉？ 事实上并不是这样的，从库读取binlog是顺序读，效率较高。由于IO线程和SQL线程独立运行，并不会由于其中一个阻塞另一个，即使SQL线程执行慢，IO线程也能将binlog的信息写入到relay log, SQL线程只需要不断地读取relay log即可。从而在保证主从之间复制的开销小的同时将主库面临的读取压力转移到从库。从库可以配置多个，读取时可以通过代理做一次负载均衡，降低单个从库的读取压力。
• 从库面临的主要压力来自于DDL和DML语句的执行，mysql的主从复制都是单线程(5.6之后 SQL执行可以并发)的操作。每条statement基本上都是随机写入，若主库的并发较高时，产生的DML数量超过slave的SQL thread所能处理的速度，或者当slave中有大型query语句产生了锁等待，会产生延时。