Innodb中的buffer poll和redo undo log

服务器

浏览数:240

2019-3-21

内存缓冲池

buffer pool,如果mysql不使用内存缓冲池,每次读取数据时,都需要访问磁盘,会大大的增加磁盘的IO请求,导致效率低下;在Innodb引擎在读取数据的时候,把相应的数据和索引载入到内存的缓冲池(buffer pool)中,一定程度的提高了数据的读写速度

buffer pool

占用大量内存,用来存放各种数据的缓存包括:索引页,数据页,undo页,插入缓冲,自适应哈希索引,innodb存储的锁信息,数据字典等。工作方式是将数据库文件按照页(每页16k)读取到缓冲池,然后按照最近最少使用算法(LRU)来保留缓冲池中的缓冲数据。如果数据库文件需要修改,总是首先修改在缓冲池中的页(发生修改后即成为脏页),然后在按照一定的频率将缓冲池中的脏页刷新到文件

表空间

表空间可以看作是InnoDB存储引擎逻辑结构的最高层。表空间文件:InnoDB默认的表空间文件为ibdata1

  • 页:每页数据为16kb,且不能进行修改。常见的页类型有:数据页,Undo页,系统页,事务数据页,插入缓冲位图页,插入缓冲空闲列表页,未压缩的二进制大对象页,压缩的二进制大对象页

  • 区:由64个连续的页组成,每个页大小为16kb,即每个区的大小为1024kb即1MB

  • 段:表空间由各个段组成,常见的段有数据段,索引段,回滚段(undo log段)等

redo log和undo log

mysql中的原则是日志先行。为了满足事务的持久性,防止buffer pool数据丢失,innodb引入了redo log。为了满足事务的原子性,innodb引入了undo log

redo log

redo log就是保存执行的SQL语句到一个指定的log文件,当mysql进行数据恢复的时候,重新执行redo log记录的SQL操作即可。引入buffer pool会导致更新的数据不会实时地将数据持久化到硬盘,当系统崩溃时,虽然buffer pool中的数据丢失,数据没有持久化。但是系统可以根据redo log的内容,将所有数据恢复到最新的状态。redo log在磁盘上作为一个独立的文件存在,默认情况下会有两个文件,名称分别为ib_logfile0ib_logfile1

innodb_additional_mem_pool_size = 100M
innodb_buffer_pool_size = 128M
innodb_data_home_dir = /home/mysql/local/mysql/var
innodb_data_file_path = ibdata1:1G:autoextend
innodb_file_io_threads = 4
innodb_thread_concurrency = 16
innodb_flush_log_at_trx_commit = 1
innodb_log_buffer_size = 8M
innodb_log_file_size = 128M
innodb_log_file_in_group = 2
innodb_log_group_home_dir = /home/mysql/local/mysql/var

redo log的记录内容

undo log和redo log本身是分开的。Innodb的undo log是记录在数据文件(ibd)中的,而且innodb将undo log的内容看做是数据,因此对undo log本身的操作(如向undo log插入一条undo log记录等),都会记录redo log。undo log可以不必立即持久化到磁盘上。即便丢失了,也可以通过redo log将其恢复。因此当插入一条记录时:

  • 向undo log插入一条undo log记录

  • 向redo log中插入一条“插入undo log记录”的redo log记录

  • 插入数据

  • 向redo log插入一条“insert”的redo log记录

在一个事务中插入数据的时候:

假设对两个字段A,B分别进行更新,初始值分别为1,3
begin
在undo log中记录A为1
更新A为2
记录A=2到redo log

在undo log中记录B为3
更新B为4
记录B=4到redo log

将redo log写入到磁盘
commit

redo log的io性能

为了保证redo log能够有很好的io性能,innodb的redo log的设计有以下几个特点:

  • 尽量保持redo log存储在一段连续的空间上。因此在系统第一次启动时就会将日志文件的空间完全分配。以顺序追加的方式记录redo log

  • 批量写入日志。日志并不是直接写入到文件,而是先写入redo log buffer,然后每秒钟将buffer中数据一并写入磁盘

  • 并发的事务共享redo log的存储空间,他们的redo log按语句的执行顺序,依次交替的记录在一起,以减少日志占用的空间

  • redo log上只进行顺序追加的操作,当一个事务需要回滚时,它的redo log记录也不会从redo log中删除

undo log

为了满足事务的原子性,在操作任何数据之前,首先将数据备份到undo log,然后进行数据的修改。如果出现了错误或者用户手动执行了rollback,系统可以利用undo log中的备份将数据恢复到事务开始之前的状态。与redo log不同的是,磁盘上不存在单独的undo log 文件,他存放在数据库内部的特殊段(segment)中,这称之为undo段(undo segment),undo段位于共享表空间内
Innodb为每行undo log记录都实现了三个隐藏字段:

  • 6字节的事务ID(DB_TRX_ID)

  • 7字节的回滚指针(DB_ROLL_PTR)

  • 隐藏的ID

redo log和undo log

  • 数据持久化

  1. pool中维护一个按脏页修改先后顺序排列的链表,叫flush_list。根据flush_list中页的顺序刷数据到持久化存储。按页面最早一次被修改的顺序排列。正常情况下,dirty page刷新数据的时机为:

    1. 当redo空间占满时,将会将部分dirty page flush到disk上,然后释放部分redo log内容

    2. 当需要buffer pool分配一个page,但是已经满了,这时候必须flush dirty pages to disk。

    3. 检测到系统空闲的时候

  • 数据恢复
    随着时间积累,redo log会变得很大。如果每次都从第一条记录开始恢复,恢复过程会十分缓慢,从而无法被容忍。为了减少恢复的时间,就引入了checkpoint机制:假设在某个时间点,所有的脏页都被刷新到了磁盘上。这个时间点之前的所有redo log就不需要重做了。系统记录下这个时间点时redo log的结尾位置作为checkoutpoint。在进行恢复时,从这个checkpoint的位置开始即可。checkpoint点之前的日志就不再需要了,可以被删除掉