MySQL8.0 · 引擎特性 · 关于undo表空间的一些新变化

本文涉及的产品
RDS PostgreSQL Serverless,0.5-4RCU 50GB 3个月
推荐场景:
对影评进行热评分析
云数据库 RDS SQL Server,基础系列 2核4GB
云原生数据库 PolarDB 分布式版,标准版 2核8GB
简介: Note: 当前版本为MySQL8.0.3 InnoDB的undo log是其实现多版本的关键组件,在物理上以数据页的形式进行组织。在早期版本中(

Note: 当前版本为MySQL8.0.3

InnoDB的undo log是其实现多版本的关键组件,在物理上以数据页的形式进行组织。在早期版本中(<5.6),undo tablespace是在ibdata中,因此一个常见的问题是由于大事务不提交导致ibdata膨胀,这时候通常只有重建数据库一途来缩小空间。到了MySQL5.6版本, InnoDB开始支持独立的undo tablespace,也就是说,undo log可以存储于ibdata之外。但这个特性依然鸡肋:

  1. 首先你必须在install实例的时候就指定好独立Undo tablespace, 在install完成后不可更改。
  2. Undo tablepsace的space id必须从1开始,无法增加或者删除undo tablespace。

到了MySQL5.7版本中,终于引入了一个期待已久的功能:即在线truncate undo tablespace。DBA终于摆脱了undo空间膨胀的苦恼。

在MySQL8.0,InnoDB再进一步,对undo log做了进一步的改进:

  1. 无需从space_id 1开始创建undo tablespace,这样解决了In-place upgrade或者物理恢复到一个打开了Undo tablespace的实例所产生的space id冲突。不过依然要求undo tablespace的space id是连续分配的(fsp_is_undo_tablespace), space id的范围为(0xFFFFFFF0UL - 128, 0xFFFFFFF0UL - 1) (Bug #23517560)
  2. 从8.0.3版本开始,默认undo tablespace的个数从0调整为2,也就是在8.0版本中,独立undo tablespace被默认打开。修改该参数为0会报warning并在未来不再支持(WL#10583)
  3. 允许动态的增加undo tablespace的个数,也就是说可以动态调整innodb_undo_tablespaces。当调大该参数时,会去创建新的undo tablespace。但如果设小该值,则仅仅是不实用多出来的Undo tablespace,目前不会去主动删除它们(innodb_undo_tablespaces_update), WL#9507
  4. Undo tablespace的命名从undoNNN修改为undo_NNN
  5. 和以前版本最大的不同之处就是,在8.0之前只能创建128个回滚段,而在8.0版本开始,每个Undo tablespace可以创建128个回滚段,也就是说,总共有innodb_rollback_segments * innodb_undo_tablespaces个回滚段。这个改变的好处是在高并发下可以显著的减少因为分配到同一个回滚段内的事务间产生的锁冲突
  6. Innodb_undo_truncate参数默认打开,这意味着默认情况下,undo tablespace超过1GB(参数innodb_max_undo_log_size来控制)时,就会触发online truncate
  7. 支持undo tablespace加密( 参考文档)
  8. 在ibdata中保留的32个slot原本用于临时表空间的回滚段,但事实上他们并没有做任何的持久化,因此在8.0中直接在内存中为其创建单独的内存结构,这32个slot可以用于持久化的undo回滚段(Bug #24462978)!

主要代码commit(按照时间顺序由新到旧):

Commit 1

    WL#10583: Stop using rollback segments in the system tablespace

    * Change the minimum value of innodb_undo_tablespaces to 2
    * Fix code that allows and checks for innodb_undo_tablespaces=0
    * Fix all testcases affected

commit 2

    WL#9507: Make innodb_undo_tablespaces variable dynamic
    WL#10498: InnoDB: Change Default for innodb_undo_tablespaces from 0 to 2
    WL#10499: InnoDB: Change Default for innodb_undo_log_truncate from OFF to ON

    * Introduce innodb_undo_tablespace_update() and
    srv_undo_tablespaces_update() for online updates.
    * Introduce innodb_rollback_segments_update() for online updates.
    * Introduce srv_undo_tablespaces_uprade() to convert 5.7 undo
    tablespaces to 8.0.1.
    * Introduce srv_undo_tablespaces_downgrade() in case the upgrade from
      5.7 fails.
    * Introduce trx_rseg_adjust_rollback_segments() and
    trx_rseg_add_rollback_segments() to consolidate the creation and use of
    rollback segments in any tablespace.
    * Introduce a new file format for undo tablespaces including a reserved
    range for undo space IDs and an RSEG_ARRAY page.
    * Rename auto-generated undo tablespace names from undonnn to undo-nnn
    * Expand the undo namespace to support new undo file format.
    * Various changes to allow online creation of undo spaces and rollback
    segments.
    * Change round robin routine for supplying rsegs to transactions to
    support rseg arrays in each tablespace.
    * Handle conversions between undo space_id and undo space number.
    * Introduce undo_settings.test
    * Adjust and improve a lot of testcases.

commit 3

    WL#10322: Deprecate innodb_undo_logs in 5.7

    * Add (deprecated) to innodb-undo-logs description and mention that it
    is actually setting the number of rollback segments.
    * Delete “(deprecated)” from innodb-rollback-segments message.
    * Add a deprecation warning message when innodb_undo_logs is used
    at runtime and also at startup in a config or the command line.
    * Return a warning when innodb_undo_logs is used at runtime.
    * Rename srv_undo_logs to srv_rollback_segments in code
    * Rename innodb_undo_logs to innodb_rollback_segments in all collections
    and testcases except sysvars.innodb_undo_logs_basic.
    * Fix sysvars.innodb_undo_logs_basic to suppress the deprecation warning.
    Add a restart to exercise the deprecation code for using it at startup.

commit 4

    Bug #25572279 WARNING ALLOCATED TABLESPACE ID N FOR INNODB_UNDO00N
    OLD MAXIMUM WAS N

    This extra bootstrap warning was introduced in rb#13164:
    Bug#24462978: Free up 32 slots in TRX_SYS page for non-temp rsegs.

    It occurs when the database is initialized with undo tablespaces > rollback
    segments. In this case, only the first undo tablespaces associated with the
    limited rollback segments will be used. The remaining undo tablespaces
    cannot be used because the rollback segment slots are not available in the
    TRX_SYS page. But when starting the server, we have to open all unused
    undo tablespaces. Along with opening the unused undo tablespaces, the
    max_assigned_id needs to be incremented to avoid the warning. The rb#13164
    patch was not doing that.

    The solution is simply to call to fil_set_max_space_id_if_bigger(space_id)
    in srv_undo_tablespaces_open() instead of the other three place it does now.
    This makes sure that the condition "id > fil_system->max_assigned_id" in
    fil_space_create() is false which will prevent the reported warning message.

commit 5

    Bug #25551311   BACKPORT BUG #23517560 REMOVE SPACE_ID
                    RESTRICTION FOR UNDO TABLESPACES

    Description:
    ============
    The restriction that required the first undo tablespace to use space_id 1
    is removed. The first undo tablespace can now use a space_id other than 1.
    space_id values for undo tablespaces are still assigned in a consecutive
    sequence.

commit 6

WL#9289 InnoDB: Support Transparent Data Encryption for Undo Tablespaces
    WL#9290 InnoDB: Support Transparent Data Encryption for Redo Log

    Based on wl#8548, we provide encryption support for redo log and undo tablespaces.

    For encrypting redo/undo log, as same as we did in wl#8548, we will en/decrypt the
    redo log blocks/undo log pages in the I/O layer.
    Which means, the en/decryption only happens when the redo/undo log read or
    write from/to disk.

    For redo log, encryption metadata will be stored in the header of first log file.
    Same as wl#8548, there're 2 key levels here, master key and tablespace key.
    Master key is stored in keyring plugin, and it's used to en/decrypt tablespace
    key and iv. Tablespace key is for en/decrypt redo log blocks, and it will be
    stored into the 3rd block of first redo log file(ib_logfile0).

    For undo log, Same as regular tablespace, the encryption metadata will be stored
    in the first page of data file.

    We also added 2 new global variables innodb_redo_log_encrypt=ON/OFF,
    innodb_undo_log_encrypt=ON/OFF for en/disable redo/undo log encryption.
相关实践学习
如何快速连接云数据库RDS MySQL
本场景介绍如何通过阿里云数据管理服务DMS快速连接云数据库RDS MySQL,然后进行数据表的CRUD操作。
全面了解阿里云能为你做什么
阿里云在全球各地部署高效节能的绿色数据中心,利用清洁计算为万物互联的新世界提供源源不断的能源动力,目前开服的区域包括中国(华北、华东、华南、香港)、新加坡、美国(美东、美西)、欧洲、中东、澳大利亚、日本。目前阿里云的产品涵盖弹性计算、数据库、存储与CDN、分析与搜索、云通信、网络、管理与监控、应用服务、互联网中间件、移动服务、视频服务等。通过本课程,来了解阿里云能够为你的业务带来哪些帮助 &nbsp; &nbsp; 相关的阿里云产品:云服务器ECS 云服务器 ECS(Elastic Compute Service)是一种弹性可伸缩的计算服务,助您降低 IT 成本,提升运维效率,使您更专注于核心业务创新。产品详情: https://www.aliyun.com/product/ecs
相关文章
|
1月前
|
存储 SQL 关系型数据库
MySQL日志详解——日志分类、二进制日志bin log、回滚日志undo log、重做日志redo log
MySQL日志详解——日志分类、二进制日志bin log、回滚日志undo log、重做日志redo log、原理、写入过程;binlog与redolog区别、update语句的执行流程、两阶段提交、主从复制、三种日志的使用场景;查询日志、慢查询日志、错误日志等其他几类日志
136 35
MySQL日志详解——日志分类、二进制日志bin log、回滚日志undo log、重做日志redo log
|
17天前
|
存储 SQL 关系型数据库
mysql的undo log、redo log、bin log、buffer pool
MySQL的undo log、redo log、bin log和buffer pool是确保数据库高效、安全和可靠运行的关键组件。理解这些组件的工作原理和作用,对于优化数据库性能和保障数据安全具有重要意义。通过适当的配置和优化,可以显著提升MySQL的运行效率和数据可靠性。
36 16
|
16天前
|
存储 SQL 关系型数据库
mysql的undo log、redo log、bin log、buffer pool
MySQL的undo log、redo log、bin log和buffer pool是确保数据库高效、安全和可靠运行的关键组件。理解这些组件的工作原理和作用,对于优化数据库性能和保障数据安全具有重要意义。通过适当的配置和优化,可以显著提升MySQL的运行效率和数据可靠性。
24 4
|
15天前
|
SQL 存储 关系型数据库
简单聊聊MySQL的三大日志(Redo Log、Binlog和Undo Log)各有什么区别
在MySQL数据库管理中,理解Redo Log(重做日志)、Binlog(二进制日志)和Undo Log(回滚日志)至关重要。Redo Log确保数据持久性和崩溃恢复;Binlog用于主从复制和数据恢复,记录逻辑操作;Undo Log支持事务的原子性和隔离性,实现回滚与MVCC。三者协同工作,保障事务ACID特性。文章还详细解析了日志写入流程及可能的异常情况,帮助深入理解数据库日志机制。
|
2月前
|
SQL 关系型数据库 MySQL
MySQL事务日志-Undo Log工作原理分析
事务的持久性是交由Redo Log来保证,原子性则是交由Undo Log来保证。如果事务中的SQL执行到一半出现错误,需要把前面已经执行过的SQL撤销以达到原子性的目的,这个过程也叫做"回滚",所以Undo Log也叫回滚日志。
133 7
MySQL事务日志-Undo Log工作原理分析
|
1月前
|
存储 关系型数据库 MySQL
图解MySQL【日志】——Undo Log
Undo Log(回滚日志)是 MySQL 中用于实现事务原子性和一致性的关键机制。在默认的自动提交模式下,MySQL 隐式开启事务,每条增删改语句都会记录到 Undo Log 中。其主要作用包括:
48 0
|
3月前
|
SQL 安全 关系型数据库
【MySQL基础篇】事务(事务操作、事务四大特性、并发事务问题、事务隔离级别)
事务是MySQL中一组不可分割的操作集合,确保所有操作要么全部成功,要么全部失败。本文利用SQL演示并总结了事务操作、事务四大特性、并发事务问题、事务隔离级别。
1280 2
【MySQL基础篇】事务(事务操作、事务四大特性、并发事务问题、事务隔离级别)
|
3月前
|
安全 关系型数据库 MySQL
MySQL崩溃保险箱:探秘Redo/Undo日志确保数据库安全无忧!
《MySQL崩溃保险箱:探秘Redo/Undo日志确保数据库安全无忧!》介绍了MySQL中的三种关键日志:二进制日志(Binary Log)、重做日志(Redo Log)和撤销日志(Undo Log)。这些日志确保了数据库的ACID特性,即原子性、一致性、隔离性和持久性。Redo Log记录数据页的物理修改,保证事务持久性;Undo Log记录事务的逆操作,支持回滚和多版本并发控制(MVCC)。文章还详细对比了InnoDB和MyISAM存储引擎在事务支持、锁定机制、并发性等方面的差异,强调了InnoDB在高并发和事务处理中的优势。通过这些机制,MySQL能够在事务执行、崩溃和恢复过程中保持
185 3
|
3月前
|
存储 关系型数据库 MySQL
MySQL引擎InnoDB和MyISAM的区别?
InnoDB是MySQL默认的事务型存储引擎,支持事务、行级锁、MVCC、在线热备份等特性,主索引为聚簇索引,适用于高并发、高可靠性的场景。MyISAM设计简单,支持压缩表、空间索引,但不支持事务和行级锁,适合读多写少、不要求事务的场景。
93 9
|
4月前
|
关系型数据库 MySQL
mysql事务特性
原子性:一个事务内的操作统一成功或失败 一致性:事务前后的数据总量不变 隔离性:事务与事务之间相互不影响 持久性:事务一旦提交发生的改变不可逆

相关产品

  • 云数据库 RDS MySQL 版