MySQL 8.0.30动态redo log初探

MySQL 使用 Redo Log 崩溃恢复过程分析 MySQL 崩溃也是一次关闭过程,只是比正常关闭着急了一些。正常关闭时,MySQL 会做一系列收尾工作,例如:清理 undo 日志、合并 change buffer 缓冲区等操作。具体会进行哪些收尾工作,取决于系统变量 innodb_fast_shutdown 的配置。崩溃直接就是戛然而止,撂挑子不干了,还没来得及进行的那些收尾工作怎么办?那就只能等待下次启动的时候再干了,这就是本文要介绍的崩溃恢复过程。 阅读详情
  • GreatSQL社区原创内容未经授权不得随意使用,转载请联系小编并注明来源。
  • GreatSQL是MySQL的国产分支版本,使用上与MySQL一致。
  • 作者:YeJinrong/叶金荣

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 |
+---------+-----------------------------+-------------+-------------+---------------+---------+
|    9692 | ./#innodb_redo/#ib_redo9692 | 19417284608 | 19419379712 |       2097152 |       1 |
|    9693 | ./#innodb_redo/#ib_redo9693 | 19419379712 | 19421474816 |       2097152 |       1 |
|    9694 | ./#innodb_redo/#ib_redo9694 | 19421474816 | 19423569920 |       2097152 |       1 |
|    9695 | ./#innodb_redo/#ib_redo9695 | 19423569920 | 19425665024 |       2097152 |       1 |
|    9696 | ./#innodb_redo/#ib_redo9696 | 19425665024 | 19427760128 |       2097152 |       1 |
|    9697 | ./#innodb_redo/#ib_redo9697 | 19427760128 | 19429855232 |       2097152 |       1 |
|    9698 | ./#innodb_redo/#ib_redo9698 | 19429855232 | 19431950336 |       2097152 |       1 |
|    9699 | ./#innodb_redo/#ib_redo9699 | 19431950336 | 19434045440 |       2097152 |       1 |
|    9700 | ./#innodb_redo/#ib_redo9700 | 19434045440 | 19436140544 |       2097152 |       1 |
|    9701 | ./#innodb_redo/#ib_redo9701 | 19436140544 | 19438235648 |       2097152 |       1 |
|    9702 | ./#innodb_redo/#ib_redo9702 | 19438235648 | 19440330752 |       2097152 |       1 |
|    9703 | ./#innodb_redo/#ib_redo9703 | 19440330752 | 19442425856 |       2097152 |       1 |
|    9704 | ./#innodb_redo/#ib_redo9704 | 19442425856 | 19444520960 |       2097152 |       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 在线修改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 有哪些改变。... 阅读详情

相关推荐

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

mysql

1.mysql基础 1.1mysql高级之mysql优化 1.1.1explain的用法 表的读取的顺序(id) 表的读取操作的操作类型(select_type) 关联类型或者访问类型(type) 可能使用哪些索引查询(possible_keys) 实际采用的索引(key) 索引使用的字节数(key_len) 显示了在key列记录的索引中,表查找值所用到的列或常量(ref) mysql估计要读取并检测的行数(rows) 展示的是额外信息(Extra) 1.1.2常见的几种查询优化 查询的时候不要用se

qq_35367268的博客 315

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

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

cuyi7076的博客 541

8.0 新特性 - innodb_redo_log_capacity

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

分享既学习 4517

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

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

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

等时替代模型( Isotemporal Substitution Model)

文献阅读:Associations of sedentary time and physical activity with adverse health conditions: Outcome-wide analyses using isotemporal substitution model(该论文于2022年4月28日发表在柳叶刀子刊 EClinicalMedicine 上)

姚巨龙的博客 1万+

MySQL 8.0.30新特性GIPK

结论2:对于已经自动添加my_row_id的表,如需要使用自定义列代替my_row_id作为主键,可以先将set session sql_generate_invisible_primary_key=OFF;结论4:在主库是没有此特性的情况下,从库(8.0.32)通过回放主库的binlog进行同步,gipk特性失效,且主库创建带有my_row_id关键字的列,从库回放不会报错。my_row_id为invisible不可见状态下,DML语句正常 ,且可以通过my_row_id进行查询、更新和删除操作。

m0_66522805的博客 911

遥感图像融合实战:5分钟搞懂全色与多光谱图像如何提升分辨率(附Python代码)

本文通过实战案例,详细解析了如何利用全色锐化技术融合全色与多光谱遥感图像,以提升图像分辨率。文章深入浅出地介绍了核心概念、环境配置、经典GS融合算法的Python代码实现,并对比了不同算法的优劣,最后提供了效果评估方法与实战陷阱分析,帮助读者快速掌握遥感图像融合的关键技术。

weixin_29041195的博客 394

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

Orcad原理图导入Allegro

在即将设计的PCB中,将层叠设置好后,执行File→import→parameters,将刚才导出的.prm文件导入,很多参数就自动设置好了,与已完成的PCB里的参数保持一致。具体操作是:在已完成的PCB里执行File→Exoprt→Parameters,弹出下图所示的对话框,选择需要导出的设计参数后,设置到导出路径,导出记录设计参数的文件(.prm)。在.brd文件导入网表后,往往需要页面大小、格点、各层叠里各要素显示颜色等参数,手动设置十分麻烦,我们可以在一块已经完成的PCB里导出记录设计参数的文件。

sinat_27007097的博客 2085

MFC 中实现 WebSocket 客户端以支持实时双向通信

3. **协议兼容**:若服务器使用 `wss://`(加密),需在 `lws_client_connect_info` 中配置 SSL 相关参数(`ssl_connection = LCCSCF_USE_SSL`)。- 编辑框(`m_editUrl`):输入 WebSocket 服务器地址(如 `ws://echo.websocket.events`)。2. 将编译后的库文件(`.lib`、`.dll`)和头文件路径添加到 MFC 项目中(项目属性 -> VC++ 目录)。// UI:服务器地址。

寒寒豆豆软件公司的博客 202

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

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

weixin_30596165的博客 461

微软商店报错“此产品当前不可用”?终极修复指南

微软商店报错“此产品当前不可用”?终极修复指南

安德洛夫 3810

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

SpringBoot实战教程-springboot概论

Spring Boot 是一个快速开发框架,能够快速的整合第三方框架,简化XML配置,全部采用注解形式,以及自动配置。内置web容器,帮助开发者能够实现快速开发,简化了应用系统的初始搭建以及开发过程。

鸟哥哥的专栏 4155

036、算子映射:如何将ONNX算子映射到NPU硬件指令?

《算子映射:ONNX到NPU的转换艺术》 本文深入探讨了将ONNX算子映射到NPU硬件指令的技术挑战与实践经验。作者通过真实案例揭示了映射过程中的常见陷阱,如Reshape算子被错误映射导致分类错误。文章详细分析了三种映射策略(直接映射、拆分映射和融合映射),并强调映射表在编译器中的核心作用。特别针对动态形状、精度对齐等难题提供了解决方案,分享了编写映射表时的实用铁律,包括先优化后映射、严格单元测试等。最后指出,成功的算子映射需要在数学语义、硬件约束和性能优化之间找到精确平衡,这种看似枯燥的工作实则决定着N

m0_50546716的博客 186

MySQL日志管理:Binary Log与Redo Log

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

zevjay的博客 1080

危废焚烧优化控制系统设计与实现:基于数据驱动的控制参数预测

本文提出了一种基于数据驱动的危险废物焚烧过程优化控制方法。系统利用历史运行数据和实时监测数据,通过深度学习模型预测关键控制参数,实现焚烧过程的智能化控制。系统采用Python开发,结合TensorFlow/PyTorch框架,构建了完整的数据采集、预处理、特征工程、模型训练和实时预测闭环系统。该系统能够处理多变量非线性关系,适应工况变化,从历史数据中学习最优控制策略,相比传统PID控制方法具有显著优势。论文详细介绍了系统架构、算法设计和实现细节,为危废焚烧过程的优化控制提供了有效解决方案。

huanghm88的专栏 206

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

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

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

TMS_WebGMaps_1.9.8.0_Full_Source

TMS_WebGMaps_1.9.8.0_Full_Source 全源码 delphi cbuilder

lwip-2.0.3

lwip是瑞典计算机科学院(SICS)的Adam Dunkels 开发的一个小型开源的TCP/IP协议栈。实现的重点是在保持TCP协议主要功能的基础上减少对RAM 的占用。

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

IEM模型,地表粗糙度模拟

利用微波反演土壤水分时候,利用IEM模型可以实现对随机地表的模拟

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

计算机控制技术及应用

《计算机控制技术及应用》通过总结作者的科研成果和吸收国内外的先进理论、方法和技术,以计算机控制系统的网络化、开放化、智能化和集成化发展趋势为主线索,主要介绍计算机控制系统的基本概念和计算机控制系统的典型形式,计算机控制系统的数学描述与基本分析方法,以及数字PID控制器、最少拍控制系统、达林算法、状态变量设计法等设计方法及其各种改进算法。重点突出计算机控制系统输入输出通道接口的设计方法和典型控制系统的设计案例与实现方法等。

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

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

weixin_30907935的博客 336

MySQL 8.0.32 双写参数和innodb_redo

版本为mysql 8.0.32。

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

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明:

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

余额充值