MYSQL: redo log 和 bin log 的区别，非常重要，很多人都不清楚。

原创已于 2025-11-18 10:51:53 修改 · 87 阅读

0 ·

CC 4.0 BY-SA版权

文章标签：

#数据库

于 2025-11-14 15:42:25 首次发布

rodo log 二阶段提交： redo log 是innodb存储引擎的级的.

binlog是MySQL服务层产生的日志，每个线程有独立的缓存，在事务提交时才写入磁盘(fsync行为依赖 sync_binlog 设置)，无法进行回滚，是逻辑的日志，记录行的改变或SQL语句。
参数 sync_binlog 控制 binlog的写入。

redo日志(WAL)是InnoDB存储引擎产生的日志，在事务的执行过程中一直会产生，所有线程共享内存缓存(innodb_log_buffer_size)，事务提交时会进行刷盘操作(fsync行为依赖 innodb_flush_log_at_trx_commit 设置)，
同时也会将没提交的事务日志顺带写入磁盘，写了redo的事务也能回滚。

参数 innodb_flush_log_at_trx_commit 控制redo log 的写入。

binlog和redo是由不同的子系统产生的，两个子系统怎么协调，以保证binlog和redo的数据一致性呢？
在分布式系统中，MySQL通过分布式事务(innodb_support_xa=1，8.0默认使用)来解决两者的一致性问题，在事务提交时，redo先写prepare 日志，并做刷盘，然后写binlog，并刷盘，binlog写成功后，再进行写redo commit日志。

将binlog的写分为三个阶段：flush，sync，commit。

binlog_group_commit_sync_delay，等待多少微秒后才进行fsync；

binlog_group_commit_sync_no_delay_count，达到等待的事务数量后调用fsync操作,

如果binlog_group_commit_sync_delay为0，此参数不生效；

GTID:

transaction_id 是在该主库上生成的事务序列号，从1开始，1-2代表第二个事务；第1-n代表第n个事务。

1为这个节点上提交的第1个事务的事务号，如果提交了10个事务，GTID会是这样： 3E11FA47-71CA-11E1-9E33-C80AA9429562:1-10

一般在主从复制的场景下，如果只有单台就没必要使用GTID了。
一个 GTID 在一个服务器上只执行一次，避免重复执行导致数据混乱或者主从不一致。
GTID是连续的没有空洞的，保证数据的一致性，零丢失
之前binlog中的所有gtid都会被加入mysql.gtid_executed表中
select * from mysql.gtid_executed;

-- 查看从库已接收的 GTID 集合（从主库获取但未执行/已执行的）
show slave status like 'Retrieved_Gtid_Set';

-- 查看从库已执行的 GTID 集合
show slave status like 'Executed_Gtid_Set';

-- 查看主库当前已执行的 GTID 集合
show master status; -- 结果中包含 Executed_Gtid_Set

在 GTID 复制架构中，MASTER_AUTO_POSITION = 1（启用）时，从库会通过以下逻辑自动完成同步定位：
从库向主库发送自身已执行的 GTID 集合（Executed_Gtid_Set）；
主库对比自身已执行的 GTID 集合，找出从库未执行的所有事务；
主库从这些未执行事务的第一个开始，向从库推送二进制日志；
从库接收并执行日志，自动完成同步，无需人工干预。
简单说：启用后，从库会 “告诉” 主库 “我已经执行到哪了”，主库自动 “补送” 未执行的事务。

MASTER_AUTO_POSITION = 1; -- 1=启用自动定位（GTID模式必选）
-- 或 MASTER_AUTO_POSITION = 0; -- 0=禁用（默认，需手动指定 File+Pos）

Retrieved_Gtid_Set（已接收的 GTID）、Executed_Gtid_Set（已执行的 GTID）

在 GTID 复制架构中，MASTER_AUTO_POSITION = 1（启用）时，从库会通过以下逻辑自动完成同步定位：
从库向主库发送自身已执行的 GTID 集合（Executed_Gtid_Set）；
主库对比自身已执行的 GTID 集合，找出从库未执行的所有事务；
主库从这些未执行事务的第一个开始，向从库推送二进制日志；
从库接收并执行日志，自动完成同步，无需人工干预。

简单说：启用后，从库会 “告诉” 主库 “我已经执行到哪了”，主库自动 “补送” 未执行的事务。

Retrieved_Gtid_Set（已接收的 GTID）、Executed_Gtid_Set（已执行的 GTID）

gtid_purged 存储的是：当前实例的二进制日志（binlog）中已被物理删除的所有事务对应的 GTID 集合。

简单理解：
主库会定期清理过期的 binlog（通过 expire_logs_days 或手动执行 PURGE BINARY LOGS）；
被清理的 binlog 对应的事务 GTID，会被添加到 gtid_purged 中；
gtid_purged 是一个 “只读变量”（无法直接手动修改，仅由系统自动更新），

可通过 show variables like 'gtid_purged'; 查看。

gtid_purged | 3E11FA47-71CA-11E1-9E33-C80AA9429562:1-10
第 1-10 号事务对应的 binlog 已被清理，这些 GTID 对应的日志文件在当前实例中已不存在。