MySQL主从复制原理

MySQL主从复制是构建高可用MySQL的基础，复制就是让一台服务器的数据和其它服务器保持同步，一台主库能够同步到多台备库上面，备库也能够做为另外一台服务器的主库。主库和备库之间能够有多种不一样的组合方式。

主从复制

1)、主库记录二进制日志，每次准备提交事物完成数据库更新前，先记录二进制日志，记录二进制日志后，主库会告诉存储引擎能够提交事物了

2)、备库将主库的二进制日志复制到本地的中继日志中，首先，备库会先启动一个工做进程，称为IO工做线程，负责和主库创建一个普通的客户端链接。若是该进程追遇上了主库，它将进入睡眠状态，直到主库有新的事件产生通知它，他才会被唤醒，将接收到的事件记录到中继日志中。

3)、备库的SQL线程执行最后一步，该线程从中继日志中读取事件而且在备库执行，当SQL线程遇上IO线程的时候，中继日志一般记录在系统缓存中，因此中继日志的开销很低。SQL线程也能够根据配置选项来决定是否写入其本身的二进制日志中。

半同步复制

如何解决MySQL主库宕机致使的数据丢失状况？

使用半同步复制。在主库commit以前，须要先将binlog同步到从库，主库能够设置同步binlog的过时时间，在binlog复制到从库以后，从库后续会自行重放中继日志。不过这样也增长了客户端的延迟。另外这个须要安装下MySQL的插件。

MySQL的半同步插件为：semisync_xx.so

具体如何操做，参考我以前的博客：MySQL复制详解

复制方式

基于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复制架构

参考

• MySQL复制详解