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

本文涉及的产品
云原生数据库 PolarDB 分布式版,标准版 2核8GB
RDS PostgreSQL Serverless,0.5-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.
相关实践学习
每个IT人都想学的“Web应用上云经典架构”实战
本实验从Web应用上云这个最基本的、最普遍的需求出发,帮助IT从业者们通过“阿里云Web应用上云解决方案”,了解一个企业级Web应用上云的常见架构,了解如何构建一个高可用、可扩展的企业级应用架构。
MySQL数据库入门学习
本课程通过最流行的开源数据库MySQL带你了解数据库的世界。 &nbsp; 相关的阿里云产品:云数据库RDS MySQL 版 阿里云关系型数据库RDS(Relational Database Service)是一种稳定可靠、可弹性伸缩的在线数据库服务,提供容灾、备份、恢复、迁移等方面的全套解决方案,彻底解决数据库运维的烦恼。 了解产品详情:&nbsp;https://www.aliyun.com/product/rds/mysql&nbsp;
相关文章
|
13天前
|
关系型数据库 MySQL 数据库
阿里云数据库RDS费用价格:MySQL、SQL Server、PostgreSQL和MariaDB引擎收费标准
阿里云RDS数据库支持MySQL、SQL Server、PostgreSQL、MariaDB,多种引擎优惠上线!MySQL倚天版88元/年,SQL Server 2核4G仅299元/年,PostgreSQL 227元/年起。高可用、可弹性伸缩,安全稳定。详情见官网活动页。
|
14天前
|
关系型数据库 分布式数据库 数据库
阿里云数据库收费价格:MySQL、PostgreSQL、SQL Server和MariaDB引擎费用整理
阿里云数据库提供多种类型,包括关系型与NoSQL,主流如PolarDB、RDS MySQL/PostgreSQL、Redis等。价格低至21元/月起,支持按需付费与优惠套餐,适用于各类应用场景。
|
25天前
|
存储 关系型数据库 MySQL
介绍MySQL的InnoDB引擎特性
总结而言 , Inno DB 引搞 是 MySQL 中 高 性 能 , 高 可靠 的 存 储选项 , 宽泛 应用于要求强 复杂交易处理场景 。
64 15
|
19天前
|
关系型数据库 MySQL 数据库
MySql事务以及事务的四大特性
事务是数据库操作的基本单元,具有ACID四大特性:原子性、一致性、隔离性、持久性。它确保数据的正确性与完整性。并发事务可能引发脏读、不可重复读、幻读等问题,数据库通过不同隔离级别(如读未提交、读已提交、可重复读、串行化)加以解决。MySQL默认使用可重复读级别。高隔离级别虽能更好处理并发问题,但会降低性能。
|
19天前
|
关系型数据库 MySQL 数据库
阿里云数据库RDS支持MySQL、SQL Server、PostgreSQL和MariaDB引擎
阿里云数据库RDS支持MySQL、SQL Server、PostgreSQL和MariaDB引擎,提供高性价比、稳定安全的云数据库服务,适用于多种行业与业务场景。
|
19天前
|
缓存 关系型数据库 BI
使用MYSQL Report分析数据库性能(下)
使用MYSQL Report分析数据库性能
56 3
|
25天前
|
关系型数据库 MySQL 数据库
自建数据库如何迁移至RDS MySQL实例
数据库迁移是一项复杂且耗时的工程,需考虑数据安全、完整性及业务中断影响。使用阿里云数据传输服务DTS,可快速、平滑完成迁移任务,将应用停机时间降至分钟级。您还可通过全量备份自建数据库并恢复至RDS MySQL实例,实现间接迁移上云。
|
2月前
|
存储 运维 关系型数据库
从MySQL到云数据库,数据库迁移真的有必要吗?
本文探讨了企业在业务增长背景下,是否应从 MySQL 迁移至云数据库的决策问题。分析了 MySQL 的优势与瓶颈,对比了云数据库在存储计算分离、自动化运维、多负载支持等方面的优势,并提出判断迁移必要性的五个关键问题及实施路径,帮助企业理性决策并落地迁移方案。
|
12天前
|
关系型数据库 MySQL 分布式数据库
阿里云PolarDB云原生数据库收费价格:MySQL和PostgreSQL详细介绍
阿里云PolarDB兼容MySQL、PostgreSQL及Oracle语法,支持集中式与分布式架构。标准版2核4G年费1116元起,企业版最高性能达4核16G,支持HTAP与多级高可用,广泛应用于金融、政务、互联网等领域,TCO成本降低50%。
|
13天前
|
SQL 关系型数据库 MySQL
Mysql数据恢复—Mysql数据库delete删除后数据恢复案例
本地服务器,操作系统为windows server。服务器上部署mysql单实例,innodb引擎,独立表空间。未进行数据库备份,未开启binlog。 人为误操作使用Delete命令删除数据时未添加where子句,导致全表数据被删除。删除后未对该表进行任何操作。需要恢复误删除的数据。 在本案例中的mysql数据库未进行备份,也未开启binlog日志,无法直接还原数据库。

相关产品

  • 云数据库 RDS MySQL 版
  • 推荐镜像

    更多