1.MySQL 核心模块揭秘 | 12 期 | 创建 savepoint
2.Springboot之分布式事务框架Seata实现原理源码分析
3.详解 MySQL 的日志日志 undo log
4.PostgreSQL · 源码分析 · 回放分析（一）
5.MySQL 核心模块揭秘 | 13 期 | 回滚到 savepoint
6.[转载] 细说jbd （journal-block-device）& 源码分析

MySQL 核心模块揭秘 | 12 期 | 创建 savepoint

       回滚操作，除了回滚整个事务，源码还可以部分回滚。候删部分回滚，日志日志需要保存点（savepoint）的源码协助。本文我们先看看保存点里面都有什么。候删六仔程序源码

       作者：操盛春，日志日志爱可生技术专家，源码公众号『一树一溪』作者，候删专注于研究 MySQL 和 OceanBase 源码。日志日志 爱可生开源社区出品，源码原创内容未经授权不得随意使用，候删转载请联系小编并注明来源

       本文基于 MySQL 8.0. 源码，日志日志存储引擎为 InnoDB。源码

       InnoDB 的候删事务对象有一个名为undo_no 的属性。事务每次改变（插入、更新、删除）某个表的一条记录，都会产生一条 undo 日志。这条 undo 日志中会存储它自己的序号。这个序号就来源于事务对象的 undo_no 属性。

       也就是说，事务对象的 undo_no 属性中保存着事务改变（插入、更新、删除）某个表中下一条记录产生的 undo 日志的序号。

       每个事务都维护着各自独立的 undo 日志序号，和其它事务无关。

       每个事务的 undo 日志序号都从 0 开始。事务产生的第 1 条 undo 日志的序号为 0，第 2 条 undo 日志的序号为 1，依此类推。

       InnoDB 的 savepoint 结构中会保存创建 savepoint 时事务对象的 undo_no 属性值。

       我们通过 SQL 语句创建一个 savepoint 时，server 层、binlog、InnoDB 会各自创建用于保存 savepoint 信息的unity上层框架源码结构。

       server 层的 savepoint 结构是一个SAVEPOINT 类型的对象，主要属性如下：

       binlog 的 savepoint 结构很简单，是一个 8 字节的整数。这个整数的值，是创建 savepoint 时事务已经产生的 binlog 日志的字节数，也是接下来新产生的 binlog 日志写入 trx_cache 的 offset。

       为了方便介绍，我们把这个整数值称为binlog offset。

       InnoDB 的 savepoint 结构是一个trx_named_savept_t 类型的对象，主要属性如下：

       创建 savepoint 时，server 层会分配一块 字节的内存，除了存放它自己的 SAVEPOINT 对象，还会存放 binlog offset 和 InnoDB 的 trx_named_savept_t 对象。

       server 层的 SAVEPOINT 对象占用这块内存的前 字节，InnoDB 的 trx_named_savept_t 对象占用中间的 字节，binlog offset 占用最后的 8 字节。

       客户端连接到 MySQL 之后，MySQL 会分配一个专门用于该连接的用户线程。

       用户线程中有一个m_savepoints 链表，用户创建的多个 savepoint 通过 prev 属性形成链表，m_savepoints 就指向最新创建的 savepoint。

       server 层创建 savepoint 之前，会按照创建时间从新到老，逐个查看链表中是否存在和本次创建的 savepoint 同名的 savepoint。

       如果在用户线程的 m_savepoints 链表中找到了和本次创建的 savepoint 同名的 savepoint，需要先删除 m_savepoints 链表中的同名 savepoint。

       找到的同名 savepoint，是 server 层的SAVEPOINT 对象，它后面的内存区域分别保存着 InnoDB 的 trx_named_savept_t 对象、binlog offset。

       binlog 是个老实孩子，乖乖的把 binlog offset 写入了 server 层为它分配的内存里。删除同名 savepoint 时，不需要单独处理 binlog offset。

       InnoDB 就不老实了，gif图格式源码虽然 server 层也为 InnoDB 的 trx_named_savept_t 对象分配了内存，但是 InnoDB 并没有往里面写入内容。

       事务执行过程中，用户每次创建一个 savepoint，InnoDB 都会创建一个对应的 trx_named_savept_t 对象，并加入 InnoDB 事务对象的 trx_savepoints 链表的末尾。

       因为 InnoDB 自己维护了一个存放 savepoint 结构的链表，server 层删除同名 savepoint 时，InnoDB 需要找到这个链表中对应的 savepoint 结构并删除，流程如下：

       InnoDB 从事务对象的 trx_savepoints 链表中删除 trx_named_savept_t 对象之后，server 层接着从用户线程的 m_savepoints 链表中删除 server 层的SAVEPOINT 对象，也就连带着清理了 binlog offset。

       处理完查找、删除同名 savepoint 之后，server 层就正式开始创建 savepoint 了，这个过程分为 3 步。

       第 1 步，binlog 会生成一个 Query_log_event。

       以创建名为test_savept 的 savepoint 为例，这个 event 的内容如下：

       binlog event 写入 trx_cache 之后，binlog offset 会写入 server 层为它分配的 8 字节的内存中。

       第 2 步，InnoDB 创建 trx_named_savept_t 对象，并放入事务对象的 trx_savepoints 链表的末尾。

       trx_named_savept_t 对象的 name 属性值是 InnoDB 的 savepoint 名字。这个名字是根据 server 层为 InnoDB 的 trx_named_savept_t 对象分配的内存的地址计算得到的。

       trx_named_savept_t 对象的savept 属性，是一个 trx_savept_t 类型的对象。这个对象里保存着创建 savepoint 时，事务对象中 undo_no 属性的值，也就是下一条 undo 日志的序号。

       第 3 步，把 server 层的 SAVEPOINT 对象加入用户线程的 m_savepoints 链表的尾部。

       server 层会创建一个SAVEPOINT 对象，用于存放 savepoint 信息。快手批量获取源码

       binlog 会把binlog offset 写入 server 层为它分配的一块 8 字节的内存里。

       InnoDB 会维护自己的 savepoint 链表，里面保存着trx_named_savept_t 对象。

       如果 m_savepoints 链表中存在和本次创建的 savepoint 同名的 savepoint， 创建新的 savepoint 之前，server 层会从链表中删除这个同名的 savepoint。

       server 层创建的 SAVEPOINT 对象会放入m_savepoints 链表的末尾。

       InnoDB 创建的 trx_named_savept_t 对象会放入事务对象的trx_savepoints 链表的末尾。

Springboot之分布式事务框架Seata实现原理源码分析

       在Springboot 2.2. + Seata 1.3.0环境中，Seata通过GlobalTransactionScanner实现全局事务管理。首先，它会扫描带有@GlobalTransactional注解的方法类，作为BeanPostProcessor处理器，通过InstantiationAwareBeanPostProcessor的postProcessAfterInitialization方法中的wrapIfNecessary方法进行全局事务拦截。

       GlobalTransactionScanner判断类方法是否有@GlobalTransactional注解，如果没有则直接返回，否则创建GlobalTransactionalInterceptor。拦截器负责全局事务的执行，包括事务开始、执行本地业务、提交和回滚等步骤。例如，事务开始时，Seata通过SPI技术将xid绑定到当前线程，执行过程中会记录undo log以实现回滚。

       Seata自动配置会创建代理数据源（DataSourceProxy），在数据源方法调用时进行代理处理。当调用带有全局事务的方法时，如RestTemplate和Feign，拦截器会传递XID到请求头中，确保跨服务的事务一致性。参与者（被调用服务）通过SeataHandlerInterceptor拦截器获取并绑定XID，然后通过ConnectionProxy代理进行数据库操作，其中ConnectionContext用于判断是否为全局事务。

       总结来说，转换指标公式源码Seata的核心机制是通过代理、拦截器和XID的传递，确保分布式环境下的事务处理协调和一致性。

详解 MySQL 的 undo log

       详解MySQL的undo log

       undo log是InnoDB引擎中的一种关键日志，它在事务修改数据记录前，先行保存该记录的原始状态（before image），以便在修改过程中遇到错误时恢复原始数据或允许其他事务读取。undo log的两个主要作用在于提供事务的回滚能力和支持并发读取。

       在事务执行时，以下四种操作会生成undo log：插入、更新、删除和选择。在MySQL的不同版本中，undo log的存储方式也有所变化。在早期版本中，undo log与系统表空间共存于同一个表空间内，直到MySQL 5.6.3版本引入了将undo log表空间独立出来的特性。这一特性在MySQL 5.7版本中得到进一步强化，引入了在线truncating undo tablespace功能。MySQL 8.0版本进一步改进undo log机制，使其更易于管理和优化性能。

       undo log主要储存在单独的undo tablespace中，这个表空间定义了回滚段（rollback segments），用于存放undo log。undo tablespace的结构通过源代码中的定义得以揭示，其中包括了用于管理回滚段的结构体。回滚段进一步管理着Rollback Segment Header Page，以确保数据的高效管理和回滚操作。

       undo log可以分为insert undo log和update undo log两种类型。对于insert操作，undo log记录插入数据的ID，以便在事务回滚时精确删除；对于update操作，undo log记录修改前的数据，回滚时只需反向更新。而对于delete和select操作，由于它们不涉及数据的修改，因此不需要undo log来支持回滚。

       undo log的处理逻辑复杂，但通过构建undo log链条，可以高效地实现事务的回滚。当事务开始时，会记录所有修改前的数据到undo log中。当事务提交后，这些undo log可能仍保留在系统中，以备在需要时执行回滚操作。在事务执行期间，其他事务可以读取undo buffer缓存中的数据，从而实现并发读取。当事务回滚时，系统会从undo buffer中读取数据，而不是直接从磁盘读取，从而提高了性能和效率。

       总的来说，undo log在MySQL中扮演着至关重要的角色，它不仅保证了事务的原子性和一致性，还支持并发读取，提高了数据库的性能和可靠性。理解undo log的工作原理对于深入掌握MySQL的事务处理机制至关重要。

PostgreSQL · 源码分析 · 回放分析（一）

       在数据库运行中，可能遇到非预期问题，如断电、崩溃。这些情况可能导致数据异常或丢失，影响业务。为了在数据库重启时恢复到崩溃前状态，确保数据一致性和完整性，我们引入了WAL（Write-Ahead Logging）机制。WAL记录数据库事务执行过程，当数据库崩溃时，利用这些记录恢复至崩溃前状态。

       WAL通过REDO和UNDO日志实现崩溃恢复。REDO允许对数据进行修改，UNDO则撤销修改。REDO/UNDO日志结合了这两种功能。除了WAL，还有Shadow Pagging、WBL等技术，但WAL是主要方法。

       数据库内部，日志管理器记录事务操作，缓冲区管理器负责数据存储。当崩溃发生，恢复管理器读取事务状态，回放已提交数据，回滚中断事务，恢复数据库一致性。ARIES算法是日志记录和恢复处理的重要方法。

       长时间运行后崩溃，可能需要数小时甚至数天进行恢复。检查点技术在此帮助，将脏数据刷入磁盘，记录检查点位置，确保恢复从相对较新状态开始，同时清理旧日志文件。WAL不仅用于崩溃恢复，还支持复制、主备同步、时间点还原等功能。

       在记录日志时，WAL只在缓冲区中记录，直到事务提交时等待磁盘写入。LSN（日志序列号）用于管理，只在共享缓冲区中检查。XLog是事务日志，WAL是持久化日志。

       崩溃恢复中，checkpointer持续做检查点，加快数据页面更新，提高重启恢复速度。在回放时，数据页面不断向前更新，直至达到特定LSN。

       了解WAL格式和包含信息有助于理解日志内容。PG社区正在实现Zheap特性，改进日志格式。WAL文件存储在pg_wal目录下，大小为1GB，与时间线和LSN紧密关联。事务日志与WAL段文件相关联，根据特定LSN可识别文件名和位置。

       使用pg_waldump工具可以查看日志内容，理解一次操作记录。日志类型包括Standby、Heap、Transaction等，对应不同资源管理器。PostgreSQL 包含种资源管理器类型，涉及堆元组、索引、序列号操作。

       标准记录流程包括：读取数据页面到frame、记录WAL、进行事务提交。插入数据流程生成WAL，复杂修改如索引分裂需要记录多个WAL。

       崩溃恢复流程从控制文件中获取检查点位置，严格串行回放至崩溃前状态。redo回放流程与记录代码高度一致。在部分写问题上，FullPageWrite（FPW）策略记录完整数据页面，防止损坏。WAL错误导致部分丢失不影响恢复，数据库会告知失败。磁盘静默错误和内存错误需通过冗余校验解决。

       本文总结了数据库崩溃恢复原理，以及PostgreSQL日志记录和崩溃恢复实现。深入理解原理可提高数据库管理效率。下文将详细描述热备恢复和按时间点还原（PITR）方法。

MySQL 核心模块揭秘 | 期 | 回滚到 savepoint

       深入理解 MySQL，了解如何实现部分回滚操作。本文由技术专家操盛春撰写，他在公众号『一树一溪』分享 MySQL 和 OceanBase 源码研究。本文基于 MySQL 8.0.，InnoDB 存储引擎，探讨核心模块的工作原理。

       首先，我们创建测试表并插入数据。关键操作分为四个阶段，编号为 SQL 1 至 SQL 4，其中 SQL 4 是讨论焦点。SQL 2 和 SQL 3 分别产生 undo 日志 0 和 1。

       当执行事务时，产生的 binlog 日志在 trx cache 中。回滚整个事务时，需要清除这些日志。然而，实际操作中，binlog 回滚步骤看似简单，却并未执行真正清除，只是为后续的 InnoDB 回滚做准备。

       InnoDB 回滚是关键环节，它会根据 undo 日志执行反向操作，恢复事务影响的数据。以 SQL 为例，会从最新的 undo 日志开始回滚，逐条执行反向操作，包括记录的删除。

       回滚后，事务的执行状态需要通过提交事务来更新。这不同于 commit 语句，因为回滚操作已经改变了数据，即使从逻辑上看恢复了原样，也需要将 InnoDB 中的修改正式提交。

       trx cache 中的 binlog 日志会在 InnoDB 回滚完成后进行清除，这个过程涉及内存 buffer 和磁盘临时文件。binlog 回滚步骤延迟到这个阶段，是因为在事务提交前，binlog 日志并不需要写入持久化存储。

       总结起来，MySQL 的部分回滚包括：无实际动作的 binlog 回滚，执行 InnoDB 回滚恢复数据，然后提交 InnoDB 事务，最后清理 trx cache 中的临时 binlog。如果你对文中内容有疑问，欢迎留言交流。

       对于 SQL 质量管理，如需更多工具支持，可以了解 SQLE，一个覆盖开发到生产环境的 SQL 管理平台，提供流程自动化和数据质量管理功能。

[转载] 细说jbd （journal-block-device）& 源码分析

       jbd 要解决什么问题

       文件系统某些操作抽象成原子操作

       若干个原子操作组成一个事务

       在磁盘上单独划分一个日志空间

       将内存事务的数据写到日志中

       从日志恢复数据

       概念介绍

       buffer_head 元数据块

       handle transaction journal commit checkpoint revoke recover kjournald

       数据结构介绍

       handle_t 表示一个原子操作

       transaction_t 表示一个事务

       journal_t journal_superblock_t journal_head journal_head_t

       三种日志模式

       jbd基本操作

       journal_start journal_stop journal_get_create_access journal_get_write_access journal_get_undo_access

       journal_dirty_data journal_dirty_metadata journal_forget journal_revoke journal_extend

       元数据缓冲区处理流程

       数据缓冲区处理流程

       提交事务kjournald----- 时刻准备着

       fs/jbd/journal.c

       提交事务

       journal_commit_transaction __journal_clean_checkpoint_list journal_submit_data_buffers

       fs/jdb/commit.c

       journal_write_revoke_records journal_write_metadata_buffer journal_write_commit_record

       数据块缓冲区状态转移图

       元数据块缓冲区状态转移图

       日志恢复

       准备工作

       journal_recover 函数

       恢复步骤1： PASS_SCAN

       恢复步骤2：PASS_REVOKE

       恢复步骤3：PASS_REPLAY

       恢复后的设置工作