MySQL架构原理(三)线程模型和文件模型

2021/7/10 2:06:54

本文主要是介绍MySQL架构原理(三)线程模型和文件模型,对大家解决编程问题具有一定的参考价值,需要的程序猿们随着小编来一起学习吧!

InnoDB线程模型

在这里插入图片描述

  • IO Thread
    在InnoDB中使用了大量的AIO(Async IO)来做读写处理,这样可以极大提高数据库的性能。在InnoDB1.0版本之前共有4个IO Thread,分别是write,read,insert buffer和log thread,后来版本将read thread和write thread分别增大到了4个,一共有10个了。

    • read thread : 负责读取操作,将数据从磁盘加载到缓存page页。4个
  • write thread:负责写操作,将缓存脏页刷新到磁盘。4个

    • log thread:负责将日志缓冲区内容刷新到磁盘。1个

    • insert buffer thread :负责将写缓冲内容刷新到磁盘。1个

  • Purge Thread
    事务提交之后,其使用的undo日志将不再需要,因此需要Purge Thread回收已经分配的undo页。
    show variables like '%innodb_purge_threads%';

  • Page Cleaner Thread
    作用是将脏数据刷新到磁盘,脏数据刷盘后相应的redo log也就可以覆盖,即可以同步数据,又能达到redo log循环使用的目的。会调用write thread线程处理。
    show variables like '%innodb_page_cleaners%';

  • Master Thread
    Master thread是InnoDB的主线程,负责调度其他各线程,优先级最高。作用是将缓冲池中的数据异步刷新到磁盘 ,保证数据的一致性。包含:脏页的刷新(page cleaner thread)、undo页回收(purge thread)、redo日志刷新(log thread)、合并写缓冲等。内部有两个主处理,分别是每隔1秒和10秒处理。
    每1秒的操作:

    • 刷新日志缓冲区,刷到磁盘
    • 合并写缓冲区数据,根据IO读写压力来决定是否操作
    • 刷新脏页数据到磁盘,根据脏页比例达到75%才操作(innodb_max_dirty_pages_pct,innodb_io_capacity)

    每10秒的操作:

    • 刷新脏页数据到磁盘

    • 合并写缓冲区数据

    • 刷新日志缓冲区

    • 删除无用的undo页

InnoDB数据文件

一、InnoDB文件存储结构

在这里插入图片描述
InnoDB数据文件存储结构:
分为一个ibd数据文件–>Segment(段)–>Extent(区)–>Page(页)–>Row(行)

  • Tablesapce
    表空间,用于存储多个ibd数据文件,用于存储表的记录和索引。一个文件包含多个段。

  • Segment
    段,用于管理多个Extent,分为数据段(Leaf node segment)、索引段(Non-leaf nodesegment)、回滚段(Rollback segment)。一个表至少会有两个segment,一个管理数据,一个管理索引。每多创建一个索引,会多两个segment。

  • Extent
    区,一个区固定包含64个连续的页,大小为1M。当表空间不足,需要分配新的页资源,不会一页一页分,直接分配一个区。

  • Page
    页,用于存储多个Row行记录,大小为16K。包含很多种页类型,比如数据页,undo页,系统页,事务数据页,大的BLOB对象页。

  • Row
    行,包含了记录的字段值,事务ID(Trx id)、滚动指针(Roll pointer)、字段指针(Fieldpointers)等信息。

Page是文件最基本的单位,无论何种类型的page,都是由page header,page trailer和pagebody组成。如下图所示,

在这里插入图片描述

二、InnoDB文件存储格式

  • 通过 SHOW TABLE STATUS 命令
    在这里插入图片描述

一般情况下,如果row_format为REDUNDANT、COMPACT,文件格式为Antelope;如果row_format为DYNAMIC和COMPRESSED,文件格式为Barracuda。

  • 通过 information_schema 查看指定表的文件格式
    select * from information_schema.innodb_sys_tables;	
    

三、File文件格式(File-Format)

  在早期的InnoDB版本中,文件格式只有一种,随着InnoDB引擎的发展,出现了新文件格式,用于支持新的功能。目前InnoDB只支持两种文件格式:Antelope 和 Barracuda。

  • Antelope: 先前未命名的,最原始的InnoDB文件格式,它支持两种行格式:COMPACT和REDUNDANT,MySQL 5.6及其以前版本默认格式为Antelope。

  • Barracuda: 新的文件格式。它支持InnoDB的所有行格式,包括新的行格式:COMPRESSED和 DYNAMIC。

通过innodb_file_format 配置参数可以设置InnoDB文件格式,之前默认值为Antelope,5.7版本开始改为Barracuda。
在这里插入图片描述

四、Row行格式(Row_format)

  表的行格式决定了它的行是如何物理存储的,这反过来又会影响查询和DML操作的性能。如果在单个page页中容纳更多行,查询和索引查找可以更快地工作,缓冲池中所需的内存更少,写入更新时所需的I/O更少。
  InnoDB存储引擎支持四种行格式:REDUNDANT、COMPACT、DYNAMIC和COMPRESSED。
在这里插入图片描述
  DYNAMIC和COMPRESSED新格式引入的功能有:数据压缩、增强型长列数据的页外存储和大索引前缀。

  每个表的数据分成若干页来存储,每个页中采用B树结构存储;

  如果某些字段信息过长,无法存储在B树节点中,这时候会被单独分配空间,此时被称为溢出页,该字段被称为页外列。

  • REDUNDANT 行格式
    使用REDUNDANT行格式,表会将变长列值的前768字节存储在B树节点的索引记录中,其余的存储在溢出页上。对于大于等于786字节的固定长度字段InnoDB会转换为变长字段,以便能够在页外存储。

  • COMPACT 行格式
    与REDUNDANT行格式相比,COMPACT行格式减少了约20%的行存储空间,但代价是增加了某些操作的CPU使用量。如果系统负载是受缓存命中率和磁盘速度限制,那么COMPACT格式可能更快。如果系统负载受到CPU速度的限制,那么COMPACT格式可能会慢一些。

  • DYNAMIC 行格式
    使用DYNAMIC行格式,InnoDB会将表中长可变长度的列值完全存储在页外,而索引记录只包含指向溢出页的20字节指针。大于或等于768字节的固定长度字段编码为可变长度字段。DYNAMIC行格式支持大索引前缀,最多可以为3072字节,可通过innodb_large_prefix参数控制。

  • COMPRESSED 行格式
    COMPRESSED行格式提供与DYNAMIC行格式相同的存储特性和功能,但增加了对表和索引数据压缩的支持。

  在创建表和索引时,文件格式都被用于每个InnoDB表数据文件(其名称与*.ibd匹配)。修改文件格式的方法是重新创建表及其索引,最简单方法是对要修改的每个表使用以下命令:

ALTER TABLE 表名 ROW_FORMAT=格式类型;

Undo Log

Undo Log介绍

  Undo: 意为撤销或取消,以撤销操作为目的,返回指定某个状态的操作。

  Undo Log: 数据库事务开始之前,会将要修改的记录存放到 Undo 日志里,当事务回滚时或者数据库崩溃时,可以利用 Undo 日志,撤销未提交事务对数据库产生的影响。

  Undo Log产生和销毁: Undo Log在事务开始前产生;事务在提交时,并不会立刻删除undolog,innodb会将该事务对应的undo log放入到删除列表中,后面会通过后台线程purge thread进行回收处理。Undo Log属于逻辑日志,记录一个变化过程。例如执行一个delete,undolog会记录一个insert;执行一个update,undolog会记录一个相反的update。

  Undo Log存储: undo log采用段的方式管理和记录。在innodb数据文件中包含一种rollbacksegment回滚段,内部包含1024个undo log segment。可以通过下面一组参数来控制Undo log存储。

show variables like '%innodb_undo%';

在这里插入图片描述
innodb_undo_logs,128 128 日志文件大小128k
innodb_undo_tablespaces,0 0表示使用系统表空间 大于0表示使用独立表空间,2表示可以存储两个文件

3.5.2 Undo Log作用

  • 实现事务的原子性
    Undo Log 是为了实现事务的原子性而出现的产物。事务处理过程中,如果出现了错误或者用户执行了 ROLLBACK 语句,MySQL 可以利用 Undo Log 中的备份将数据恢复到事务开始之前的状态。

  • 实现多版本并发控制(MVCC)
    Undo Log 在 MySQL InnoDB 存储引擎中用来实现多版本并发控制。事务未提交之前,Undo Log保存了未提交之前的版本数据,Undo Log 中的数据可作为数据旧版本快照供其他并发事务进行快照读。
    在这里插入图片描述
    事务A手动开启事务,执行更新操作,首先会把更新命中的数据备份到 Undo Buffer 中。
    事务B手动开启事务,执行查询操作,会读取 Undo 日志数据返回,进行快照读

Redo Log和Binlog

Redo Log和Binlog是MySQL日志系统中非常重要的两种机制,也有很多相似之处,下面介绍下两者细节和区别。

Redo Log日志

  • Redo Log介绍
    Redo: 顾名思义就是重做。以恢复操作为目的,在数据库发生意外时重现操作。

    Redo Log: 指事务中修改的任何数据,将最新的数据备份存储的位置(Redo Log),被称为重做日志。

    Redo Log 的生成和释放: 随着事务操作的执行,就会生成Redo Log,在事务提交时会将产生Redo Log写入Log Buffer,并不是随着事务的提交就立刻写入磁盘文件。等事务操作的脏页写入到磁盘之后,Redo Log 的使命也就完成了,Redo Log占用的空间就可以重用(被覆盖写入)。

  • Redo Log工作原理
    Redo Log 是为了实现事务的持久性而出现的产物。防止在发生故障的时间点,尚有脏页未写入表的 IBD 文件中,在重启 MySQL 服务的时候,根据 Redo Log 进行重做,从而达到事务的未入磁盘数据进行持久化这一特性。

在这里插入图片描述

  • Redo Log写入机制
    Redo Log 文件内容是以顺序循环的方式写入文件,写满时则回溯到第一个文件,进行覆盖写。
    在这里插入图片描述

如图所示:

  • write pos 是当前记录的位置,一边写一边后移,写到最后一个文件末尾后就回到 0 号文件开头;

  • checkpoint 是当前要擦除的位置,也是往后推移并且循环的,擦除记录前要把记录更新到数据文件;

write pos 和 checkpoint 之间还空着的部分,可以用来记录新的操作。如果 write pos 追上checkpoint,表示写满,这时候不能再执行新的更新,得停下来先擦掉一些记录,把 checkpoint推进一下。

  • Redo Log相关配置参数
    每个InnoDB存储引擎至少有1个重做日志文件组(group),每个文件组至少有2个重做日志文件,默认为ib_logfile0和ib_logfile1。可以通过下面一组参数控制Redo Log存储:
show variables like '%innodb_log%';

Redo Buffer 持久化到 Redo Log 的策略,可通过 Innodb_flush_log_at_trx_commit 设置:

  • 0:每秒提交 Redo buffer ->OS cache -> flush cache to disk,可能丢失一秒内的事务数据。由后台Master线程每隔 1秒执行一次操作,事务提交先到redobuffer,再由master线程一秒刷一次。

  • 1(默认值):每次事务提交执行 Redo Buffer -> OS cache -> flush cache to disk,最安全,性能最差的方式。

  • 2:每次事务提交执行 Redo Buffer -> OS cache,然后由后台Master线程再每隔1秒执行OScache -> flush cache to disk 的操作,每次事务执行的时候会直接提从redobuffer提交OScache中,后续再由master线程执行flush。

一般建议选择取值2,因为 MySQL 挂了数据没有损失,整个服务器挂了才会损失1秒的事务提交数据。

在这里插入图片描述

Binlog日志

  • Binlog记录模式
    Redo Log 是属于InnoDB引擎所特有的日志,而MySQL Server也有自己的日志,即 Binarylog(二进制日志),简称Binlog。Binlog是记录所有数据库表结构变更以及表数据修改的二进制日志,不会记录SELECT和SHOW这类操作。Binlog日志是以事件形式记录,还包含语句所执行的消耗时间。开启Binlog日志有以下两个最重要的使用场景。

    • 主从复制:在主库中开启Binlog功能,这样主库就可以把Binlog传递给从库,从库拿到Binlog后实现数据恢复达到主从数据一致性。

    • 数据恢复:通过mysqlbinlog工具来恢复数据。

    Binlog文件名默认为“主机名_binlog-序列号”格式,例如oak_binlog-000001,也可以在配置文件中指定名称。文件记录模式有STATEMENTROW和MIXED三种,具体含义如下。

    • ROW(row-based replication, RBR):日志中会记录每一行数据被修改的情况,然后在slave端对相同的数据进行修改。
      优点:能清楚记录每一个行数据的修改细节,能完全实现主从数据同步和数据的恢复。
      缺点:批量操作,会产生大量的日志,尤其是alter table会让日志暴涨。

    • STATMENT(statement-based replication, SBR):每一条被修改数据的SQL都会记录到master的Binlog中,slave在复制的时候SQL进程会解析成和原来master端执行过的相同的SQL再次执行。简称SQL语句复制。
      优点:日志量小,减少磁盘IO,提升存储和恢复速度
      缺点:在某些情况下会导致主从数据不一致,比如last_insert_id()、now()等函数。

    • MIXED(mixed-based replication, MBR):以上两种模式的混合使用,一般会使用
      STATEMENT模式保存binlog,对于STATEMENT模式无法复制的操作使用ROW模式保存binlog,MySQL会根据执行的SQL语句选择写入模式。

  • Binlog文件结构
    MySQL的binlog文件中记录的是对数据库的各种修改操作,用来表示修改操作的数据结构是Logevent。不同的修改操作对应的不同的log event。比较常用的log event有:Query event、Rowevent、Xid event等。binlog文件的内容就是各种Log event的集合。

Binlog文件中Log event结构如下图所示:
在这里插入图片描述

Binlog写入机制

  • 根据记录模式和操作触发event事件生成log event(事件触发执行机制)

  • 将事务执行过程中产生log event写入缓冲区,每个事务线程都有一个缓冲区Log Event保存在一个binlog_cache_mngr数据结构中,在该结构中有两个缓冲区,一个是stmt_cache,用于存放不支持事务的信息;另一个是trx_cache,用于存放支持事务的信息。

  • 事务在提交阶段会将产生的log event写入到外部binlog文件中。不同事务以串行方式将log event写入binlog文件中,所以一个事务包含的log event信息在binlog文件中是连续的,中间不会插入其他事务的log event。

    show variables like 'Innodb_flush_log_at_trx_commit';
    

Binlog文件操作

  • Binlog状态查看

    show variables like '%log_bin%';
    
  • 开启Binlog功能

    set global log_bin=mysqllogbin
    [2021-07-09 21:03:08] [HY000][1238] Variable 'log_bin' is a read only variable
    

    需要修改my.cnf或my.ini配置文件,在[mysqld]下面增加log_bin=mysql_bin_log,重启MySQL服务。

    	#log-bin=ON
    	#log-bin-basename=mysqlbinlog
    	binlog-format=ROW
    	log-bin=mysqlbinlog  #这里等于上面注释掉的两行
    
  • 使用show binlog events命令

    show binary logs; //等价于show master logs;
    show master status;
    show binlog events;
    show binlog events in 'mysqlbinlog.000001';
    
  • 使用mysqlbinlog 命令

    mysqlbinlog "文件名"
    mysqlbinlog "文件名" > "test.sql"
    ```* 使用 binlog 恢复数据
    ```shell
    //按指定时间恢复
    mysqlbinlog --start-datetime="2020-04-25 18:00:00" --stopdatetime="2020-04-26 00:00:00" mysqlbinlog.000002 | mysql -uroot -p1234
    //按事件位置号恢复
    mysqlbinlog --start-position=154 --stop-position=957 mysqlbinlog.000002| mysql -uroot -p1234
    

    mysqldump:定期全部备份数据库数据。mysqlbinlog可以做增量备份和恢复操作。

  • 删除Binlog文件

    purge binary logs to 'mysqlbinlog.000001'; //删除指定文件
    purge binary logs before '2020-04-28 00:00:00'; //删除指定时间之前的文件
    reset master; //清除所有文件
    

    可以通过设置expire_logs_days参数来启动自动清理功能。默认值为0表示没启用。设置为1表示超出1天binlog文件会自动删除掉。

Redo Log和Binlog区别

  • Redo Log是属于InnoDB引擎功能,Binlog是属于MySQL Server自带功能,并且是以二进制文件记录。

  • Redo Log属于物理日志,记录该数据页更新状态内容,Binlog是逻辑日志,记录更新过程。

  • Redo Log日志是循环写,日志空间大小是固定,Binlog是追加写入,写完一个写下一个,不会覆盖使用。

  • Redo Log作为服务器异常宕机后事务数据自动恢复使用,Binlog可以作为主从复制和数据恢复使用。Binlog没有自动crash-safe能力。



这篇关于MySQL架构原理(三)线程模型和文件模型的文章就介绍到这儿,希望我们推荐的文章对大家有所帮助,也希望大家多多支持为之网!


扫一扫关注最新编程教程