MySQL 主从复制

MySQL 主从复制

 

一、MySQL复制解决的问题

数据分布 -- 横向扩展解决方案 -- 提供读写分离的能力

负载平衡

数据备份--安全性

高可用性和容错

二、MySQL支持的复制类型

（１）：基于语句的复制： 在主服务器上执行的SQL语句，在从服务器上执行同样的语句。**MySQL默认采用基于语句的复制，效率比较高。**  一旦发现没法精确复制时， 会自动选着基于行的复制。

（２）：基于行的复制： 把改变的内容复制过去，而不是把命令在从服务器上执行一遍. 从 mysql 5.0开始支持

（３）：混合类型的复制: 默认采用基于语句的复制，一旦发现基于语句的无法精确的复制时，就会采用基于行的复制。

三、主从复制原理

1、Master 开启 bin-log 功能，日志文件用于记录数据库的读写增删

2、Master 会生成一个 log dump (I/O) 线程

      Slave 生成两个线程，一个 I/O 线程，一个 SQL 线程；

3、Slave 通过 I/O 线程连接 Master，并且请求某个 bin-log，position 之后的内容。

Master 服务器收到 Slave I/O 线程发来的日志请求信息，Master 的 I/O 线程去将  bin-log内容，position 返回给 Slave I/O 线程。

4、Slave 服务器收到 bin-log 日志，将 bin-log 日志内容写入中继日志 ( Relay_log )，创建一个 master.info 的文件，该文件记录了 Master ip 用户名 密码 master bin-log 名称，bin-log position。

5、Slave 端开启 SQL 线程，实时监控中继日志( Relay_log )内容是否有更新，解析文件中的 SQL 语句，在 Slave 数据库中去执行,来实现主从的操作一致，而最终数据一致；

四、主从复制存在的问题：

1、主库宕机后，数据可能丢失

2、从库只有一个sql Thread，主库写压力大，复制很可能延时

解决方法：

1、半同步复制---解决数据丢失的问题

2、并行复制----解决从库复制延迟的问题

五、半同步复制(after_commit)：

MySQL从5.5开始推出了半同步复制。

相比异步复制，半同步复制提高了数据完整性，因为很明确知道，在一个事务提交成功之后，这个事务就至少会存在于两个地方。即在master的dumper线程通知slave后，增加了一个ack（消息确认），即是否成功收到t1的标志码，也就是dumper线程除了发送t1到slave，还承担了接收slave的ack工作。如果出现异常，没有收到ack，那么将自动降级为普通的复制，直到异常修复后又会自动变为半同步复制。

存在问题：

在MySQL 5.5~5.6使用after_commit的模式下，客户端事务在存储引擎层提交后，在得到从库确认的过程中，主库宕机了。此时，即主库在等待Slave ACK的时候，虽然没有返回当前客户端，但事务已经提交，其他客户端会读取到已提交事务。如果Slave端还没有读到该事务的events，同时主库发生了crash，然后切换到备库。那么之前读到的事务就不见了，出现了幻读。

优化半同步复制---无损复制(after_sync)：

在5.7.2引入了Loss-less Semi-Synchronous，在调用 binlog sync 之后，engine 层commit之前等待 Slave ACK。

这样只有在确认 Slave 收到事务 events 后，事务才会提交。在commit之前等待 Slave ACK，同时可以堆积事务，利于 group commit，有利于提升性能。

主库 log dump (I/O) 线程独立出一个 Ack Receiver 线程 ，专门用于接收 Slave 返回的ack请求，这将之前dump线程的发送和接受工作分为了两个线程来处理。

六、并行复制：

并行是指从库SQL多线程解析文件中的 SQL 语句，在 Slave 数据库中去执行。

并行复制基于group commit。