xx

src/content/posts/中间件/MySQL/MySQL-binlog.md

@@ -0,0 +1,39 @@
+---
+title: MySQL-binlog
+published: 2025-09-16
+description: ''
+image: ''
+tags: [MYSQL,binlog,MySQL]
+category: '中间件 > MySQL'
+draft: false 
+lang: ''
+---
+
+![](https://blog.meowrain.cn/api/i/2025/09/16/11ci8hc-1.webp)
+# binlog（二进制日志）
+二进制日志主要用于记录所有针对数据库表结构的变更
+以及对表数据的修改操作，不包括SELECT,SHOW等读取类的操作。
+Binlog是在事务提交成功以后，在服务层生成的日志文件
+
+作用：
+1. 数据恢复： 通过详尽的记录所有影响数据状态的SQL命令，binlog为从特定时间点或者由于意外操作导致的数据丢失提供了恢复手段。一旦发生数据损坏或者丢失事件，可以通过重放binlog中的历史更改来恢复到先前的状态。
+2. 主从复制： 对于需要跨多台服务器实现数据备份的应用场景，binlog提供了基础。通过将主服务器的binlog传输到从服务器，从服务器可以重放这些日志以实现数据的同步。
+
+# binlog格式类型
+MySQL支持三种类型的binlog格式：
+`STATEMENT`,`ROW`和`MIXED `
+
+- STATEMENT模式： 在这个模式下，每一条引起数据变化的SQL语句都会被记录下来。这种方式的优点在于减少了日志大小并且提高了处理速度。
+然而，如果使用了SYSDATE（），NOW()之类的非确定性函数，就有可能导致在执行数据恢复或主从复制过程中产生一致性问题。
+
+- ROW模式： 与记录整个SQL不同，ROW模式仅追踪实际受到影响的数据行的变化情况。这种方法避免了STATEMENT模式下的动态内容带来的挑战，但是代价是增加了日志文件的体积
+
+- MIXED模式： 前两者的折中方案。根据具体情况自动选择最合适的记录方式。当系统认为STATEMENT更优的时候，使用STATEMENT模式；当系统认为ROW更优的时候，使用ROW模式。
+
+
+# 记录方式
+![](https://blog.meowrain.cn/api/i/2025/09/16/11buhw1-1.webp)
+
+# 主从复制
+
+![](https://blog.meowrain.cn/api/i/2025/09/16/11c1t5t-1.webp)

src/content/posts/中间件/MySQL/MySQL-redolog.md

@@ -0,0 +1,39 @@
+---
+title: MySQL-redolog
+published: 2025-09-16
+description: ''
+image: ''
+tags: [MYSQL,redolog,MySQL]
+category: '中间件 > MySQL'
+draft: false 
+lang: ''
+---
+![](https://blog.meowrain.cn/api/i/2025/09/16/11ci8hc-1.webp)
+# Redo Log（实现持久化）
+在InnoDB存储引擎中，大部分Redo Log记录的是物理日志，也就是对特定数据页进行的具体修改。
+那么为啥要称呼它为大部分是物理日志呢？是因为Redo Log系统由两部分构成：
+- 一是位于内存中的重做日志缓冲区（redolog buffer），这部分信息容易因为断电等原因丢失。
+- 二是保存于磁盘上的重做日志文件（redolog file）提供持久化存储
+
+## 引入redo log的必要性
+尽管buffer pool确实极大提升了数据库操作的性能，但是由于它基于内存的特点，存在着固有的不稳定性，一旦发生系统崩溃或断电等故障，内存中的数据就可能会丢失。为了避免这种情况，Redo Log应运而生。
+通过与buffer pool和change buffer协同工作，redolog负责记录所有尚未同步到磁盘的更改操作，确保即使发生故障重启以后也能恢复这些更新，直到相关页面被最终安全地写入到磁盘为止。
+
+![](https://blog.meowrain.cn/api/i/2025/09/16/10r7qnc-1.webp)
+
+## redo log和undo log之间的差异
+
+- Redo Log专注于 记录事务完成后的新状态，也就是变更后的值
+- Undo Log用来追踪事务开始前的原始状态，保存的是变更前的旧值
+
+![](https://blog.meowrain.cn/api/i/2025/09/16/10uklpi-1.webp)
+
+![](https://blog.meowrain.cn/api/i/2025/09/16/10wvrf2-1.webp)
+
+![](https://blog.meowrain.cn/api/i/2025/09/16/10xmq2l-1.webp)
+
+![](https://blog.meowrain.cn/api/i/2025/09/16/10xp98x-1.webp)
+
+
+## 崩溃恢复
+![](https://blog.meowrain.cn/api/i/2025/09/16/10xs9rk-1.webp)

src/content/posts/中间件/MySQL/MySQL-relaylog.md

@@ -0,0 +1,21 @@
+---
+title: MySQL-relaylog
+published: 2025-09-16
+description: ''
+image: ''
+tags: [MYSQL,relaylog,MySQL]
+category: '中间件 > MySQL'
+draft: false 
+lang: ''
+---
+# Relay Log（中继日志）
+
+中继日志（relay log）只在主从服务器架构的从服务器上存在。从服务器（slave）为了与主服务器(Master)保持一致，要从主服务器读取二进制日志的内容，并且把读取到的信息写入本地的日志文件中，这个从服务器本地的日志文件就叫中继日志。然后，从服务器读取中继日志，并根据中继日志的内容对从服务器的数据进行更新，完成主从服务器的数据同步。
+
+搭建好主从服务器之后，中继日志默认会保存在从服务器的数据目录下。
+
+文件名的格式是：从服务器名 - relay-bin.序号。中继日志还有一个索引文件：从服务器名 - relay-bin.index，用来定位当前正在使用的中继日志。
+
+![](https://blog.meowrain.cn/api/i/2025/09/16/11ci8hc-1.webp)
+
+![](https://blog.meowrain.cn/api/i/2025/09/16/11d3ogv-1.webp)

src/content/posts/中间件/MySQL/MySQL-undolog.md

@@ -0,0 +1,35 @@
+---
+title: MySQL-undolog（回滚日志）
+published: 2025-09-16
+description: ''
+image: ''
+tags: [MYSQL,undolog,MySQL]
+category: '中间件 > MySQL'
+draft: false 
+lang: ''
+---
+![](https://blog.meowrain.cn/api/i/2025/09/16/11ci8hc-1.webp)
+# 回滚日志 Undo Log
+
+回滚日志是数据库引擎层生成的一种日志，主要用于确保事务的ACID特性中的`原子性`。它记录的是逻辑操作，也就是**数据在被修改之前的状态。** 
+这些逻辑操作包括 插入，删除和更新
+
+## 主要功能
+1. 事务回滚： 当事务需要回滚的时候，通过执行undo log记录的逆向操作来恢复到事务开始前的数据状态
+2. 多版本并发控制 MVCC： 结合ReadView机制，利用undo log实现多版本并发控制，从而支持高并发读写操作
+
+## 记录内容
+![](https://blog.meowrain.cn/api/i/2025/09/16/u7dxwr-1.webp)
+
+![](https://blog.meowrain.cn/api/i/2025/09/16/u80n69-1.webp)
+
+## 事务回滚
+每条记录在进行更新操作的时候，产生的undo日志都包含一个roll_pointer指针和一个trx_id事务标识符。
+- trx_id用于识别对特定记录执行修改的操作的具体事务
+- roll_pointer 则允许把一系列相关的undolog日志链接起来形成所谓的**版本链**
+
+![](https://blog.meowrain.cn/api/i/2025/09/16/ua6n2r-1.webp)
+
+当某一个事务需要回滚的时候，并不是通过逆向执行SQL语句来恢复数据状态的，而是依据事务中roll_pointer指向的undolog日志条目来进行数据复原。
+
+![](https://blog.meowrain.cn/api/i/2025/09/16/vqnibz-1.webp)