MySQL 主从同步,事务回滚的实现原理

BinLog

BinLog是记录所有数据库表结构变更(例如create、alter table)以及表数据修改(insert、update、delete)的二进制日志,主从数据库同步用到的都是BinLog文件。BinLog日志文件有三种模式。

STATEMENT 模式

内容:binlog 只会记录引起数据变更的 sql 语句

优势:该模式下,因为没有记录实际的数据,所以日志量和 IO 都消耗很低,性能是最优的

劣势:但有些操作并不是确定的,比如 uuid() 函数会随机产生唯一标识,当依赖 binlog 回放时,该操作生成的数据与原数据必然是不同的,此时可能造成无法预料的后果。

ROW 模式

内容:在该模式下,binlog 会记录每次操作的源数据与修改后的目标数据,StreamSets就要求该模式。

优势:可以绝对精准的还原,从而保证了数据的安全与可靠,并且复制和数据恢复过程可以是并发进行的

劣势:缺点在于 binlog 体积会非常大,同时,对于修改记录多、字段长度大的操作来说,记录时性能消耗会很严重。阅读的时候也需要特殊指令来进行读取数据。

MIXED 模式

内容:是对上述STATEMENT 跟 ROW 两种模式的混合使用。

细节:对于绝大部分操作,都使用 STATEMENT 来进行 binlog 的记录,只有以下操作使用 ROW 来实现:表的存储引擎为 NDB,使用了uuid() 等不确定函数,使用了 insert delay 语句,使用了临时表

主从同步流程:

1、主节点必须启用二进制日志,记录任何修改了数据库数据的事件。

2、从节点开启一个线程(I/O Thread)把自己扮演成 mysql 的客户端,通过 mysql 协议,请求主节点的二进制日志文件中的事件 。

3、主节点启动一个线程(dump Thread),检查自己二进制日志中的事件,跟对方请求的位置对比,如果不带请求位置参数,则主节点就会从第一个日志文件中的第一个事件一个一个发送给从节点。

4、从节点接收到主节点发送过来的数据把它放置到中继日志(Relay log)文件中。并记录该次请求到主节点的具体哪一个二进制日志文件内部的哪一个位置(主节点中的二进制文件会有多个)。

5、从节点启动另外一个线程(sql Thread ),把 Relay log 中的事件读取出来,并在本地再执行一次。

mysql默认的复制方式是异步的,并且复制的时候是有并行复制能力的。主库把日志发送给从库后不管了,这样会产生一个问题就是假设主库挂了,从库处理失败了,这时候从库升为主库后,日志就丢失了。由此产生两个概念。

  • 全同步复制

主库写入binlog后强制同步日志到从库,所有的从库都执行完成后才返回给客户端,但是很显然这个方式的话性能会受到严重影响。

  • 半同步复制

半同步复制的逻辑是这样,从库写入日志成功后返回ACK确认给主库,主库收到至少一个从库的确认就认为写操作完成。

RedoLog

binlog跟redolog区别:

  • redo log是InnoDB引擎特有的;binlog是MySQL的Server层实现的,所有引擎都可以使用。
  • redo log是物理日志,记录的是在某个数据页上做了什么修改;binlog是逻辑日志,记录的是这个语句的原始逻辑,比如给ID=2这一行的c字段加1。
  • redo log是循环写的,空间固定会用完;binlog是可以追加写入的。追加写是指binlog文件写到一定大小后会切换到下一个,并不会覆盖以前的日志。

在MySQL中如果每一次的更新操作都需要写进磁盘,然后磁盘也要找到对应的那条记录,然后再更新,整个过程IO成本、查找成本都很高。先写日志,再写磁盘BinLog,RedoLog。

1、 记录更新时,InnoDB引擎就会先把记录写到RedoLog(里面,并更新内存。同时,InnoDB引擎会在空闲时将这个操作记录更新到磁盘里面。

2、 如果更新太多RedoLog处理不了的时候,需先将RedoLog部分数据写到磁盘,然后擦除RedoLog部分数据。

RedoLog的write pos 跟checkpoint

RedoLog有write pos 跟checkpoint

write pos :是当前记录的位置,一边写一边后移,写到第3号文件末尾后就回到0号文件开头。

check point:缩短数据库的恢复时间,buffer pool空间不够用时,将脏页刷新到磁盘,redolog不可用时,刷新脏页

redo log顺序写实际上是循环写固定几个文件,写满一轮就要从头开始覆盖。它包括两个位点,check point和write pos,write pos是写到那个位置了,循环往后递增,check point是当前要擦除的位置。二者中间的空间是可写入的,当write pos追上check point时,就会先停下更新,覆盖掉一些记录,然后继续写入redo log。

redo log 的crash-safe

MySQL支持用户自定义在commit时如何将log buffer中的日志刷log file中。这种控制通过变量 innodb_flush_log_at_trx_commit 的值来决定。该变量有3种值:0、1、2,默认为1。但注意,这个变量只是控制commit动作是否刷新log buffer到磁盘。

  • 当设置为1的时候,事务每次提交都会将log buffer中的日志写入os buffer并调用fsync()刷到log file on disk中。这种方式即使系统崩溃也不会丢失任何数据,但是因为每次提交都写入磁盘,IO的性能较差。
  • 当设置为0的时候,事务提交时不会将log buffer中日志写入到os buffer,而是每秒写入os buffer并调用fsync()写入到log file on disk中。也就是说设置为0时是(大约)每秒刷新写入到磁盘中的,当系统崩溃,会丢失1秒钟的数据。
  • 当设置为2的时候,每次提交都仅写入到os buffer,然后是每秒调用fsync()将os buffer中的日志写入到log file on disk。

在主从复制结构中,要保证事务的持久性和一致性,需要对日志相关变量设置为如下:

  • 如果启用了二进制日志,则设置sync_binlog=1,即每提交一次事务同步写到磁盘中。
  • 总是设置innodb_flush_log_at_trx_commit=1,即每提交一次事务都写到磁盘中。

上述两项变量的设置保证了:每次提交事务都写入二进制日志和事务日志,并在提交时将它们刷新到磁盘中。

有了redo log,InnoDB就可以保证即使数据库发生异常重启,之前提交的记录都不会丢失,这个能力称为crash-safe。redolog两阶段提交`:为了让binlog跟redolog两份日志之间的逻辑一致。提交流程大致如下:

1 prepare阶段 --> 2 写binlog --> 3 commit

1.当在2之前崩溃时,重启恢复后发现没有commit,回滚。备份恢复:没有binlog 。一致
2.当在3之前崩溃时,重启恢复发现虽没有commit,但满足prepare和binlog完整,所以重启后会自动commit。备份:有binlog. 一致

UndoLog

undo log有两个作用:提供回滚和多个行版本控制(MVCC).主要分为两种

在数据修改的时候,不仅记录了redo,还记录了相对应的undo,如果因为某些原因导致事务失败或回滚了,可以借助该undo进行回滚。当delete一条记录时,undo log中会记录一条对应的insert记录,反之亦然,当update一条记录时,它记录一条对应相反的update记录。

当执行rollback时,就可以从undo log中的逻辑记录读取到相应的内容并进行回滚

  • insert undo log

代表事务在insert新记录时产生的undo log, 只在事务回滚时需要,并且在事务提交后可以被立即丢弃

  • update undo log

事务在进行update或delete时产生的undo log; 不仅在事务回滚时需要,在快照读时也需要;所以不能随便删除,只有在快速读或事务回滚不涉及该日志时,对应的日志才会被purge线程统一清除

以上就是MySQL 主从同步,事务回滚的实现原理的详细内容,更多关于MySQL 主从同步,事务回滚的资料请关注我们其它相关文章!

(0)

相关推荐

  • MySQL主从同步机制与同步延时问题追查过程

    前言 作为一名DBA,在工作中会经常遇到一些MySQL主从同步延迟的问题,这些同步慢的问题,其实原因非常多,可能是因为主从的网络问题导致,可能是因为网络带宽问题导致,可能是因为大事务导致,也可能是因为单线程复制导致的延迟. 今天遇到一个问题,Mysql持续报错,主从同步延时数过大或错误.所以这篇文章给大家分享下主从同步的机制原理以及问题排查思路. 故障表现 最直观的表现为: mysql> show slave status\G; // 状态一 Seconds_Behind_Master: NUL

  • MySQL主从同步中的server-id示例详解

    前言 当我们搭建MySQL集群时,自然需要完成数据库的主从同步来保证数据一致性.而主从同步的方式也分很多种,一主多从.链式主从.多主多从,根据你的需要来进行设置.但只要你需要主从同步,就一定要注意server-id的配置,否则会出现主从复制异常. 在控制数据库数据复制和日志管理中,有两个重要的配置:server-id和server-uuid,他们会影响二进制日志文件记录和全局事务标识. server-id配置 当你使用主从拓扑时,一定要对所有MySQL实例都分别指定一个独特的互不相同的serve

  • MYSQL事务回滚的2个问题分析

    因此,正确的原子操作是真正被执行过的.是物理执行. 在当前事务中确实能看到插入的记录.最后只不过删除了.但是AUTO_INCREMENT不会应删除而改变值. 1.为什么auto_increament没有回滚? 因为innodb的auto_increament的计数器记录的当前值是保存在存内存中的,并不是存在于磁盘上,当mysql server处于运行的时候,这个计数值只会随着insert改增长,不会随着delete而减少.而当mysql server启动时,当我们需要去查询auto_increm

  • Shell脚本实现监控MySQL主从同步

    代码如下: 复制代码 代码如下: #!/bin/bash #check MySQL_Slave Status #crontab time 00:10 MYSQLPORT=`netstat -na|grep "LISTEN"|grep "3306"|awk -F[:" "]+ '{print $4}'` MYSQLIP=`ifconfig eth0|grep "inet addr" | awk -F[:" "

  • MySQL数据库主从同步实战过程详解

    本文实例讲述了MySQL数据库主从同步实战过程.分享给大家供大家参考,具体如下: 接上一篇:MySQL数据库入门之备份数据库 安装环境说明 系统环境: [root@~]# cat /etc/redhat-release CentOS release 6.5 (Final) [root@~]# uname -r 2.6.32-431.el6.x86_64 数据库: 由于是模拟环境,主从库在同一台服务器上,服务器IP地址192.168.1.7 主库使用3306端口 从库使用3307端口 数据库数据目

  • Mysql主从同步的实现原理

    1.什么是mysql主从同步? 当master(主)库的数据发生变化的时候,变化会实时的同步到slave(从)库. 2.主从同步有什么好处? 水平扩展数据库的负载能力. 容错,高可用.Failover(失败切换)/High Availability 数据备份. 3.主从同步的原理是什么? 首先我们来了解master-slave的体系结构. 如下图: 不管是delete.update.insert,还是创建函数.存储过程,所有的操作都在master上.当master有操作的时候,slave会快速的

  • 详解MySQL数据库设置主从同步的方法

    简介 MySQL主从同步是目前使用比较广泛的数据库架构,技术比较成熟,配置也不复杂,特别是对于负载比较大的网站,主从同步能够有效缓解数据库读写的压力. MySQL主从同步的机制: MySQL同步的流程大致如下: 1.主服务器(master)将变更事件(更新.删除.表结构改变等等)写入二进制日志(master log). 2.从服务器(slave)的IO线程从主服务器(binlog dump线程)获取二进制日志,并在本地保存一份自己的二进制日志(relay log) 3.从服务器的SQL线程读取本

  • PHP入门教程之使用Mysqli操作数据库的方法(连接,查询,事务回滚等)

    本文实例讲述了PHP入门教程之使用Mysqli操作数据库的方法.分享给大家供大家参考,具体如下: Demo1.php <?php //使用 mysqli 对象操作数据库 //创建 mysqli 对象(资源句柄) $_mysqli = new mysqli(); //连接数据库 1.主机名(ip) 2.账户 3.密码 4.数据库 //mysqli_connect 函数 == $_mysqli -> connect(); $_mysqli -> connect('localhost','ro

  • MySQL5.1主从同步出现Relay log read failure错误解决方法

    众所周知MySQL5.1的Replication是比较烂的.MySQL的每一个版本更新关于同步方面每次都是可以看到一大堆.但MySQL 5.1性能是比较突出的.所以经不住诱惑使用MySQL 5.1.所以也要经常遇到一些Bug.如: 复制代码 代码如下: mysql> show slave status\G *************************** 1. row ***************************                Slave_IO_State: Wa

  • MySQL主从同步延迟的原因及解决办法

    由于历史原因,MySQL复制基于逻辑的二进制日志,而非重做日志.多次被问到何时MySQL能支持基于物理的复制,其实这就看MySQL各位大佬的想法.上次和赖老师脑暴,倏地说道:MySQL会不会来个基于Paxos的redo复制? 物理复制的真正好处不在于正确性,因为基于ROW格式的日志复制也已能完全保证复制的正确性.由于物理日志的写入是在事务执行过程中就不断写入,而二进制日志的写入仅仅在事务提交时.因此物理日志的优势如下所示: 复制架构下,大事务日志提交速度快: 复制架构下,主从数据延迟小: 假设执

随机推荐