Innodb检查点和redo写盘时机

本文涉及的产品
云数据库 RDS MySQL,集群系列 2核4GB
推荐场景:
搭建个人博客
RDS MySQL Serverless 基础系列,0.5-2RCU 50GB
RDS MySQL Serverless 高可用系列,价值2615元额度,1个月
简介:

我的学习记录,可能有误请谅解,提供了一些源码接口供有兴趣的朋友调试。

版本:5.7.17

一、LSN

innodb的lsn和oracle的scn一样,是一个重要的概念。是整个数据库数据同步的一种统一辨别标准,在很多地方都使用到了LSN比如

  • 在flush list中正是是使用page的oldest lsn作为链表的条件
    参考buf_page_t类中的 lsn_t oldest_modification;变量
  • 在checkpoint中记录的也是lsn
    参考宏 LOG_CHECKPOINT_LSN
  • 在物理文件中每个page最后的刷新lsn
    参考宏FIL_PAGE_LSN
  • 在写日志落盘的时候也是以lsn为标准的
    参考函数log_write_up_to

实际上lsn就是表示的日志量的字节数,是一个累加的值,在5.7中表现为:

/* Type used for all log sequence number storage and arithmetics */
typedef    ib_uint64_t        lsn_t;

及一个8字节非负的整数。最大值及2的64次方。有了这种物理上概念,lsn很容易换算为当前日志的偏移量。

二、innodb中检查点的理解

这里我只讨论正常运行的情况下检查点。innodb中类似oracle的增量检查点。正常运行checkpoint是由master线程触发。我们知道脏数据通过page clean线程和lru manager线程是在不断写盘的,那么在进行异常重启的的时候我们必须要知道一个恢复的起点,但是这个起点是不能记录在内存中必要固化到磁盘,恢复的时候读取这个点以后的redo进行恢复,而checkpoint就是完成这个事情下面是checkpoint的执行流程。

正常情况下master线程会每秒进行检查点其作用有(参考log_checkpoint函数):

  • 检查是否有自上次检查点以来的脏数据写盘了。
  • 如果有则在redo里面会为每个修改过的文件写入MLOG_FILE_NAME,完成后写入一个总MLOG_CHECKPOINT(参考fil_names_clear函数)。
    1、MLOG_FILE_NAME主要记录至上次检查点以来更改过的数据文件。

2、MLOG_CHECKPOINT主要记录检查点的lsn。
这个步骤会遍历fil_system->named_spaces用于查找是否有自上次检查点以来修改过的文件链表。

  • 如果有则在redo log header中写入相应的检查点信息包含(异步写)。

实际上我们可以理解检查点就是由master线程每秒醒来查看一下脏数据写到哪里了,然后将其记录到合适的位置,以备carsh recovery使用。(参考srv_master_thread函数)

三、show engine innodb中的检查点信息

下面是一个没有任何更新操作的库的信息如下:

Log sequence number 697794162
Log flushed up to   697794162
Pages flushed up to 697794162
Last checkpoint at  697794153
  • Log sequence number:已经写到log buffer中的lsn。
    参考mtr_t::Command::finish_write函数。
  • Log flushed up to:已经写到日志文件的redo的lsn。
    参考log_write_flush_to_disk_low函数。
  • Pages flushed up to :此lsn之前的脏数据都已经写到了数据文件。
    参考log_buf_pool_get_oldest_modification函数。
  • Last checkpoint at :最后一次检查点记录到了什么位置。
    参考next_checkpoint_lsn函数。

下面是这段输出的源码:

    fprintf(file,
        "Log sequence number " LSN_PF "\n"
        "Log flushed up to   " LSN_PF "\n"
        "Pages flushed up to " LSN_PF "\n"
        "Last checkpoint at  " LSN_PF "\n",
        log_sys->lsn,
        log_sys->flushed_to_disk_lsn,
        log_buf_pool_get_oldest_modification(),
        log_sys->last_checkpoint_lsn);

一般来讲Log sequence number >Log flushed up to> Pages flushed up to>Last checkpoint at ,但是这里注意一下。Pages flushed up to 697794162和Last checkpoint at 697794153,显然这里是一个没有任何操作的库所以Pages flushed up to应该和Last checkpoint at 相等,但是这里存在差值,差值为:

  • 697794162-697794153 = 9

这刚好是MLOG_CHECKPOINT的长度源码片段如下:

oldest_lsn <= log_sys->last_checkpoint_lsn + SIZE_OF_MLOG_CHECKPOINT 

/** Size of a MLOG_CHECKPOINT record in bytes.
The record consists of a MLOG_CHECKPOINT byte followed by
mach_write_to_8(checkpoint_lsn). */
#define SIZE_OF_MLOG_CHECKPOINT    9

四、我所debug的几种redo写盘的时机

  • master 线程每秒调用 栈帧(可能是idle可能是active 和检测是否需要插入缓存合并有关)
#0  log_group_write_buf (group=0x33f29f8, buf=0x7fffa5b38000 "\200\024", len=512, pad_len=0, start_lsn=697764864, new_data_offset=166)
    at /root/mysql5.7.14/percona-server-5.7.14-7/storage/innobase/log/log0log.cc:1145
#1  0x0000000001a50f95 in log_write_up_to (lsn=697765068, flush_to_disk=true) at /root/mysql5.7.14/percona-server-5.7.14-7/storage/innobase/log/log0log.cc:1493
#2  0x0000000001a51163 in log_buffer_sync_in_background (flush=true) at /root/mysql5.7.14/percona-server-5.7.14-7/storage/innobase/log/log0log.cc:1553
#3  0x0000000001b84bd1 in srv_sync_log_buffer_in_background () at /root/mysql5.7.14/percona-server-5.7.14-7/storage/innobase/srv/srv0srv.cc:2312
#4  0x0000000001b85666 in srv_master_do_idle_tasks () at /root/mysql5.7.14/percona-server-5.7.14-7/storage/innobase/srv/srv0srv.cc:2586
#5  0x0000000001b85b6b in srv_master_thread (arg=0x0) at /root/mysql5.7.14/percona-server-5.7.14-7/storage/innobase/srv/srv0srv.cc:2744
  • master 线程每秒checkpoint调用 (可能是idle可能是active 和检测是否需要插入缓存合并有关)
#0  log_group_write_buf (group=0x33f29f8, buf=0x7fffa5a38000 "\200\024\002", len=1024, pad_len=0, start_lsn=697789952, new_data_offset=139)
    at /root/mysql5.7.14/percona-server-5.7.14-7/storage/innobase/log/log0log.cc:1145
#1  0x0000000001a50f95 in log_write_up_to (lsn=697790725, flush_to_disk=true) at /root/mysql5.7.14/percona-server-5.7.14-7/storage/innobase/log/log0log.cc:1493
#2  0x0000000001a52247 in log_checkpoint (sync=true, write_always=false) at /root/mysql5.7.14/percona-server-5.7.14-7/storage/innobase/log/log0log.cc:1934
#3  0x0000000001b856f2 in srv_master_do_idle_tasks () at /root/mysql5.7.14/percona-server-5.7.14-7/storage/innobase/srv/srv0srv.cc:2596
#4  0x0000000001b85b6b in srv_master_thread (arg=0x0) at /root/mysql5.7.14/percona-server-5.7.14-7/storage/innobase/srv/srv0srv.cc:2744
  • page clean 线程调用 栈帧
#0  log_group_write_buf (group=0x33f29f8, buf=0x7fffa5a38000 "\200\024\002", len=13312, pad_len=1024, start_lsn=697778176, new_data_offset=468)
    at /root/mysql5.7.14/percona-server-5.7.14-7/storage/innobase/log/log0log.cc:1145
#1  0x0000000001a50f95 in log_write_up_to (lsn=697790015, flush_to_disk=true) at /root/mysql5.7.14/percona-server-5.7.14-7/storage/innobase/log/log0log.cc:1493
#2  0x0000000001c704c7 in buf_flush_write_block_low (bpage=0x7fffc0cae940, flush_type=BUF_FLUSH_LIST, sync=false)
    at /root/mysql5.7.14/percona-server-5.7.14-7/storage/innobase/buf/buf0flu.cc:1035
#3  0x0000000001c70cea in buf_flush_page (buf_pool=0x33247d8, bpage=0x7fffc0cae940, flush_type=BUF_FLUSH_LIST, sync=false)
    at /root/mysql5.7.14/percona-server-5.7.14-7/storage/innobase/buf/buf0flu.cc:1237
#4  0x0000000001c717f4 in buf_flush_try_neighbors (page_id=..., flush_type=BUF_FLUSH_LIST, n_flushed=0, n_to_flush=25)
    at /root/mysql5.7.14/percona-server-5.7.14-7/storage/innobase/buf/buf0flu.cc:1466
  • 当前线程commit 调用栈帧如下:
#0  log_group_write_buf (group=0x33f29f8, buf=0x7fffa5a38000 "\200\024\002", len=2560, pad_len=0, start_lsn=697762816, new_data_offset=230)
    at /root/mysql5.7.14/percona-server-5.7.14-7/storage/innobase/log/log0log.cc:1145
#1  0x0000000001a50f95 in log_write_up_to (lsn=697765030, flush_to_disk=true) at /root/mysql5.7.14/percona-server-5.7.14-7/storage/innobase/log/log0log.cc:1493
#2  0x0000000001a51087 in log_buffer_flush_to_disk (sync=true) at /root/mysql5.7.14/percona-server-5.7.14-7/storage/innobase/log/log0log.cc:1524
#3  0x00000000019a9157 in innobase_flush_logs (hton=0x2e9fdd0, binlog_group_flush=true)
    at /root/mysql5.7.14/percona-server-5.7.14-7/storage/innobase/handler/ha_innodb.cc:4407
#4  0x0000000000f65893 in flush_handlerton (thd=0x0, plugin=0x7ffff03588e8, arg=0x7ffff0358944) at /root/mysql5.7.14/percona-server-5.7.14-7/sql/handler.cc:2606
#5  0x00000000015d7716 in plugin_foreach_with_mask (thd=0x0, func=0xf65835 <flush_handlerton(THD*, plugin_ref, void*)>, type=1, state_mask=4294967287, 
    arg=0x7ffff0358944) at /root/mysql5.7.14/percona-server-5.7.14-7/sql/sql_plugin.cc:2318
#6  0x0000000000f658ef in ha_flush_logs (db_type=0x0, binlog_group_flush=true) at /root/mysql5.7.14/percona-server-5.7.14-7/sql/handler.cc:2617
#7  0x000000000185733d in MYSQL_BIN_LOG::process_flush_stage_queue (this=0x2e02c80, total_bytes_var=0x7ffff0358a88, rotate_var=0x7ffff0358a87, 
    out_queue_var=0x7ffff0358a78) at /root/mysql5.7.14/percona-server-5.7.14-7/sql/binlog.cc:8541
#8  0x000000000185899f in MYSQL_BIN_LOG::ordered_commit (this=0x2e02c80, thd=0x7fff2c000b70, all=false, skip_commit=false)
    at /root/mysql5.7.14/percona-server-5.7.14-7/sql/binlog.cc:9189
#9  0x000000000185700c in MYSQL_BIN_LOG::commit (this=0x2e02c80, thd=0x7fff2c000b70, all=false) at /root/mysql5.7.14/percona-server-5.7.14-7/sql/binlog.cc:8440
#10 0x0000000000f63df8 in ha_commit_trans (thd=0x7fff2c000b70, all=false, ignore_global_read_lock=false)
  • innodb shutdown(未debug)
  • redo buffer不足(未debug)

作者微信:
微信.jpg

相关实践学习
如何快速连接云数据库RDS MySQL
本场景介绍如何通过阿里云数据管理服务DMS快速连接云数据库RDS MySQL,然后进行数据表的CRUD操作。
全面了解阿里云能为你做什么
阿里云在全球各地部署高效节能的绿色数据中心,利用清洁计算为万物互联的新世界提供源源不断的能源动力,目前开服的区域包括中国(华北、华东、华南、香港)、新加坡、美国(美东、美西)、欧洲、中东、澳大利亚、日本。目前阿里云的产品涵盖弹性计算、数据库、存储与CDN、分析与搜索、云通信、网络、管理与监控、应用服务、互联网中间件、移动服务、视频服务等。通过本课程,来了解阿里云能够为你的业务带来哪些帮助 &nbsp; &nbsp; 相关的阿里云产品:云服务器ECS 云服务器 ECS(Elastic Compute Service)是一种弹性可伸缩的计算服务,助您降低 IT 成本,提升运维效率,使您更专注于核心业务创新。产品详情: https://www.aliyun.com/product/ecs
相关文章
|
7月前
|
存储 SQL 关系型数据库
MySQL之深入InnoDB存储引擎——redo日志
我们知道数据的修改首先是在Buffer Pool中进行的,之后再定时刷到磁盘中。那么如果在事务提交后还没刷新到磁盘中,系统就崩溃了,那么此时数据就丢失了,这就不满足事务的持久性了。而如果我们考虑每次提交之后,都同步将事务中所有的页面刷新到磁盘,这样确实可以保证持久性,但是这种方法存在以下两种问题:
|
存储 关系型数据库 MySQL
庖丁解InnoDB之REDO LOG
磁盘数据库为了在保证数据库的原子性(A, Atomic) 和持久性(D, Durability)的同时,还能以灵活的刷盘策略来充分利用磁盘顺序写的性能,会记录REDO和UNDO日志,即ARIES方法。本文将重点介绍REDO LOG的作用,记录的内容,组织结构,写入方式等内容,希望读者能够更全面准确的理解REDO LOG在InnoDB中的位置。本文基于MySQL 8.0代码。
1003 1
庖丁解InnoDB之REDO LOG
|
存储 关系型数据库 MySQL
InnoDB存储引擎的redo log(重做日志)
InnoDB存储引擎的redo log(重做日志)
118 0
InnoDB存储引擎的redo log(重做日志)
|
存储 关系型数据库 MySQL
庖丁解InnoDB之REDO LOG
数据库故障恢复机制的前世今生一文中提到,今生磁盘数据库为了在保证数据库的原子性(A, Atomic) 和持久性(D, Durability)的同时,还能以灵活的刷盘策略来充分利用磁盘顺序写的性能,会记录REDO和UNDO日志,即ARIES方法。本文将重点介绍REDO LOG的作用,记录的内容,组织结构,写入方式等内容,希望读者能够更全面准确的理解REDO LOG在InnoDB中的位置。本文基于MySQL 8.0代码。
庖丁解InnoDB之REDO LOG
|
关系型数据库
InnoDB redo log thread cpu usage
InnoDB 在8.0 里面把写redo log 角色的各个线程都独立出来, 每一个thread 都处于wait 状态, 同样用户thread 调用log_write_up_to 以后, 也会进入wait 状态.这里的wait 等待最后都是通过调用 os_event_wait_for 来实现, 而 os_event_wait_for 是先spin + wait 的方式实现.所以这里有两个参数会影响os_event_wait_for 函数:spins_limit,timeout.
159 0
|
Oracle 关系型数据库 MySQL
新特性速递 | InnoDB redo log archiving(归档)
新特性速递 | InnoDB redo log archiving(归档)
336 0
|
存储 缓存 安全
庖丁解InnoDB之REDO LOG
本文将重点介绍REDO LOG的作用,记录的内容,组织结构,写入方式等内容,希望读者能够更全面准确的理解REDO LOG在InnoDB中的位置。
316 0
|
Oracle 关系型数据库 MySQL
新特性速递 | InnoDB redo log archiving(归档)
新特性速递 | InnoDB redo log archiving(归档)
|
SQL 存储 关系型数据库
MySQL · 引擎特性 · InnoDB redo log漫游
前言 InnoDB 有两块非常重要的日志,一个是undo log,另外一个是redo log,前者用来保证事务的原子性以及InnoDB的MVCC,后者用来保证事务的持久性。 和大多数关系型数据库一样,InnoDB记录了对数据文件的物理更改,并保证总是日志先行,也就是所谓的WAL,即在持久化数据文
9432 2