MySQL Redo Log归档

原创

已于 2024-12-13 17:34:50 修改 · 531 阅读

3 ·

CC 4.0 BY-SA版权

文章标签：

#mysql #数据库

于 2024-12-13 17:16:51 首次发布

Redo Log归档功能V8.0.17发布，只有企业版备份工具支持归档Redo Log
用于在备份期间避免重做日志记录丢失

Redo归档设置

查看 show variables like '%archive%';
变量innodb_redo_log_archive_dirs 默认值为NULL，不允许激活重做日志存档

## my.cnf配置：
innodb_redo_log_archive_dirs=arch1:/redo_archive/arch1;arch2:/redo_archive/arch2 
## 命令行设置： 
SET GLOBAL innodb_redo_log_archive_dirs=arch1:/redo_archive/arch1;arch2:/redo_archive/arch2

设置和使用注意事项

&nbs

最低0.47元/天解锁文章

确定要放弃本次机会？

福利倒计时

: :

立减 ¥

普通VIP年卡可用

立即使用

diandian_mao

关注关注

3
点赞
踩
3

收藏

觉得还不错? 一键收藏
0
评论
分享

复制链接

分享到 QQ

分享到新浪微博

扫一扫
举报

举报

新特性速递 | InnoDB redo log archiving(归档)

老叶茶馆

07-23

1926

导读MySQL 8.0.17开始支持的redo log归档能干嘛用呢，好吃吗今天，MySQL 8.0.17发布了，看了下release note，发现果真如之前预期的那...

MySQL binlog归档日志和redo log事务日志详解

qq_56263094的博客

07-27

1780

Buffer pool是InnoDB存储引擎层的内存缓存池，查询都是先从Buffer pool先查询，没有命中再从磁盘加载，这样就减少了IO的消耗更新表数据的时候，也是在Buffer pool里面修改，同时，会将修改的记录记录到redo log buffer里面，根据选择的刷盘时机刷屏到redo log里面 ......

参与评论您还未登录，请先登录后发表或查看评论

新特性解读 | MySQL 8.0 REDO 归档目录权限问题

ActionTech的博客

04-18

1134

作者：杨涛涛资深数据库专家，专研 MySQL 十余年。擅长 MySQL、PostgreSQL、MongoDB 等开源数据库相关的备份恢复、SQL 调优、监控运维、高可用架构设计等。目前任职于爱可生，为各大运营商及银行金融企业提供 MySQL 相关技术支持、MySQL 相关课程培训等工作。本文来源：原创投稿*爱可生开源社区出品，原创内容未经授权不得随意使用，转载请联系小编并注明来源。特分享出来最近在整理 MySQL 热备工具的实验题目时遇到的 REDO 日志归档问题！

MySQL 知识点分享三：MySQL的8种日志和相关参数

贺浦力特的博客

03-24

1002

MySQL的8种日志重做日志回滚日志(undo log) 二进制日志(binlog) 错误日志(errorlog) 慢查询日志(slow query log) 通用查询日志(general log) 中继日志(relay log) DDL日志(metadata log)

mysql 备份优化,MySQL8.0新特性：备份优化

weixin_39809584的博客

03-17

364

Redo Log Archiving在MySQL8.0中启用了redo log archive的功能，旨在解决一致性备份问题。在之前的版本中，由于redo是固定大小循环写入的，如果备份速度跟不上redo log生成的速度，则无法保持备份一致性。redo log archive在备份启动时同步启动，备份结束时停止，此时可以利用redo log归档进行数据恢复。在启用redo log archive之...

查询归档空间存放路径_新特性速递 | InnoDB redo log archiving(归档)

weixin_29972227的博客

01-13

275

导读MySQL 8.0.17开始支持的redo log归档能干嘛用呢，好吃吗今天，MySQL 8.0.17发布了，看了下release note，发现果真如之前预期的那样，恢复了redo log归档(redo log archiving)功能。之所以说是“恢复”，那是因为在InnoDB非常古老的版本(MySQL 4.0.6之前的版本)才存在，之后就取消了，当时还支持redo log mirror...

MySQL 的 redo log 和 binlog 区别？

hixiaoyang的博客

06-05

878

MySQL的redo log和binlog主要区别：1) 层级不同 - redo log是InnoDB引擎层的物理日志，binlog是MySQL Server层的逻辑日志；2) 用途不同 - redo log用于崩溃恢复保证事务持久性，binlog用于主从复制和数据归档；3) 写入机制不同 - redo log循环写入，binlog追加写入。二者通过两阶段提交机制保证一致性，建议生产环境配置innodb_flush_log_at_trx_commit=1和sync_binlog=1确保数据安全。redo l

MySQL事务，从redo log、bin log、undo log说起...

Java Punk

07-20

1087

通过本讲，你将学到redo log、bin log、undo log日志系统的产生、释放过程，作用，以及与事务（ACID）的关系

【面试八股总结】MySQL日志：undo log、redo log、binlog

Chesnut.

09-04

1711

MySQL中存在三种日志： undo log（回滚日志）：是 Innodb 存储引擎层生成的日志，实现了事务中的原子性，主要用于事务回滚和 MVCC。 redo log（重做日志）：是 Innodb 存储引擎层生成的日志，实现了事务中的持久性，主要用于掉电等故障恢复； binlog （归档日志）：是 Server 层生成的日志，主要用于数据备份和主从复制。

【MySQL精通之路】InnoDB(6)-磁盘结构(5)-Redolog

Anakki的博客

05-20

1453

主博客：在正常操作过程中，重做日志对或进行编码。在和完成更新数据文件的有关重做日志在崩溃恢复中的作用的信息，请参阅“InnoDB恢复”。重做日志在磁盘上由物理表示。写入的数据是根据，这些数据统称为重做。通过的数据传输由不断增加的表示。重做日志数据会随着数据修改的进行而附加，

MySQL 8.0.17新特性-Redo日志归档功能

阮胜昌的专栏

04-19

608

功能作用：在备份操作进行期间，复制重做日志记录的备份实用程序有时可能无法跟上重做日志生成的步伐，从而导致由于这些记录被覆盖而丢失重做日志记录。当备份操作期间MySQL服务器有大量活动，并且重做日志文件存储介质的运行速度比备份存储介质快时，最常出现此问题。MySQL 8.0.17中引入的重做日志归档功能通过将重做日志记录顺序写入到除重做日志文件之外的归档文件来解决此问题。备份实用程序可以根据需要从归档文件中复制重做日志记录，从而避免潜在的数据丢失。如果在服务器上配置了重做日志存档，则MySQL Ente

MySQL8归档_MySQL8.0 redo log归档功能

weixin_30071787的博客

02-05

883

我们知道，在MySQL中，redo log是一个文件组，一般是3个文件，循环写入，写满的时候会做redo log层面的checkpoint，然后覆盖之前的redo log；而binlog是有归档功能的，每个binlog写满之后，都会重新开启下一个binlog开始写入，这也是为什么可以使用binlog来进行数据恢复的一个原因，就是因为它的归档功能。MySQL8.0.17中引入了redo log的归档...

MySQL中一条更新语句是如何执行的

weixin_30653097的博客

07-25

349

1、创建表的语句和更新的语句这个表的创建语句，这个表有一个主键ID和一个整型字段c： mysql> create table T(ID int primary key, c int); 如果要将ID=2这一行的值加1，SQL语句就会这么写： mysql> update T set c=c+1 where ID=2; 更...

redo的类型和作用

weixin_38168786的博客

07-29

220

　　重做日志(redo log)用来保证事务的持久性。实际上它可以分为以下两种类型：物理Redo日志、逻辑Redo日志；在InnoDB存储引擎中，大部分情况下Redo是物理日志，记录的是数据页的物理变化。而逻辑Redo日志，不是记录页面的实际修改，而是记录修改页面的一类操作，比如新建数据页时，需要记录逻辑日志。只需要记住绝大数情况下，Redo是物理日志即可，DML对页的修改操作，均需要记...

MySQL · 引擎特性 · InnoDB redo log

bohu83的博客

08-08

5325

一序本文根据《MYSQL运维内参》第11章INNODB日志管理机制整理，本篇书上侧重于原理说明日志的生成、格式、工作原理、刷盘机制等。限于篇幅，崩溃恢复的需要单独整理。InnoDB 有两块非常重要的日志，一个是undo log，另外一个是redo log，前者用来保证事务的原子性以及InnoDB的MVCC，后者用来保证事务的持久性。解释下redolog与事务持久性：redo l...

Linux + MySQL + Sysbench 一键部署和压测教程

soft2001525的博客

12-10

691

安装 Sysbench 并验证创建测试数据库sbtest和用户sbtest使用prepare构造数据表使用run进行各种类型压测使用cleanup清理数据分析每秒统计和最终汇总报告。

记一次Mysql数据删除生产事故处理

企业实战系列集 ●●● https://ximenjianxue.blog.youkuaiyun.com

12-12

815

从一次增删改操作开始：彻底理解 MySQL Buffer Pool 的地位与作用

soft2001525的博客

12-11

2036

它是 InnoDB 的核心内存引擎，是所有数据读写的唯一入口，是数据库性能与安全性的关键支撑。理解 Buffer Pool 的逻辑，你就理解了 MySQL 的一半。redo logundo log（事务回滚）MVCC脏页、刷盘策略自适应哈希索引B+树索引加载机制查询优化都与 Buffer Pool 有直接关系。如果你想系统搞懂 MySQL，从 Buffer Pool 开始是最佳路径。如果本篇文章对你有帮助，欢迎：✏️ 评论交流。

重装系统C盘格式化，MYSQL恢复

最新发布

2301_80082921的博客

12-14

139

背景：mysql在E盘，但是C盘重装系统，以前的注册表之类的都没有了，想重新恢复mysql的使用。2. 按照下面的步骤注册并启动服务。1. 配置以前的环境变量。

binlong redolog undolog

10-16

<think>嗯，用户现在想了解MySQL的三大日志：binlog、redolog和undolog的介绍、作用、原理等相关信息。首先，我需要回顾之前的引用内容，确保信息准确。引用[1]提到redolog保证持久性（ACID的D），undolog保证原子性，并且在MVCC中用于隔离性。引用[2]和[3]补充了binlog的设计目标和格式，比如statement、row、mixed三种格式。用户的需求是全面了解这三个日志的作用、原理等。需要分点整理，确保每个日志的介绍、作用、原理和关键点都涵盖清楚。首先，binlog是MySQL服务器层的逻辑日志，用于主从复制和数据恢复，记录SQL操作的逻辑。格式方面，statement记录SQL原文，row记录行变化，mixed是混合模式。而redolog是InnoDB存储引擎的物理日志，通过Write-Ahead Logging技术确保事务的持久性，循环写入，有缓冲区机制。undolog也是InnoDB层的日志，用于事务回滚和MVCC，记录数据变更前的镜像，形成版本链。需要注意三者之间的协同，比如事务提交时redolog和binlog的两阶段提交（2PC），避免数据不一致。同时，undolog在事务回滚和MVCC中的作用，如生成旧版本数据。还要提到日志的存储位置，binlog可能单独存储，redolog和undolog在ibdata文件中。应用场景方面，binlog用于备份恢复和主从复制，redolog用于崩溃恢复，undolog用于回滚和读一致性。用户可能关心它们的区别，比如层级（server vs engine）、内容（逻辑 vs 物理）、用途等。此外，需要澄清常见误区，比如redolog不是写入数据文件而是日志文件，undolog的清理机制（purge线程）。确保术语正确，如WAL、事务ID、rollback segment等。最后，总结时用表格对比三者的核心差异，帮助用户一目了然。还要检查是否有遗漏点，比如binlog的刷盘策略sync_binlog，redolog的刷盘策略innodb_flush_log_at_trx_commit，这些参数对性能的影响。确保原理部分准确，比如两阶段提交的流程，避免在崩溃时出现数据不一致的问题。整体结构要清晰，分块讲解后对比，保持语言流畅，避免技术错误。 </think>以下是MySQL三大日志（**binlog**、**redo log**、**undo log**）的对比解析，结合其作用、原理及协作逻辑： --- ### **1. binlog (归档日志)** - **作用** - **主从复制**：将数据变更同步到从库 - **数据恢复**：通过`mysqlbinlog`工具实现时间点恢复（Point-in-Time Recovery） - **审计**：记录所有更改数据库的SQL语句 - **原理** - **逻辑日志**：记录SQL语句原文（格式为`statement`）、或变更后的行数据（格式为`row`），或混合模式（`mixed`） - **写入时机**：事务提交时**一次性写入**（不同步写入可能导致数据丢失） - **存储方式**：追加写入文件（可配置大小上限和保留策略） - **关键点** - **Server层实现**：与存储引擎无关 - **三种格式**： - `statement`：记录SQL原文（如`UPDATE T SET update_time=NOW() WHERE id=1`） - `row`：记录行变更前后的值（数据量大但精准） - `mixed`：自动切换上述两种模式 --- ### **2. redo log (重做日志)** - **作用** - **崩溃恢复**：确保事务的**持久性（Durability）** - **缓冲优化**：减少随机写磁盘（将随机写转为顺序写） - **原理** - **物理日志**：记录数据页的物理修改（如“在表空间X的页面Y偏移量Z处写入数据”） - **Write-Ahead Logging (WAL)**： 1. 事务修改数据前，先写redo log到内存缓冲区（`redo log buffer`） 2. 事务提交时，将redo log刷盘（`fsync`）到`ib_logfile`文件 3. 后台线程异步将修改写入数据文件 - **循环覆盖写入**：固定大小文件（通常两个文件轮替） - **关键点** - **InnoDB引擎层实现** - **强制刷盘策略**： - `innodb_flush_log_at_trx_commit=1`：每次提交都刷盘（保证强持久性） - `0`或`2`：延迟刷盘（性能更高，但可能丢失事务） --- ### **3. undo log (回滚日志)** - **作用** - **事务回滚**：保证**原子性（Atomicity）**，用于`ROLLBACK` - **MVCC支持**：提供数据的历史版本，实现**隔离性（Isolation）** - **原理** - **逻辑日志**：记录数据修改前的镜像（如更新前值、删除前的整行数据） - **版本链构建**： - 每行记录隐藏字段`DB_TRX_ID`（事务ID）和`DB_ROLL_PTR`（回滚指针） - `DB_ROLL_PTR`指向undo log中该行的历史版本链表 - **读写分离**： - 读操作通过`ReadView`判断可见版本（避免脏读、不可重复读） - **关键点** - **存储位置**：存放在`ibdata`系统表空间中 - **清理机制**：事务提交后，undo log由后台`purge线程`回收 --- ### **三者的协作流程（以更新操作为例）** 1. **修改数据前**：生成undo log（记录旧值） 2. **执行修改**： - 内存中更新数据页 - 生成redo log（记录物理修改） 3. **事务提交**： - redo log刷盘（保证持久性） - binlog写入磁盘 - 两阶段提交（2PC）确保redo log与binlog一致性 4. **后台操作**： - 脏页写入磁盘 - 清理undo log（不再需要时） --- ### **对比总结** | **日志** | **层级** | **内容** | **核心作用** | **生命周期** | |------------|-------------|-------------|----------------------|--------------------| | **binlog** | MySQL Server | 逻辑日志 | 主从复制、数据恢复 | 长期保留（可配置） | | **redo log**| InnoDB引擎 | 物理日志 | 崩溃恢复、持久性 | 循环覆盖写入 | | **undo log**| InnoDB引擎 | 逻辑日志 | 事务回滚、MVCC支持 | 事务提交后异步清理 | > ⚠️ **关键协作**：通过**两阶段提交（2PC）** 确保binlog和redo log的一致性，避免主从不一致或数据丢失[^3]。 --- ### **相关问题** 1. 为什么需要两阶段提交（2PC）来协调binlog和redo log？ 2. undo log版本链如何实现MVCC的可重复读（RR）隔离级别？ 3. binlog的`row`格式与`statement`格式在数据安全性上有何差异？ 4. 如何配置MySQL的日志参数以平衡性能和数据可靠性？ [^1]: 原子性原理与MVCC实现 [^2]: binlog设计目标 [^3]: 日志协作机制与两阶段提交