标签:span 引擎 ima 记录 回滚 height blank 事务 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】异步复制:
主库只管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不丢数据。
标签:span 引擎 ima 记录 回滚 height blank 事务 mysql
原文地址:https://www.cnblogs.com/gered/p/11299168.html