（5.2）mysql高可用系列——mysql主从复制

Posted 2022-06-11 gered

关键词：mysql主从复制，mysql复制

【1】mysql支持的复制类型

　　基于binlog的3种模式（详情参考：binlog的3种日志记录模式），oracle在mysql5.5版本收购

　　【1.1】statement：基于语句的复制（5.5.6之前默认），主服务器执行的SQL语句，在从服务器执行同样的语句

　　【1.2】row：基于行的复制（5.5.7之后默认），把改变的内容复制到从库，而不是把SQL命令在从库重新执行一遍。mysql5.0就开始支持

　　【1.3】mixed：混合类型的复制，默认是使用 statement 语句方式复制，一旦发现基于语句无法精确复制时（比如now() 因为主从有延迟导致数据不一致）就会采用基于 row 行的方式复制。

 

　　

【2】mysql的4种同步方式介绍

　　　　　　以下图片均引用自《深入浅出mysql开发、优化与管理维护》

　　　　　　　

 　　　　　　　

　　【2.1】异步复制：

　　　　　　　主库只管binlog dump数据到从库，不保证主从完全一致，断电、崩溃等情况会丢失数据。（和MSSQL的高性能模式镜像一样）　　　

　　　　　　

 

 　　【2.2】全同步复制：

　　　　　　主库事务写入redo log和 binlog 文件后，binlog dump线程提取binlog数据给IO线程，IO线程把数据加载回从库的relay log文件。

　　　　　　从库SQL线程开启事务重做应用relay log数据操作，等从库提交完后，返回ACK确认标识，主库才会提交。

　　【2.3】传统半同步复制：

　　　　　　master事务commit 指令已经写入redo log（注意，这里已经提交了，再去同步，只是在等一个ACK）和 binlog 文件后，binlog dump线程提取binlog数据给IO线程，IO线程把数据加载回从库的relay log文件。

　　　　　　只要IO线程-》slave的relay log已经flush disk 磁盘落地，slave就返回ACK确认标识给master。

　　　　　　注意：

　　　　　　　　这里的commit主库上是已经在 binlog、redo log 中提交了的，其他session都可以看到。

　　　　　　　　但需要等待从库返回ACK确认标识才会把事务提交到存储引擎持久化（即 ibdata、ibd等磁盘数据文件）且返回到client一个commit成功的指令。

　　　　　　　　意思就是，master上这个事务其实是已经提交了，master的其他Session是可以看到这个提交后的事务的，而slave还没有commit。

　　　　　　　　这个时候master挂了，master上的数据和slave不一致。master crash后，master根据redo重做提交了这个事务，在切换到从后，slave因为没有commit而回滚了这个事务导致数据丢失。导致主从不一致。

　　　　　　

　　　　　　

 

 

　　【2.4】增强半同步复制（mysql 5.7及以上才可以用）

　　　　　　与【2.3】传统半同步复制大致一样。唯一的区别就是，在事务提交过来后：

　　　　　　核心区别：主库会等从库在relay log阶段持久化该事务到该文件后，接受ACK成功确认标识后，再进行提交（commit指令写入redo log）

　　　　　　　　传统的半同步复制：

　　　　　　　　　　master 会把binlog和redo log全部写了。

　　　　　　　　增强半同步复制：

　　　　　　　　　　master 只会写binlog，然后等slave的IO线程把事务持久化（flush disk）到 relay log 上后，返回ACK确认标识。

　　　　　　　　　　master收到确认标识后才会commit 写入到redo log，并返回给客户端commit成功的指令。

　　　　　　　　宕机情况：

　　　　　　　　　　主库上这个事务因为没有写入redo log，所以这个事务被认为是未提交。master的其他session是不可以看到这个事务的。

　　　　　　　　　　这个时候主库挂了，master上的数据和slave一致，master crash后，slave不丢数据。