MySQL 8.0.30动态redo log初探

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

MySQL从5.7版本开始支持在线动态修改 innodb_buffer_pool_size,8.0开始支持在线添加undo表空间,以及临时表空间的自动回收,真的是越来越方便了。

从8.0.30开始,又新增支持动态调整redo log的大杀器,对DBA来说又是一大福音。

在8.0.30里,新增选项 innodb_redo_log_capacity,用于定义redo log总大小。如果设置了该选项,则原来定义redo log的几个选项 innodb_log_file_sizeinnodb_log_files_in_groupinnodb_log_group_home_dir 就都失效了。

在8.0.30里,redo log存储在 datadir/#innodb_redo下,由32个文件组成。文件命名为 #ib_redoN**,每个文件大小是 innodb_redo_log_capacity/32(在resize redo log时可能会短时间不一样)。

-rw-r-----. 1 mysql mysql 110M Sep 28 13:54 #ib_redo2923
-rw-r-----. 1 mysql mysql 256K Sep 28 13:54 #ib_redo2924
-rw-r-----. 1 mysql mysql 256K Sep 28 13:54 #ib_redo2925
-rw-r-----. 1 mysql mysql 256K Sep 28 13:54 #ib_redo2926

有两种类型的redo log文件,一种是当前正在使用的(ordinary),文件名是正常的 #ib_redoN;另一种是空闲的(spare),文件名为 #ib_redoN_tmp,多加了个 _tmp 后缀。

-rw-r-----. 1 mysql mysql 192M Sep 28 13:53 #ib_redo2922
-rw-r-----. 1 mysql mysql 192M Sep 28 13:53 #ib_redo2923
-rw-r-----. 1 mysql mysql 192M Sep 28 12:42 #ib_redo2924_tmp
-rw-r-----. 1 mysql mysql 192M Sep 28 12:44 #ib_redo2925_tmp
-rw-r-----. 1 mysql mysql 192M Sep 28 12:47 #ib_redo2926_tmp

可以直接查看当前所有活跃redo log的状态:

mysql> SELECT FILE_NAME, START_LSN, END_LSN FROM performance_schema.innodb_redo_log_files;
mysql> SELECT * FROM performance_schema.innodb_redo_log_files;
+---------+-----------------------------+-------------+-------------+---------------+---------+----------------+
| FILE_ID | FILE_NAME                   | START_LSN   | END_LSN     | SIZE_IN_BYTES | IS_FULL | CONSUMER_LEVEL |
+---------+-----------------------------+-------------+-------------+---------------+---------+----------------+
|    9692 | ./#innodb_redo/#ib_redo9692 | 19417284608 | 19419379712 |       2097152 |       1 |              0 |
|    9693 | ./#innodb_redo/#ib_redo9693 | 19419379712 | 19421474816 |       2097152 |       1 |              0 |
|    9694 | ./#innodb_redo/#ib_redo9694 | 19421474816 | 19423569920 |       2097152 |       1 |              0 |
|    9695 | ./#innodb_redo/#ib_redo9695 | 19423569920 | 19425665024 |       2097152 |       1 |              0 |
|    9696 | ./#innodb_redo/#ib_redo9696 | 19425665024 | 19427760128 |       2097152 |       1 |              0 |
|    9697 | ./#innodb_redo/#ib_redo9697 | 19427760128 | 19429855232 |       2097152 |       1 |              0 |
|    9698 | ./#innodb_redo/#ib_redo9698 | 19429855232 | 19431950336 |       2097152 |       1 |              0 |
|    9699 | ./#innodb_redo/#ib_redo9699 | 19431950336 | 19434045440 |       2097152 |       1 |              0 |
|    9700 | ./#innodb_redo/#ib_redo9700 | 19434045440 | 19436140544 |       2097152 |       1 |              0 |
|    9701 | ./#innodb_redo/#ib_redo9701 | 19436140544 | 19438235648 |       2097152 |       1 |              0 |
|    9702 | ./#innodb_redo/#ib_redo9702 | 19438235648 | 19440330752 |       2097152 |       1 |              0 |
|    9703 | ./#innodb_redo/#ib_redo9703 | 19440330752 | 19442425856 |       2097152 |       1 |              0 |
|    9704 | ./#innodb_redo/#ib_redo9704 | 19442425856 | 19444520960 |       2097152 |       0 |              0 |
+---------+-----------------------------+-------------+-------------+---------------+---------+----------------+

相应的,增加了几个status用来观察redo log的状态:

mysql> show global status like '%innodb%redo%';
+-------------------------------------+-------------+
| Variable_name                       | Value       |
+-------------------------------------+-------------+
| Innodb_redo_log_read_only           | OFF         |   #当前redo不是处于RO状态
| Innodb_redo_log_uuid                | 1075899837  |   #redo log uuid,归档用
| Innodb_redo_log_checkpoint_lsn      | 16900081552 |   #最新的checkpoint
| Innodb_redo_log_current_lsn         | 16905440582 |   #当前LSN
| Innodb_redo_log_flushed_to_disk_lsn | 16905433909 |   #已刷盘的LSN
| Innodb_redo_log_logical_size        | 5358080     |   #当前活跃事务正在使用中的redo log大小
| Innodb_redo_log_physical_size       | 24117248    |   #当前正在使用中的redo log大小(不含空闲的那部分)
| Innodb_redo_log_capacity_resized    | 33554432    |   #redo log resized后的大小
| Innodb_redo_log_resize_status       | OK          |   #resize状态,OK|Resizing down两种
| Innodb_redo_log_enabled             | ON          |
+-------------------------------------+-------------+

从上面的结果中能看到当前redo log总大小是32MB,ordinary空间是 24117248字节,spare空间 9437184字节(33554432 - 24117248),当前活跃事务占用的空间是 5358080字节。

我们还可以利用下面的方法来预估合理的 innodb_redo_log_capacity 值应该是多少。

mysql> SHOW GLOBAL STATUS LIKE 'Innodb_redo_log_current_lsn'; SELECT SLEEP(60); SHOW GLOBAL STATUS LIKE 'Innodb_redo_log_current_lsn';
+-----------------------------+------------+
| Variable_name               | Value      |
+-----------------------------+------------+
| Innodb_redo_log_current_lsn | 1895933494 |
+-----------------------------+------------+
1 row in set (0.01 sec)
+-----------+
| SLEEP(60) |
+-----------+
|         0 |
+-----------+
1 row in set (1 min 0.00 sec)
+-----------------------------+------------+
| Variable_name               | Value      |
+-----------------------------+------------+
| Innodb_redo_log_current_lsn | 1986911858 |
+-----------------------------+------------+
1 row in set (0.01 sec)

先观察1分钟内,共产生多少redo log为 86.76MB(1986911858-1895933494),通常我们要预留10-30分钟的redo log空间,因此合理的 innodb_redo_log_capacity 建议值约为 1GB ~ 3GB左右。

当我们把redo log调小(压测期间,从32MB调低到8MB):

mysql> SET GLOBAL innodb_redo_log_capacity = 8*1024*1024;

日志中可能会有类似下面的提示,警告redo log可能不够用,建议加大:

2022-09-28T14:04:15.046016+08:00 8 [Note] [MY-013884] [InnoDB] User has set innodb_redo_log_capacity to 8M.
2022-09-28T14:04:15.046322+08:00 0 [Note] [MY-013885] [InnoDB] Redo log has been requested to resize from 64M to 8M.
2022-09-28T14:04:15.918901+08:00 0 [Warning] [MY-013867] [InnoDB] Redo log is running out of free space, pausing user threads... Consider increasing innodb_redo_log_capacity.
2022-09-28T14:04:16.012707+08:00 0 [Note] [MY-013868] [InnoDB] Redo log reclaimed some free space, resuming user threads.
2022-09-28T14:04:18.630082+08:00 0 [Note] [MY-013887] [InnoDB] Redo log has been resized to 8M.

注意:调小redo log的话,需要等当前事务提交后,相应的活跃redo log文件才能释放。

当启用 innodb_redo_log_capacity 后,如果还继续设置 innodb_log_files_in_groupinnodb_log_file_size,则日志中会有类似下面的提示,忽略即可:

2022-09-28T14:49:20.248216+08:00 0 [Warning] [MY-013869] [InnoDB] Ignored deprecated configuration parameter innodb_log_file_size. Use
d innodb_redo_log_capacity instead.
2022-09-28T14:49:20.248271+08:00 0 [Warning] [MY-013870] [InnoDB] Ignored deprecated configuration parameter innodb_log_files_in_group
. Used innodb_redo_log_capacity instead.

有了动态redo log功能,又少了一个需要重启MySQL的理由,对DBA来说真的是很方便。

顺便一起来猜猜MySQL下一个能动态实现的功能是啥呢?比如可以在线动态回收空闲的表空间?哈哈。。。

Enjoy MySQL :)

相关实践学习
如何快速连接云数据库RDS MySQL
本场景介绍如何通过阿里云数据管理服务DMS快速连接云数据库RDS MySQL,然后进行数据表的CRUD操作。
全面了解阿里云能为你做什么
阿里云在全球各地部署高效节能的绿色数据中心,利用清洁计算为万物互联的新世界提供源源不断的能源动力,目前开服的区域包括中国(华北、华东、华南、香港)、新加坡、美国(美东、美西)、欧洲、中东、澳大利亚、日本。目前阿里云的产品涵盖弹性计算、数据库、存储与CDN、分析与搜索、云通信、网络、管理与监控、应用服务、互联网中间件、移动服务、视频服务等。通过本课程,来了解阿里云能够为你的业务带来哪些帮助     相关的阿里云产品:云服务器ECS 云服务器 ECS(Elastic Compute Service)是一种弹性可伸缩的计算服务,助您降低 IT 成本,提升运维效率,使您更专注于核心业务创新。产品详情: https://www.aliyun.com/product/ecs
相关文章
|
15天前
|
SQL 存储 关系型数据库
Mysql并发控制和日志
通过深入理解和应用 MySQL 的并发控制和日志管理技术,您可以显著提升数据库系统的效率和稳定性。
66 10
|
10天前
|
安全 关系型数据库 MySQL
MySQL崩溃保险箱:探秘Redo/Undo日志确保数据库安全无忧!
《MySQL崩溃保险箱:探秘Redo/Undo日志确保数据库安全无忧!》介绍了MySQL中的三种关键日志:二进制日志(Binary Log)、重做日志(Redo Log)和撤销日志(Undo Log)。这些日志确保了数据库的ACID特性,即原子性、一致性、隔离性和持久性。Redo Log记录数据页的物理修改,保证事务持久性;Undo Log记录事务的逆操作,支持回滚和多版本并发控制(MVCC)。文章还详细对比了InnoDB和MyISAM存储引擎在事务支持、锁定机制、并发性等方面的差异,强调了InnoDB在高并发和事务处理中的优势。通过这些机制,MySQL能够在事务执行、崩溃和恢复过程中保持
37 3
|
27天前
|
SQL 存储 缓存
MySQL进阶突击系列(02)一条更新SQL执行过程 | 讲透undoLog、redoLog、binLog日志三宝
本文详细介绍了MySQL中update SQL执行过程涉及的undoLog、redoLog和binLog三种日志的作用及其工作原理,包括它们如何确保数据的一致性和完整性,以及在事务提交过程中各自的角色。同时,文章还探讨了这些日志在故障恢复中的重要性,强调了合理配置相关参数对于提高系统稳定性的必要性。
|
2月前
|
SQL 关系型数据库 MySQL
【赵渝强老师】MySQL的全量日志文件
MySQL全量日志记录所有操作的SQL语句,默认禁用。启用后,可通过`show variables like %general_log%检查状态,使用`set global general_log=ON`临时开启,执行查询并查看日志文件以追踪SQL执行详情。
|
2月前
|
关系型数据库 MySQL 数据库
【赵渝强老师】MySQL的binlog日志文件
MySQL的binlog日志记录了所有对数据库的更改操作(不包括SELECT和SHOW),主要用于主从复制和数据恢复。binlog有三种模式,可通过设置binlog_format参数选择。示例展示了如何启用binlog、设置格式、查看日志文件及记录的信息。
161 6
|
2月前
|
SQL 关系型数据库 MySQL
【赵渝强老师】MySQL的慢查询日志
MySQL的慢查询日志用于记录执行时间超过设定阈值的SQL语句,帮助数据库管理员识别并优化性能问题。通过`mysqldumpslow`工具可查看日志。本文介绍了如何检查、启用及配置慢查询日志,并通过实例演示了慢查询的记录与分析过程。
174 3
|
2月前
|
XML 安全 Java
【日志框架整合】Slf4j、Log4j、Log4j2、Logback配置模板
本文介绍了Java日志框架的基本概念和使用方法,重点讨论了SLF4J、Log4j、Logback和Log4j2之间的关系及其性能对比。SLF4J作为一个日志抽象层,允许开发者使用统一的日志接口,而Log4j、Logback和Log4j2则是具体的日志实现框架。Log4j2在性能上优于Logback,推荐在新项目中使用。文章还详细说明了如何在Spring Boot项目中配置Log4j2和Logback,以及如何使用Lombok简化日志记录。最后,提供了一些日志配置的最佳实践,包括滚动日志、统一日志格式和提高日志性能的方法。
408 30
【日志框架整合】Slf4j、Log4j、Log4j2、Logback配置模板
|
21天前
|
监控 安全 Apache
什么是Apache日志?为什么Apache日志分析很重要?
Apache是全球广泛使用的Web服务器软件,支持超过30%的活跃网站。它通过接收和处理HTTP请求,与后端服务器通信,返回响应并记录日志,确保网页请求的快速准确处理。Apache日志分为访问日志和错误日志,对提升用户体验、保障安全及优化性能至关重要。EventLog Analyzer等工具可有效管理和分析这些日志,增强Web服务的安全性和可靠性。
|
3月前
|
XML JSON Java
Logback 与 log4j2 性能对比:谁才是日志框架的性能王者?
【10月更文挑战第5天】在Java开发中,日志框架是不可或缺的工具,它们帮助我们记录系统运行时的信息、警告和错误,对于开发人员来说至关重要。在众多日志框架中,Logback和log4j2以其卓越的性能和丰富的功能脱颖而出,成为开发者们的首选。本文将深入探讨Logback与log4j2在性能方面的对比,通过详细的分析和实例,帮助大家理解两者之间的性能差异,以便在实际项目中做出更明智的选择。
352 3
|
1月前
|
存储 监控 安全
什么是事件日志管理系统?事件日志管理系统有哪些用处?
事件日志管理系统是IT安全的重要工具,用于集中收集、分析和解释来自组织IT基础设施各组件的事件日志,如防火墙、路由器、交换机等,帮助提升网络安全、实现主动威胁检测和促进合规性。系统支持多种日志类型,包括Windows事件日志、Syslog日志和应用程序日志,通过实时监测、告警及可视化分析,为企业提供强大的安全保障。然而,实施过程中也面临数据量大、日志管理和分析复杂等挑战。EventLog Analyzer作为一款高效工具,不仅提供实时监测与告警、可视化分析和报告功能,还支持多种合规性报告,帮助企业克服挑战,提升网络安全水平。