MySQL 主从复制主流架构模型
我们基于 binlog 可以复制出一台 MySQL 服务器，也可以复制出多台，取决于我们想实现什么功能。主流的系统架构有如下几种方式：
MySQL 主从复制原理
MySQL 主从复制涉及到三个线程：
- 一个在主节点的线程：log dump thread
- 从库会生成两个线程：一个 I/O 线程，一个 SQL 线程
主库会生成一个 log dump 线程,用来给从库 I/O 线程传 binlog 数据。
从库的 I/O 线程会去请求主库的 binlog，并将得到的 binlog 写到本地的 relay log (中继日志)文件中。
SQL 线程,会读取 relay log 文件中的日志，并解析成 SQL 语句逐一执行。
主节点 log dump 线程
当从节点连接主节点时，主节点会为其创建一个 log dump 线程，用于发送和读取 binlog 的内容。在读取 binlog 中的操作时，log dump 线程会对主节点上的 binlog 加锁；当读取完成发送给从节点之前，锁会被释放。主节点会为自己的每一个从节点创建一个 log dump 线程。
从节点I/O线程
当从节点上执行start slave命令之后，从节点会创建一个 I/O 线程用来连接主节点，请求主库中更新的Binlog。I/O 线程接收到主节点的 log dump 进程发来的更新之后，保存在本地 relay-log（中继日志）中。
从服务器 I/O 线程将主服务器的 binlog 日志读取过来，解析到各类 Events 之后记录到从服务器本地文件，这个文件就被称为 relay log。然后 SQL 线程会读取 relay log 日志的内容并应用到从服务器，从而使从服务器和主服务器的数据保持一致。中继日志充当缓冲区，这样 master 就不必等待 slave 执行完成才发送下一个事件。
从节点 SQL 线程
SQL 线程负责读取 relay log 中的内容，解析成具体的操作并执行，最终保证主从数据的一致性。
对于每一个主从连接，都需要这三个进程来完成。当主节点有多个从节点时，主节点会为每一个当前连接的从节点建一个 log dump 进程，而每个从节点都有自己的 I/O 进程，SQL 进程。
从节点用两个线程将从主库拉取更新和执行分成独立的任务，这样在执行同步数据任务的时候，不会降低读操作的性能。比如，如果从节点没有运行，此时 I/O 进程可以很快从主节点获取更新，尽管 SQL 进程还没有执行。如果在 SQL 进程执行之前从节点服务停止，至少 I/O 进程已经从主节点拉取到了最新的变更并且保存在本地 relay log 中，当服务再次起来之后就可以完成数据的同步。
要实施复制，首先必须打开 Master 端的 binlog 功能，否则无法实现。
因为整个复制过程实际上就是 Slave 从 Master 端获取该日志然后再在自己身上完全顺序的执行日志中所记录的各种操作。如下图所示：
MySQL主从复制流程
在主从同步的过程中，主库会将所有的操作事件记录在 binlog 中，从库通过开启一个 I/O 线程保持与主库的通信，并在一定时间间隔内探测 binlog 日志文件是否发生改变。如果 binlog 日志发生了变化，主库生成一个 binlog dump 线程向从库 I/O 线程传送 binlog。从库上的 I/O 线程将 binlog 复制到自己的 relay log 中。最终由从库中的 SQL 线程读取 relay log 中的事件重放到从库上。
MySQL保证主备一致
- binlog_format=row 利于恢复数据，主流用法
- 有些statement格式的binlog可能会导致主备不一致，比如SQL语句中主从库可能用到不同的索引
- 主从循环复制问题解决方法：两个库的server id必须不同、一个备库接到binlog并在重放的过程中，生成与原binlog的server id相同的新的binlog，从库收到日志后先判断server_id，如果相同则丢弃
- 一般情况下，把生产库改成“非双1”配置，是设置 innodb_flush_logs_at_trx_commit=2、（每次事务提交会写入日志文件，但并不会立即刷写到磁盘，日志文件会每秒刷写一次到磁盘。） sync_binlog=1000。（1000个事务/SQL后刷盘）
主从延迟原因
随机重放
Mysql 主库中写 binlog 的操作是顺序写的，之前我们提到过，磁盘的顺序读写速度是很快的。同样的，从库中的 I/O 线程操作日志的速度效率也是很高的。但是别忘了，还有一个 SQL 线程来进行数据重放，而重放的过程是随机写盘的。到这里你应该就明白了吧，某一时刻 relay log 里的数据来不及重放进从库，就会产生主从延迟的情况。
主库并发高
知道了从库中 SQL 线程的重放情况，对于主库并发高导致主从延迟肯定就不难理解了。某一时刻，大量写请求打到主库上，意味着要不断对 binlog 进行写入，此时从库中的 SQL 线程就会应接不暇，自然会产生主从延迟。
备库的压力大
主库提供写能力，备库提供一些读能力。忽略了备库的压力控制，导致备库上的查询耗费了大量的CPU资源，影响了同步速度，造成主备延迟
锁等待
对于 SQL 单线程来说，当遇到阻塞时就会一直等待，直到执行成功才会继续进行。如果某一时刻从库因为查询产生了锁等待的情况，此时只有当前的操作执行完成后才会进行下面的操作，同理也就产生了主从延迟的情况。比如大事务提交，因为主库上必须等事务执行完才会写入binlog，再传给备库。所以，如果一个主库上的语句执行10分钟，那这个事务很可能会导致从库延迟10分钟
大事务
大事务（一次性地用delete语句删除太多数据/大表DDL）
参考