## **MySQL主从复制**  ### **主从复制原理：** （1）master服务器将数据的改变记录二进制binlog日志，当master上的数据发生改变时，则将其改变写入二进制日志中； （2）slave服务器会在一定时间间隔内对master二进制日志进行探测其是否发生改变，如果发生改变，则开始一个I/OThread请求master二进制事件 （3）同时主节点为每个I/O线程启动一个dump线程，用于向其发送二进制事件，并保存至从节点本地的中继日志中，从节点将启动SQL线程从中继日志中读取二进制日志，在本地重放，使得其数据和主节点的保持一致，最后I/OThread和SQLThread将进入睡眠状态，等待下一次被唤醒。 ### **也就是说：** * 从库会生成两个线程,一个I/O线程,一个SQL线程; * I/O线程会去请求主库的binlog,并将得到的binlog写到本地的relay-log(中继日志)文件中; * 主库会生成一个log dump线程,用来给从库I/O线程传binlog; * SQL线程,会读取relay log文件中的日志,并解析成sql语句逐一执行; ### **主从复制延迟解决方案：** > Mysql 主从同步都是单线程的, master所有的`DDL`和`DML`都会写入`binlog`中, 由于`binlog`是顺序读写, 所以效率很高, slave的`sql Thread`将master的`DDL`和`DML`操作事件都在slave中重发.`DDL`和`DML`的IO操作是随机的, 不是顺序的, 所以成本要高很多, 另一方面由于`SQL Thread`也是单线程, 当master并发高的时候,产生的`DML`数量超出了slave`SQL Thread`的处理速度, 或者当slave有大型的query语句产生了锁, 那么延迟就产生了. **解决方案:** * 1. 业务的持久化层的实现采用分库架构, mysql服务器可以平行扩展, 分散压力 * 2. 单个主库, 多个从库, 主写从读 * 3. 服务的基础架构在业务层和持久化层间加入`memcache`或者`redis`构成的cache层. 降低mysql的读写压力 * 4. 不同的业务的mysql放在不同的物理机上，分散压力 * 5. 使用更加好的硬件设备 * 6. mysql5.7 之后使用`MTS`并发复制技术, 永久解决复制延迟问题