MySQL 8.0.30动态redo log初探

MySQL 8.0 在线修改redo log 容量 MySQL redo log记录数据记录变更,以及未数据一致性恢复提供保障。在运维MySQL 过程中,很多DBA 会遇到调整redo log 和redo buffer size 大小的需求,然而修改redo log 文件大小需要重启,用户体验不好。不过 MySQL 8.0.30 版本中提供动态调整redo log 文件大小的功能。本文将介绍MySQL 8.0.30 版本中redo log 有哪些改变。... 阅读详情
  • GreatSQL社区原创内容未经授权不得随意使用,转载请联系小编并注明来源。
  • GreatSQL是MySQL的国产分支版本,使用上与MySQL一致。
  • 本文来源:原创投稿;作者:YeJinrong/叶金荣

MySQL 8.0.30动态redo log初探

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_size、innodb_log_files_in_group 就都失效了

在8.0.30里,如果innodb_log_group_home_dir 没有设置,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_group 和 innodb_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 GreatSQL :)

关于 GreatSQL

GreatSQL是由万里数据库维护的MySQL分支,专注于提升MGR可靠性及性能,支持InnoDB并行查询特性,是适用于金融级应用的MySQL分支版本。

相关链接: GreatSQL社区 Gitee GitHub Bilibili

GreatSQL社区:

捉虫活动详情:https://greatsql.cn/thread-97-1-1.html

社区博客有奖征稿详情:https://greatsql.cn/thread-100-1-1.html

6440

MySQL 8.0.30新参数innodb_redo_log_capacity怎么用?手把手教你在线调整Redo Log大小 本文详细解析MySQL 8.0.30新参数innodb_redo_log_capacity的实战应用,教你如何在线动态调整Redo Log大小以优化数据库性能。通过新旧参数对比、生产环境实操指南及异常处理方案,帮助DBA快速掌握这一关键特性,提升MySQL在高并发场景下的稳定性与吞吐量。 阅读详情

相关推荐

MySQL 8.0.30新参数innodb_redo_log_capacity:告别重启,在线调整Redo Log大小(附性能调优建议)

本文详细解析MySQL 8.0.30引入的innodb_redo_log_capacity参数,该特性支持在线调整Redo Log大小,无需重启数据库。文章从原理、实战操作到性能调优,全面指导DBA如何根据业务需求动态管理Redo Log容量,提升数据库性能与稳定性。

weixin_30345577的博客 426

8.0 新特性 - innodb_redo_log_capacity

为了取得更好的读写性能,InnoDB 会将数据缓存在内存中(InnoDB Buffer Pool)对磁盘数据的修改也会落后于内存,这时如果进程或机器崩溃,会导致内存数据丢失,为了保证数据库本身的一致性和持久性,InnoDB 维护了 REDO LOG。

分享既学习 4517

MySQL 8.0.30+ redo log 新特性解析:innodb_redo_log_capacity 如何替代旧参数管理日志文件组

本文深入解析MySQL 8.0.30+引入的redo log新特性innodb_redo_log_capacity,详细对比新旧参数管理方式的差异,揭示新参数如何简化日志文件组管理、支持动态调整并提升性能。通过容量规划公式、场景化配置建议和实战迁移指南,帮助DBA高效利用这一革新特性优化数据库运维。

cuyi7076的博客 541

InnoDB重做日志架构和innodb_redo_log_capacity系统变量(译文)

从MySQL 8.0.30开始,InnoDB的重做日志架构发生了重大变化,重做日志文件被固定为32个,并存放在一个专门的目录下面,用户可以使用系统变量innodb_redo_log_capacity在线修改重做日志容量,原来的innodb_log_files_in_group和innodb_log_file_size两个系统变量已经废弃。

姚远OracleACE的博客 4946

MySQL 三大日志:Redo Log、Undo Log 和 Binlog 完全解析

Undo Log(原子性基石):记录修改前的旧数据,支持事务回滚,也是 MVCC 多版本并发控制的关键Redo Log(持久性基石):基于 WAL 机制保证崩溃恢复能力,通过两阶段提交与 Binlog 协同,确保主从数据一致Binlog(可复制性基石):记录所有变更操作,支撑主从复制和时间点数据恢复每一类日志单独拿出来都不复杂,但三者协同的机制(特别是 MVCC + 版本链 + Read View、两阶段提交 + 崩溃恢复)才是 MySQL 真正硬核的地方。

十年老程序猿,AI 疯狂研究专家,前沿硬核知识分享 825

py_innodb_page_info工具

使用py_innodb_page_info 查看分析各种log以及data file,深入研究mysql的存储引擎底层原理与实现。 mysql innodb undo redo

MySQL8.0.30 版本中redo log的变化

摘要:MySQL 8.0版本对redo log功能进行了多项优化。8.0.30支持动态调整redo log容量,通过innodb_redo_log_capacity参数控制总大小;8.0.17引入redo log归档功能,满足审计合规需求;8.0.16新增redo log加密支持;8.0.21后可以临时禁用redo log以提升数据加载速度,但存在数据丢失风险。这些改进增强了MySQL在日志管理、安全性和性能方面的能力,为不同场景提供了更灵活的配置选项。

Eucalyptus's blog 797

SWIFT报文实战指南:从MT700到MT799的信用证操作全解析

本文深入解析了国际贸易中信用证操作的核心SWIFT报文流程,从开证的MT700到各类通知、修改及结算报文(如MT707、MT730、MT754、MT732/734等)。通过实战案例与关键字段拆解,指导外贸与银行从业者精准处理报文,规避风险,并探讨了利用自动化工具提升处理效率的方法,助力保障跨境交易顺畅。

weixin_29015801的博客 879

MySQL 8.0.30新参数innodb_redo_log_capacity:告别重启,在线调整Redo日志大小实战

MySQL 8.0.30引入的innodb_redo_log_capacity参数实现了Redo日志大小的在线动态调整,彻底解决了传统配置必须重启数据库的痛点。本文详细解析了这一革命性功能的实现原理、新旧架构对比,并提供了生产环境容量规划指南和最佳实践,帮助DBA提升数据库运维效率。

weixin_30596165的博客 461

C++新手也能搞定!Windows下Cesium-Native编译全流程(附依赖下载技巧)

本文为C++新手详细介绍了在Windows系统下编译Cesium-Native库的全流程。重点针对网络环境不佳的情况,提供了手动下载依赖库的实用技巧,并指导用户使用CMake配置、生成解决方案,最终完成编译与测试验证,帮助开发者成功构建这一处理3D地理空间数据的C++运行时库。

weixin_28839549的博客 380

MySQL 8.0.30+ redo log 配置变更:innodb_redo_log_capacity 实测与 3 种刷盘策略对比

本文深度解析MySQL 8.0.30+中redo log配置变更,重点介绍innodb_redo_log_capacity参数的使用与性能调优。通过对比三种刷盘策略,提供容量规划最佳实践和监控方案,帮助DBA优化数据库性能,确保数据安全与高吞吐量。

weixin_34199764的博客 280

Unity零基础到进阶 ☀️| Unity中的 GC及优化 超级全面解析 ☆(ゝω・)v 建议收藏!

介绍: 在游戏运行的时候,数据主要存储在内存中,当游戏的数据在不需要的时候,存储当前数据的内存就可以被回收以再次使用。内存垃圾是指当前废弃数据所占用的内存,垃圾回收(GC)是指将废弃的内存重新回收再次使用的过程。 Unity中将垃圾回收当作内存管理的一部分,如果游戏中废弃数据占用内存较大,则游戏的性能会受到极大影响,此时垃圾回收会成为游戏性能的一大障碍点。 本文我们主要学习垃圾回收的机制,垃圾回收如何被触发以及如何提GC收效率来提高游戏的性能。 Unity内存管理机制简介 要想了解垃圾回收如何工作以及何时被

努力前行,总会成为自己心中的那道光 6万+

MySQL日志管理:Binary Log与Redo Log

MySQL的Binary Log和Redo Log是数据库运行的重要组成部分,分别负责逻辑复制和物理恢复。在面对主从同步延迟和数据恢复效率低的问题时,通过合理配置和优化这两种日志,可以有效提升系统的稳定性和性能。在实际应用中,建议根据业务特点动态调整相关参数,并结合监控工具(如Prometheus、Grafana)实时观察日志使用情况,确保数据库始终处于高效运行状态。

zevjay的博客 1080

踩坑2周总结:Python+YOLO26搭建工业级多路视频分析应用,从单路卡顿到16路4K稳跑30FPS

本文分享了工业级多路视频分析系统的实战经验,针对智慧物流园区的车辆违停和人员安全监测需求,提出了一套完整的解决方案。作者通过踩坑实践,总结出多路视频分析的四大核心痛点:视频流解码瓶颈、推理调度混乱、内存占用爆炸和部署兼容性差。 文章详细介绍了技术选型方案,推荐使用FFmpeg+PyAV进行硬件加速解码、YOLO26+TensorRT INT8量化推理、单进程多线程的生产者-消费者架构,以及内存池复用等技术组合。该方案在RTX 4070 Ti上实现了16路4K视频30FPS稳定运行,GPU利用率达85%以上,

专注于Python爬虫开发,分享爬虫技巧、项目实战与反爬经验,使用Scrapy、BeautifulSoup等工具,解决数据抓取难题。 955

scp 出现Permission denied错误 解决方法

第一种说辞(来源于网络),说是scp涉及root远程登录,默认是没有打开的,只需要把配置文件中的permit打开即可。最后scp的时候发现还不行,只需要将其scp的服务器用户名 修改为root即可。第二种解决方案,将scp 传输的服务器用户名改为root即可。(这是最基本的,一开始我忽视了这个问题,导致一直scp不了)window系统下,向ubuntu操作系统 scp传输文件。

码农研究僧的博客 6729

MySQL 日志篇:Redo 文件和自适应检查点

来看看 MySQL 的 Redo 文件长啥样 ~

一直学,你始终是学生,但是只要创造一招,你便是宗师。 1117

【YOLO目标检测全栈实战】98 YOLO模型在低光照环境下的自适应增强策略

你有没有遇到过这种情况?深夜加班调试产线检测模型,车间灯光昏暗,摄像头采集的图片黑乎乎一片,YOLO模型直接“罢工”——漏检率飙升到40%以上。上个月我在一个汽车零部件质检项目里就栽了跟头:白天模型跑得飞起,mAP@0.5达到0.92,可一到夜班,同样的产线、同样的零件,mAP直接掉到0.63。客户拍着桌子问我:“你这模型怎么还分白天黑夜?”

企鹅码农的专属播客,分享10多年的实战案例和经验解读,包含YOLO、RT-DETR、AI等各个工作领域。 284

mysql 计算 redo量_MySQL如何计算统计redo log大小

在MySQL中如何计算、统计重做日志(redo log)的生成情况呢? 例如10分钟内,生成了多少M的redo log呢?30分钟内又生成了多少M的redo log.....。MySQL没有像Oracle中那样的系统视图统计这些数据,但是我们可以通过一些方法曲线的统计二进制日志的生成量。虽然我在这篇博客“MySQL中Redo Log相关的重要参数总结”中介绍了,MySQL 8.0引入了innodb...

weixin_30299099的博客 178

YOLOv12模型详解及代码复现

YOLOV12算法详解及Python代码复现

hasakie的博客 6488

迈瑞BS系列全自动生化分析仪LIS协议接口手册(内含HL7和ASTM)

迈瑞BS系列全自动生化分析仪LIS协议接口手册,内含HL7和ASTM)

mysql log长度_MySQL如何计算统计redo log大小

在MySQL中如何计算、统计重做日志(redo log)的生成情况呢? 例如10分钟内,生成了多少M的redo log呢?30分钟内又生成了多少M的redo log.....。MySQL没有像Oracle中那样的系统视图统计这些数据,但是我们可以通过一些方法曲线的统计二进制日志的生成量。虽然我在这篇博客“MySQL中Redo Log相关的重要参数总结”中介绍了,MySQL 8.0引入了innodb...

weixin_39578457的博客 173

复分析 阿尔福斯(Ahlfors) 第三版答案 英文

答案分为十章,有部分习题没有答案,全英文复分析阿尔福斯(Ahlfors) 第三版答案

保姆级教程:根据你的Buffer Pool大小,为MySQL 8.0的Redo Log设置一个‘黄金容量’

本文详细解析了MySQL 8.0中Buffer Pool与Redo Log容量的黄金匹配法则,帮助数据库管理员根据innodb_redo_log_capacity参数优化性能。通过计算公式、配置指南和监控策略,确保数据库在高负载下保持稳定运行,特别适合需要精细调优的生产环境。

weixin_30907935的博客 336

OV9734 DATASHEET,完整规格书

OV9734完整规格书,包括电气参数,尺寸规格,寄存器配置表等

android 蓝牙通讯demo

android 下蓝牙通讯demo,实现了发现蓝牙,使能蓝牙,通过蓝牙发送消息。

MySQL 8.0.32 双写参数和innodb_redo

版本为mysql 8.0.32。

青春作伴,爱情最好 1564
上一篇: MySQL 8.0.30动态redo log初探
下一篇: MySQL 聚合函数初探
GreatSQL社区
博客等级 码龄5年 1210粉丝 390原创
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付:10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值