MySQL主从复制原理浅析
MySQL主从复制是构建高可用MySQL的基础，复制就是让一台服务器的数据和其它服务器保持同步，一台主库可以同步到多台备库上面，备库也可以作为另一台服务器的主库。主库和备库之间可以有多种不同的组合方式。
主从复制
1)、主库记录二进制日志，每次准备提交事物完成数据库更新前，先记录二进制日志，记录二进制日志后，主库会告诉存储引擎可以提交事物了
2)、备库将主库的二进制日志复制到本地的中继日志中，首先，备库会先启动一个工作进程，称为IO工作线程，负责和主库建立一个普通的客户端连接。如果该进程追赶上了主库，它将进入睡眠状态，直到主库有新的事件产生通知它，他才会被唤醒，将接收到的事件记录到中继日志中。
3)、备库的SQL线程执行最后一步，该线程从中继日志中读取事件并且在备库执行，当SQL线程赶上IO线程的时候，中继日志通常记录在系统缓存中，所以中继日志的开销很低。SQL线程也可以根据配置选项来决定是否写入其自己的二进制日志中。
半同步复制
如何解决MySQL主库宕机导致的数据丢失情况？
使用半同步复制。在主库commit之前，需要先将binlog同步到从库，主库可以设置同步binlog的过期时间，在binlog复制到从库之后，从库后续会自行重放中继日志。不过这样也增加了客户端的延迟。另外这个需要安装下MySQL的插件。
MySQL的半同步插件为：semisync_xx.so
复制方式
基于GTID和日志
- 日志：传统的方式，默认的方式。依赖二进制日志，根据日志的偏移量。事务不断提交，二进制日志的偏移量也会不断的变化。需要从库告诉主库，自己明确复制到了偏移量的什么位置。
- GTID: 全局事务ID，在一个集群内的一个GTID是唯一的， GTID=source_id:transcation_id，source_id为那一台机器上的，slave增量复制还未同步的GTID即可。
| 基于日志复制 | 基于GTID |
|---|---|
| 兼容性好 | 与老版本不兼容 |
| 支持MMM与MHA架构 | 仅支持MHA架构 |
| 准备切换后很难找到新的同步点 | 基于事务ID复制，很方便的找到未完成的事务ID |
| 可以方便的跳过复制操作 | 只能通过置入空事务的方式跳过操作，会更复杂一点 |
建议优先使用GTID方式，可以更安全的进行故障转移。
主从复制延迟
产生延迟原因？
- 主节点如果执行一个很大的事务(更新千万行语句，总之执行很长时间的事务)，那么就会对主从延迟产生较大的影响。
- 网络延迟，日志较大，slave数量过多。
- 主上多线程写入，从节点只有单线程恢复。
处理办法：
- 大事务：将大事务分为小事务，分批更新数据。
- 减少Slave的数量，不要超过5个，减少单次事务的大小。
- MySQL 5.7之后，可以使用多线程复制，使用MGR复制架构。