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

本文涉及的产品
RDS PostgreSQL Serverless,0.5-4RCU 50GB 3个月
推荐场景:
对影评进行热评分析
RDS SQL Server Serverless,2-4RCU 50GB 3个月
推荐场景:
RDS MySQL Serverless 基础系列,0.5-2RCU 50GB
简介: 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.
相关实践学习
如何在云端创建MySQL数据库
开始实验后,系统会自动创建一台自建MySQL的 源数据库 ECS 实例和一台 目标数据库 RDS。
全面了解阿里云能为你做什么
阿里云在全球各地部署高效节能的绿色数据中心,利用清洁计算为万物互联的新世界提供源源不断的能源动力,目前开服的区域包括中国(华北、华东、华南、香港)、新加坡、美国(美东、美西)、欧洲、中东、澳大利亚、日本。目前阿里云的产品涵盖弹性计算、数据库、存储与CDN、分析与搜索、云通信、网络、管理与监控、应用服务、互联网中间件、移动服务、视频服务等。通过本课程,来了解阿里云能够为你的业务带来哪些帮助 &nbsp; &nbsp; 相关的阿里云产品:云服务器ECS 云服务器 ECS(Elastic Compute Service)是一种弹性可伸缩的计算服务,助您降低 IT 成本,提升运维效率,使您更专注于核心业务创新。产品详情: https://www.aliyun.com/product/ecs
相关文章
|
9天前
|
存储 关系型数据库 MySQL
MySQL 8.0特性-自增变量的持久化
【11月更文挑战第8天】在 MySQL 8.0 之前,自增变量(`AUTO_INCREMENT`)的行为在服务器重启后可能会发生变化,导致意外结果。MySQL 8.0 引入了自增变量的持久化特性,将其信息存储在数据字典中,确保重启后的一致性。这提高了开发和管理的稳定性,减少了主键冲突和数据不一致的风险。默认情况下,MySQL 8.0 启用了这一特性,但在升级时需注意行为变化。
|
10天前
|
存储 Oracle 关系型数据库
【赵渝强老师】MySQL InnoDB的表空间
InnoDB是MySQL默认的存储引擎,主要由存储结构、内存结构和线程结构组成。其存储结构分为逻辑和物理两部分,逻辑存储结构包括表空间、段、区和页。表空间是InnoDB逻辑结构的最高层,所有数据都存放在其中。默认情况下,InnoDB有一个共享表空间ibdata1,用于存放撤销信息、系统事务信息等。启用参数`innodb_file_per_table`后,每张表的数据可以单独存放在一个表空间内,但撤销信息等仍存放在共享表空间中。
|
25天前
|
存储 关系型数据库 MySQL
mysql 引擎概述
MySQL存储引擎是处理不同类型表操作的组件,InnoDB是最常用的默认引擎,支持事务、行级锁定和外键。MySQL采用插件式存储引擎架构,支持多种引擎,如MyISAM、Memory、CSV等,每种引擎适用于不同的应用场景。通过`SHOW ENGINES`命令可查看当前MySQL实例支持的存储引擎及其状态。选择合适的存储引擎需根据具体业务需求和引擎特性来决定。
|
2月前
|
JSON 关系型数据库 MySQL
MySQL 8.0 新特性
MySQL 8.0 新特性
147 10
MySQL 8.0 新特性
|
2月前
|
存储 Oracle 关系型数据库
Oracle和MySQL有哪些区别?从基本特性、技术选型、字段类型、事务、语句等角度详细对比Oracle和MySQL
从基本特性、技术选型、字段类型、事务提交方式、SQL语句、分页方法等方面对比Oracle和MySQL的区别。
510 18
Oracle和MySQL有哪些区别?从基本特性、技术选型、字段类型、事务、语句等角度详细对比Oracle和MySQL
|
1月前
|
SQL 安全 关系型数据库
MySQL8.2有哪些新特性?
【10月更文挑战第3天】MySQL8.2有哪些新特性?
37 2
|
28天前
|
存储 关系型数据库 MySQL
MySQL中的Redo Log、Undo Log和Binlog:深入解析
【10月更文挑战第21天】在数据库管理系统中,日志是保障数据一致性和完整性的关键机制。MySQL作为一种广泛使用的关系型数据库管理系统,提供了多种日志类型来满足不同的需求。本文将详细介绍MySQL中的Redo Log、Undo Log和Binlog,从背景、业务场景、功能、底层实现原理、使用措施等方面进行详细分析,并通过Java代码示例展示如何与这些日志进行交互。
63 0
|
1月前
|
存储 关系型数据库 MySQL
mysql 8.0 的 建表 和八种 建表引擎实例
mysql 8.0 的 建表 和八种 建表引擎实例
20 0
|
1月前
|
存储 监控 关系型数据库
MySQL造数据占用临时表空间
MySQL造数据占用临时表空间
39 0
|
3月前
|
C# Windows 监控
WPF应用跨界成长秘籍:深度揭秘如何与Windows服务完美交互,扩展功能无界限!
【8月更文挑战第31天】WPF(Windows Presentation Foundation)是 .NET 框架下的图形界面技术,具有丰富的界面设计和灵活的客户端功能。在某些场景下,WPF 应用需与 Windows 服务交互以实现后台任务处理、系统监控等功能。本文探讨了两者交互的方法,并通过示例代码展示了如何扩展 WPF 应用的功能。首先介绍了 Windows 服务的基础知识,然后阐述了创建 Windows 服务、设计通信接口及 WPF 客户端调用服务的具体步骤。通过合理的交互设计,WPF 应用可获得更强的后台处理能力和系统级操作权限,提升应用的整体性能。
106 0

相关产品

  • 云数据库 RDS MySQL 版