标签： redo

发布于

`InnoDB` `Redo Log` 的`物理`写入与`逻辑`写入：`redo log buffer` 与 `ib_logfile` 的关系。

InnoDB Redo Log 的物理写入与逻辑写入：Redo Log Buffer 与 ib_logfile 的关系 大家好，今天我们深入探讨 InnoDB 存储引擎中至关重要的概念：Redo Log。我们会详细讲解 Redo Log 的物理写入与逻辑写入，以及 Redo Log Buffer 和 ib_logfile 之间的关系。理解这些概念对于理解 InnoDB 的事务处理、崩溃恢复和性能优化至关重要。 1. Redo Log 的作用与必要性 InnoDB 是一个事务型的存储引擎，它必须保证 ACID (Atomicity, Consistency, Isolation, Durability) 特性。其中，Durability（持久性）是指一旦事务提交，其对数据库的更改必须永久保存，即使发生系统崩溃也不会丢失。 然而，直接将每次事务的更改写入磁盘上的数据文件（例如 .ibd 文件）会带来严重的性能问题： 随机 I/O： 事务的更改可能涉及多个分散的数据页，这会导致大量的随机 I/O 操作，磁盘寻道时间会成为性能瓶颈。 写入放大： 即使只修改了数据页中的少量字节，也需要将整个数据 …

继续阅读“`InnoDB` `Redo Log` 的`物理`写入与`逻辑`写入：`redo log buffer` 与 `ib_logfile` 的关系。”

发布于

`Redo Log` 的`Group Commit`机制：它如何批量提交事务以提升写入性能？

Redo Log 的 Group Commit 机制：批量提交事务以提升写入性能 大家好，今天我们来深入探讨数据库系统中一个非常重要的优化技术：Redo Log 的 Group Commit 机制。它通过批量提交事务，显著提升数据库的写入性能，尤其在高并发场景下效果更为明显。 1. Redo Log 基础 首先，我们需要理解 Redo Log 的作用。Redo Log 是一种预写式日志(Write-Ahead Logging, WAL)，它记录了对数据库进行的修改操作。当数据库系统发生故障时，可以通过 Redo Log 将数据库恢复到一致的状态。 简单来说，当一个事务修改了数据页，数据库首先将修改操作记录到 Redo Log 中，然后才将修改刷新到磁盘上的数据页。这种先写日志，后写数据的机制，保证了即使在数据页尚未完全写入磁盘时发生崩溃，也能通过 Redo Log 恢复数据，从而保证了ACID特性中的持久性(Durability)。 Redo Log 的基本结构： LSN (Log Sequence Number): 每个 Redo Log 记录都有一个唯一的 LSN，它是一个递增的序 …

继续阅读“`Redo Log` 的`Group Commit`机制：它如何批量提交事务以提升写入性能？”

发布于

MySQL存储引擎内部之：`InnoDB`的`Redo Log`：其在`WAL`（`Write-Ahead Logging`）机制中的持久化原理。

好的，我们开始今天的讲座，主题是MySQL InnoDB存储引擎的Redo Log，以及它在WAL（Write-Ahead Logging）机制中的持久化原理。 一、Redo Log的作用与必要性 在数据库系统中，为了保证事务的ACID特性（原子性、一致性、隔离性、持久性），特别是持久性，需要将数据变更可靠地写入磁盘。然而，直接将每次数据变更都同步写入磁盘会带来严重的性能问题，因为磁盘IO速度远低于内存。为了解决这个问题，InnoDB引入了Redo Log。 Redo Log的核心思想是：将所有对数据页的修改，先写入一个专门用于记录变更的日志文件（Redo Log），然后再异步地将这些修改刷新到磁盘上的数据文件中。这样，即使数据库在数据页尚未刷新到磁盘时发生崩溃，也可以通过Redo Log在重启后恢复未完成的事务。 Redo Log的必要性体现在以下几个方面： 性能优化: 将随机磁盘写转化为顺序磁盘写，显著提升IO性能。 数据一致性: 保证即使在崩溃的情况下，数据库也能恢复到一致的状态。 减少锁竞争: 减少对数据页的直接锁定，提高并发性能。 二、WAL（Write-Ahead Logg …

继续阅读“MySQL存储引擎内部之：`InnoDB`的`Redo Log`：其在`WAL`（`Write-Ahead Logging`）机制中的持久化原理。”

发布于

MySQL架构与底层原理之：`InnoDB`的`redo log`：其在崩溃恢复中的`WAL`（`Write-Ahead Logging`）机制。

InnoDB Redo Log：崩溃恢复的基石 各位朋友，大家好！今天我们来深入探讨MySQL InnoDB存储引擎中一个至关重要的组件：redo log。理解redo log对于理解InnoDB的事务处理、崩溃恢复机制至关重要，它也是我们常说的WAL（Write-Ahead Logging）的核心实现。 1. 为什么需要 Redo Log？ 首先，我们思考一个问题：MySQL如何保证数据的一致性和持久性？如果每次修改数据都直接同步刷盘，性能会非常低下。磁盘I/O速度远低于内存操作速度。为了解决这个问题，InnoDB引入了缓冲池（Buffer Pool）机制。 缓冲池（Buffer Pool）： InnoDB会将数据页缓存在内存中，所有读写操作都在缓冲池中进行。这样可以显著提高性能。 但是，仅仅依靠缓冲池存在一个潜在的风险：如果数据库服务器突然崩溃，缓冲池中的数据尚未刷新到磁盘，就会导致数据丢失，破坏数据一致性。 这时候，redo log就派上用场了。它的核心作用是： 记录对数据页的修改： 当InnoDB修改缓冲池中的数据页时，会首先将修改操作记录到redo log中，然后再异步地将缓 …

继续阅读“MySQL架构与底层原理之：`InnoDB`的`redo log`：其在崩溃恢复中的`WAL`（`Write-Ahead Logging`）机制。”

发布于

MySQL高阶讲座之：`Redo Log`的`Group Commit`机制：如何减少事务提交时的`IO`开销。

各位观众老爷们，大家好！我是今天的主讲人，今天咱们聊聊MySQL里一个听起来高大上，但其实挺接地气的技术——Redo Log的Group Commit机制。这玩意儿说白了，就是MySQL为了提高性能，减少磁盘IO压力使出的一个“抱团取暖”的招数。 一、Redo Log：数据安全的守护神 在深入Group Commit之前，咱们得先搞明白Redo Log是干嘛的。想象一下，你辛辛苦苦改了一堆数据，正准备提交，突然服务器崩了！如果没有Redo Log，这些数据就丢失了。Redo Log的作用就像一个“后悔药”，它记录了数据页上的修改信息，即使服务器崩溃，重启后也能根据Redo Log恢复到崩溃前的状态，保证数据的持久性。 简单来说，Redo Log就是为了解决WAL（Write-Ahead Logging）问题，即先写日志，再写数据。这样即使数据库崩溃，也能通过日志进行恢复。 二、事务提交的IO风暴 每次事务提交，都涉及到以下几个步骤： 生成Redo Log：记录事务的修改信息。 将Redo Log写入Redo Log Buffer：内存中的一块缓冲区。 将Redo Log Buffer的 …

继续阅读“MySQL高阶讲座之：`Redo Log`的`Group Commit`机制：如何减少事务提交时的`IO`开销。”

发布于

MySQL高级讲座篇之：MySQL崩溃恢复：`Redo Log`与`Undo Log`的恢复之旅。

各位观众老爷们，大家好！今天咱们聊点刺激的，聊聊MySQL的“起死回生术”——崩溃恢复。 想象一下，你正在玩一个紧张刺激的游戏，眼看就要通关了，突然电脑蓝屏了！心态崩了？别急，MySQL也有可能遇到类似的情况，比如服务器突然断电、系统崩溃等等。但MySQL可比咱们的游戏聪明多了，它有两大法宝：Redo Log（重做日志）和 Undo Log（撤销日志），能让它在崩溃后恢复到安全状态，最大程度地减少数据丢失。 今天咱们就来一场“Redo Log”与“Undo Log”的恢复之旅，看看MySQL是如何靠它们起死回生的。 一、什么是Redo Log？为什么要它？ 简单来说，Redo Log就是MySQL记录“我要做什么”的日记本。它记录的是物理级别的修改，也就是“把哪个页面的哪个字节改成什么”。 为什么需要Redo Log？ 假设你执行一个更新语句：UPDATE users SET age = 30 WHERE id = 1; 这个操作可能涉及到多个步骤： 找到 id = 1 的那一行数据所在的页。 修改该页面的数据。 将修改后的页面刷盘（写入磁盘）。 问题来了：如果数据库在第2步完成，但第 …

继续阅读“MySQL高级讲座篇之：MySQL崩溃恢复：`Redo Log`与`Undo Log`的恢复之旅。”

发布于

MySQL高级讲座篇之：Binlog与Redo Log的协同：揭示MySQL数据持久化的双重保障。

各位观众老爷，大家好！今天咱们不聊风花雪月，只谈MySQL的“内功心法”——Binlog与Redo Log的协同。这俩哥们儿是MySQL数据持久化的左膀右臂，少了谁都不行。咱们今天就来扒一扒它们的底裤，看看它们是如何保证数据不丢的。 一、开场白：数据，数据库的命根子！ 数据库是干啥的？存数据的呗！如果数据丢了，那数据库就可以关门大吉了。所以，数据持久化是数据库的头等大事。想象一下，你辛辛苦苦玩游戏，好不容易打到99级，结果服务器一宕机，数据全没了，直接回到新手村，心态崩不崩？ MySQL为了避免这种惨剧发生，搞出了Binlog和Redo Log这两大法宝。它们就像一对默契的搭档，一个负责记录“发生了什么”，一个负责“怎么做”。 二、主角登场：Binlog和Redo Log，闪亮登场！ 先简单介绍一下这两位主角： Binlog（Binary Log）： 二进制日志，记录了所有对数据库修改的SQL语句（或者是row模式下的数据变更）。你可以把它想象成一个详细的“操作日志”，记录了你对数据库做的所有事情，比如“插入一条数据”、“更新一行记录”、“删除一个表”等等。 Redo Log： 重做日 …

继续阅读“MySQL高级讲座篇之：Binlog与Redo Log的协同：揭示MySQL数据持久化的双重保障。”

发布于

InnoDB Redo Log（重做日志）的刷盘机制与性能影响（`innodb_flush_log_at_trx_commit`）

好的，各位观众老爷，大家好！我是你们的老朋友，一位在代码江湖摸爬滚打多年的老码农。今天咱们不聊那些高大上的分布式架构，也不谈深奥难懂的机器学习，咱们就聊聊数据库里一个看似不起眼，但却至关重要的家伙——InnoDB 的 Redo Log（重做日志），以及它那神秘的刷盘机制，还有那个让人又爱又恨的参数：innodb_flush_log_at_trx_commit。 准备好了吗？系好安全带，咱们的数据库之旅即将开始！🚀 一、Redo Log：数据库的后悔药？不，是救命稻草！ 想象一下，你正在写一封情书，文思泉涌，下笔如有神。突然，停电了！电脑黑屏，你辛辛苦苦敲了半天的文字瞬间灰飞烟灭，那种感觉，是不是想死的心都有了？💔 数据库也一样。它需要处理大量的事务，每个事务都可能涉及到数据的修改。如果没有一个可靠的机制来保证数据的完整性，一旦服务器突然崩溃，那些还没来得及写入磁盘的数据就会丢失，数据库就彻底崩溃了。 这时候，Redo Log 就闪亮登场了！它就像数据库的救命稻草，或者说，是数据库的“时光机”。 Redo Log 的作用，简单来说，就是记录数据库中每个事务对数据所做的修改。 它不是直接记 …

继续阅读“InnoDB Redo Log（重做日志）的刷盘机制与性能影响（`innodb_flush_log_at_trx_commit`）”

发布于

理解 Redo Log 文件组与循环写入机制

好的，各位靓仔靓女们，欢迎来到老码农的深夜课堂！今天咱们要聊聊数据库里一个既神秘又至关重要的角色——Redo Log，以及它那如同永动机般循环写入的机制。 Redo Log：数据库的时光机与后悔药 想象一下，你正在用 Photoshop 辛辛苦苦地 P 图，突然！电脑蓝屏了！😱 辛辛苦苦的成果瞬间灰飞烟灭，是不是想砸电脑的心都有了？ 别慌，如果你的 Photoshop 足够智能，它会告诉你：“别怕，我保存了你的操作记录！下次启动我还能帮你恢复！” Redo Log 在数据库里扮演的角色，就类似于 Photoshop 的操作记录。 它可以被看作是数据库的“时光机”和“后悔药”。 它的主要作用是记录数据库中发生的每一次更改。 记录的内容可不是你修改后的数据本身，而是告诉你“你在哪个时间，对哪个表的哪一行，做了什么样的修改”。 为什么需要 Redo Log？ 你可能会想，数据库不是可以直接把数据修改写入磁盘吗？为什么还要多此一举，先写一遍 Redo Log 呢？ 这就好比你盖房子，直接往地基上垒砖当然快，但是万一地基不稳，房子塌了，一切都白费。 Redo Log 的存在，就是为了解决数据库面 …

继续阅读“理解 Redo Log 文件组与循环写入机制”