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

关键词：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】异步复制(和MSSQL的高性能模式镜像一样)：

主库只管binlog dump数据到从库，不保证主从完全一致，断电、崩溃等情况会丢失数据。

【2.2】全同步复制：

【2.2.1】核心概念：主从复制，主库要等到从库重做事务并且提交成功，接受到ACK成功确认标识后，主库才能提交事务。

【2.2.2】与半同步的区别：半同步是只需要持久化到relay log阶段即可返回ACK成功标识给主库，而全同步需要等待从库SQL进程完整的运行完该事务内容才能返回ACK成功标识。

【2.2.3】原理：

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

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

【2.3】传统半同步复制：

【2.3.1】原理：

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

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

【2.3.2】特性：

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

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

【2.3.3】宕机情况：master上这个事务其实是已经提交了，master的其他Session是可以看到这个提交后的事务的，而slave还没有commit。

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

【2.4】增强半同步复制(mysql 5.7及以上才可以用，与MSSQL镜像高安全模式相同)：

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

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

【2.4.1】传统的半同步复制：

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

【2.4.2】增强半同步复制：

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

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

【2.4.3】宕机情况：

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

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

【2.5】GTID 复制(mysql 在 5.6.2 及之后开始支持GTID)：

原文：https://www.cnblogs.com/gered/p/11299168.html