一、为什么要使用主从复制
开启读写分离过后即便是业务系统的主库需要临时锁表也不会影响业务系统的读操作
可以做数据的热备
读写的分离减轻了主库的压力从而降低了磁盘IO的访问频率
二、主从复制的原理
Binary log：主数据库的二进制日志。
Relay log：从服务器的中继日志。
第一步：master在每个事务更新数据完成之前，将该操作记录串行地写入到binlog文件中。
第二步：salve开启一个I/O Thread，该线程在master打开一个普通连接，主要工作是binlog dump process。如果读取的进度已经跟上了master，就进入睡眠状态并等待master产生新的事件。I/O线程最终的目的是将这些事件写入到中继日志中。
第三步：SQL Thread会读取中继日志，并顺序执行该日志中的SQL事件，从而与主数据库中的数据保持一致。
三、为什么MySQL5.6.*会出现主从数据库的延迟现象
为什么会存在relay log文件？
SQL线程不能够及时的处理IO线程读取过来的bin log文件，只能写入relay log中作为缓冲区
导致延迟的会是主从复制流程中的哪一个步骤？
首先要清楚复制流程的IO操作属于什么IO（顺序IO或者随机IO）
什么是顺序IO
假设我们已经找到了第一块数据，并且其他所需的数据就在这一块数据后边，那么就不需要重新寻址，可以依次拿到我们所需的数据，这个就叫顺序IO。
什么是随机IO
假设我们所需要的数据是随机分散在磁盘的不同页的不同扇区中的，那么找到相应的数据需要等到磁臂（寻址作用）旋转到指定的页，然后盘片寻找到对应的扇区，才能找到我们所需要的一块数据，一次进行此过程直到找完所有数据，这个就是随机IO，读取数据速度较慢。
主从复制过程中属于顺序IO的操作是哪些？
① 主库数据写入bin log文件的过程
② IO线程读取bin log文件的过程
③ 从库将bin log 写入relay log文件时的过程
6. 主从复制过程中属于随机IO的过程
① SQL线程解析relay log的过程
7. 因为解析relay log为随机IO所以问题出现在解析上
四、主从复制延迟的原因有哪些？
1. 从库机器性能过低，资源不足
2. 从库的读压力过高，消耗大量CPU
3. 大事务执行，bin log日志写入需要等待（事务执行结束才会开始写入binlog）
4. 从库解析relaylog写操作为随机IO
5. 主库DDL数据过大，超出从库的承受范围
6. 从库同步数据时可能与其他查询线程发生锁抢占
7. 网络原因--从库异地
五、解决延迟的方法
增加SQL线程
六、SQL线程加到多少？
与CPU核数相同即可，不得大于CPU核数
七、如何保证增加SQL线程后解析relaylog不会重复？
使用调度器--coordnator
八、MySQL5.7以后不存在主从复制延迟问题
MySQL5.7以后使用GTID（组提交）的方式进行主从复制
GTID支持并行复制
