标签搜索

目 录CONTENT

文章目录

MySQL三大日志及主从复制的原理.md

小小城
2021-08-22 / 0 评论 / 0 点赞 / 5 阅读 / 4,557 字 / 正在检测是否收录...
温馨提示:
本文最后更新于 2022-05-02,若内容或图片失效,请留言反馈。部分素材来自网络,若不小心影响到您的利益,请联系我们删除。

MySQL三大日志及主从复制的原理

@[toc]
日志是mysql数据库的重要组成部分,记录着数据库运行期间各种状态信息

mysql日志主要包括错误日志、查询日志、慢查询日志、事务日志、二进制日志几大类。

作为开发,我们重点需要关注的是二进制日志(binlog)和事务日志(包括redo log和undo log)

一、binlog

1.概念

  •  binlog用于记录数据库执行的写入性操作(不包括查询)信息,以二进制的形式保存在磁盘中。binlog是mysql的逻辑日志,并且由Server层进行记录,使用任何存储引擎的mysql数据库都会记录binlog日志。

2.分类

  •  逻辑日志:可以简单理解为记录的就是sql语句。

  •  物理日志:因为mysql数据最终是保存在数据页中的,物理日志记录的就是数据页变更。

  • binlog是通过追加的方式进行写入的,可以通过max_binlog_size参数设置每个binlog文件的大小,当文件大小达到给定值之后,会生成新的文件来保存日志

3.binlog使用场景

在实际应用中,binlog的主要使用场景有两个,分别是主从复制和数据恢复。

  •  主从复制:在Master端开启binlog,然后将binlog发送到各个Slave端,Slave端重放binlog从而达到主从数据一致。
  •  数据恢复:通过使用mysqlbinlog工具来恢复数据。

4.binlog刷盘时机

对于InnoDB存储引擎而言,只有在事务提交时才会记录biglog,此时记录还在内存中,那么biglog是什么时候刷到磁盘中的呢?mysql通过sync_binlog参数控制biglog的刷盘时机,取值范围是0-N

  •  0:不去强制要求,由系统自行判断何时写入磁盘;
  •  1:每次commit的时候都要将binlog写入磁盘;
  •  N:每N个事务,才会将binlog写入磁盘。

从上面可以看出,sync_binlog最安全的是设置是1,这也是MySQL 5.7.7之后版本的默认值。但是设置一个大一些的值可以提升数据库性能,因此实际情况下也可以将值适当调大,牺牲一定的一致性来获取更好的性能。

5.binlog日志格式

binlog日志有三种格式,分别为STATMENT、ROW和MIXED

MySQL 5.7.7之前,默认的格式是STATEMENTMySQL 5.7.7之后,默认值是ROW。日志格式通过binlog-format指定。

  •  STATMENT
  • 基于SQL语句的复制(statement-based replication, SBR),每一条会修改数据的sql语句会记录到binlog中
  • 优点:不需要记录每一行的变化,减少了binlog日志量,节约了IO, 从而提高了性能;
  • 缺点:在某些情况下会导致主从数据不一致,比如执行sysdate()、slepp()等。
  •  ROW
  • 基于行的复制(row-based replication, RBR),不记录每条sql语句的上下文信息,仅需记录哪条数据被修改了
  • 优点:不会出现某些特定情况下的存储过程、或function、或trigger的调用和触发无法被正确复制的问题
  • 缺点:会产生大量的日志,尤其是alter table的时候会让日志暴涨
  •  MIXED
  • 基于STATMENT和ROW两种模式的混合复制(mixed-based replication, MBR),一般的复制使用STATEMENT模式保存binlog,对于STATEMENT模式无法复制的操作使用ROW模式保存binlog

二、redo log

1.为什么需要redo log

  •  我们都知道,事务的四大特性里面有一个是持久性,具体来说就是只要事务提交成功,那么对数据库做的修改就被永久保存下来了,不可能因为任何原因再回到原来的状态
  •  那么mysql是如何保证一致性的呢?最简单的做法是在每次事务提交的时候,将该事务涉及修改的数据页全部刷新到磁盘中
  •  但是这么做会有严重的性能问题,主要体现在两个方面:
  • 因为Innodb是以页为单位进行磁盘交互的,而一个事务很可能只修改一个数据页里面的几个字节,这个时候将完整的数据页刷到磁盘的话,太浪费资源了!
  • 一个事务可能涉及修改多个数据页,并且这些数据页在物理上并不连续,使用随机IO写入性能太差!

因此mysql设计了redo log,具体来说就是只记录事务对数据页做了哪些修改,这样就能完美地解决性能问题了(相对而言文件更小并且是顺序IO)。

2.redo log基本概念

  •  redo log包括两部分:一个是内存中的日志缓冲(redo log buffer),另一个是磁盘上的日志文件(redo log file)。
  •  mysql每执行一条DML语句,先将记录写入redo log buffer,后续某个时间点再一次性将多个操作记录写到redo log file。这种先写日志,再写磁盘的技术就是MySQL里经常说到的WAL(Write-Ahead Logging) 技术。
  •  在计算机操作系统中,用户空间(user space)下的缓冲区数据一般情况下是无法直接写入磁盘的,中间必须经过操作系统内核空间(kernel space)缓冲区(OS Buffer)
  •  因此,redo log buffer写入redo log file实际上是先写入OS Buffer,然后再通过系统调用fsync()将其刷到redo log file中,过程如下:
    在这里插入图片描述
  • mysql支持三种将redo log buffer写入redo log file的时机,可以通过innodb_flush_log_at_trx_commit参数配置,各参数值含义如下
    在这里插入图片描述

在这里插入图片描述

3.redo log记录形式

  •  前面说过,redo log实际上记录数据页的变更,而这种变更记录是没必要全部保存,因此redo log实现上采用了大小固定,循环写入的方式,当写到结尾时,会回到开头循环写日志。如下图:
    在这里插入图片描述
  • 同时我们很容易得知,在innodb中,既有redo log需要刷盘,还有数据页也需要刷盘,redo log存在的意义主要就是降低对数据页刷盘的要求
  • 在上图中,write pos表示redo log当前记录的LSN(逻辑序列号)位置,check point表示数据页更改记录刷盘后对应redo log所处的LSN(逻辑序列号)位置。
  • write pos到check point之间的部分是redo log空着的部分,用于记录新的记录
  • check point到write pos之间是redo log待落盘的数据页更改记录
  • 当write pos追上check point时,会先推动check point向前移动,空出位置再记录新的日志。
  • 启动innodb的时候,不管上次是正常关闭还是异常关闭,总是会进行恢复操作。因为redo log记录的是数据页的物理变化,因此恢复的时候速度比逻辑日志(如binlog)要快很多。
  • 重启innodb时,首先会检查磁盘中数据页的LSN,如果数据页的LSN小于日志中的LSN,则会从checkpoint开始恢复。
  • 还有一种情况,在宕机前正处于checkpoint的刷盘过程,且数据页的刷盘进度超过了日志页的刷盘进度,此时会出现数据页中记录的LSN大于日志中的LSN,这时超出日志进度的部分将不会重做,因为这本身就表示已经做过的事情,无需再重做。
    在这里插入图片描述

4.redo log与binlog区别

  •  由binlog和redo log的区别可知:binlog日志只用于归档,只依靠binlog是没有crash-safe能力的。
  •  但只有redo log也不行,因为redo log是InnoDB特有的,且日志上的记录落盘后会被覆盖掉。因此需要binlog和redo log二者同时记录,才能保证当数据库发生宕机重启时,数据不会丢失。

三、undo log

数据库事务四大特性中有一个是原子性,具体来说就是 原子性是指对数据库的一系列操作,要么全部成功,要么全部失败,不可能出现部分成功的情况。

实际上,原子性底层就是通过undo log实现的。

  •  undo log主要记录了数据的逻辑变化,比如一条INSERT语句,对应一条DELETE的undo log,对于每个UPDATE语句,对应一条相反的UPDATE的undo log,这样在发生错误时,就能回滚到事务之前的数据状态

同时,undo log也是MVCC(多版本并发控制)实现的关键

四、主从复制的原理

1.什么是主从复制?

  •  主从复制,是用来建立一个和主数据库完全一样的数据库环境,称为从数据库;主数据库一般是准实时的业务数据库

2.主从复制的作用

  •  1、做数据的热备,作为后备数据库,主数据库服务器故障后,可切换到从数据库继续工作,避免数据丢失
  •  2、架构的扩展。业务量越来越大,I/O访问频率过高,单机无法满足,此时做多库的存储,降低磁盘I/O访问的频率,提高单个机器的I/O性能。
  •  3、读写分离,使数据库能支撑更大的并发。在报表中尤其重要。由于部分报表sql语句非常的慢,导致锁表,影响前台服务。如果前台使用master,报表使用slave,那么报表sql将不会造成前台锁,保证了前台速度。

3.主从复制的原理

  •  数据库有个bin-log二进制文件,记录了所有sql语句
  •  我们的目标就是把主数据库的bin-log文件的sql语句复制过来
  •  让其在从数据的relay-log重做日志文件中再执行一次这些sql语句即可
  •  下面的主从配置就是围绕这个原理配置
  •  具体需要三个线程来操作:
  • binlog输出线程:每当有从库连接到主库的时候,主库都会创建一个线程然后发送binlog内容到从库

在从库里,当复制开始的时候,从库就会创建两个线程进行处理:

  • 从库I/O线程:当START SLAVE语句在从库开始执行之后,从库创建一个I/O线程,该线程连接到主库并请求主库发送binlog里面的更新记录到从库上。从库I/O线程读取主库的binlog输出线程发送的更新并拷贝这些更新到本地文件,其中包括relay log文件。
  • 从库的SQL线程:从库创建一个SQL线程,这个线程读取从库I/O线程写到relay log的更新事件并执行

可以知道,对于每一个主从复制的连接,都有三个线程拥有多个从库的主库为每一个连接到主库的从库创建一个binlog输出线程,每一个从库都有它自己的I/O线程和SQL线程

在这里插入图片描述
在这里插入图片描述

4.总结

  • 步骤一:主库db的更新事件(update、insert、delete)被写到binlog
  • 步骤二:从库发起连接,连接到主库
  • 步骤三:此时主库创建一个binlog dump thread线程,把binlog的内容发送到从库
  • 步骤四:从库启动之后,创建一个I/O线程,读取主库传过来的binlog内容并写入到relay log.
  • 步骤五:还会创建一个SQL线程,从relay log里面读取内容,从Exec_Master_Log_Pos位置开始执行读取到的更新事件,将更新内容写入到slave的db.
0

评论区