Redo Log 和 Binlog 的区别是什么？

Redo Log 和 BinLog 是 MySQL 中两种重要的日志，它们的区别如下：

功能

• Redo Log 主要用于实现事务的持久性，确保在数据库发生故障（如停电、系统崩溃等）时，能够恢复未完成事务对数据的修改，从而保证数据不会丢失。
• BinLog 则用于记录数据库的变更操作，包括数据的插入、更新和删除等，主要用于数据备份、主从复制和数据恢复等场景。

写入方式

• Redo Log 是循环写入的，空间固定大小，写满时会覆盖旧的日志。
• BinLog 可以通过配置来控制文件大小，当达到一定大小或其他条件时，会生成新的文件进行续写。

存储位置

• Redo Log 是存储在 InnoDB 存储引擎特有的文件中。
• BinLog 是存储在服务器级别的日志文件中。

写入时机

redo log 写入时机（InnoDB 存储引擎层面）

在事务执行过程中：

1. 事务中的操作会先在内存中的 redo log buffer（重做日志缓冲）中记录相应的 redo log 条目。 以下是后续几种触发刷到磁盘（redo log 文件）的情况：

• 由参数innodb_flush_log_at_trx_commit控制：
  • 当设置为 1（默认）：每次事务提交时都将 redo log buffer 中的 redo log 强制持久化到磁盘。
  • 当设置为 0：每次事务提交的时候都只是把 redo log 留在 redo log buffer 中；后台线程每隔 1s 进行一次刷盘操作，但如果 MySQL 进程崩溃可能丢失 1s 内的事务日志 。
  • 当设置为 2 ：每次事务提交时都只是把 redo log 写到 page cache（文件系统缓存），由操作系统决定何时刷到磁盘；如果 MySQL 进程崩溃，操作系统不崩溃则数据不会丢失，但如果系统崩溃则可能丢失 1s 内的数据（因为后台线程 1s 刷新一次）。
• 当 redo log buffer 占用的空间即将达到innodb_log_buffer_size一半的时候，后台线程会主动写盘（write，没有 fsync）。
• 并行的事务提交的时候，顺带将这个事务的 redo log buffer 持久化到磁盘（事务 a 执行一半，部分 redo log 到 buffer 中；事务 b 提交，且 innodb_flush_log_at_trx_commit 设置为 1 或 2，会把 redo log buffer 里的 log 全部持久化到磁盘中）。

binlog 写入时机

1. 在事务执行期间：
   • 先把日志写到 binlog cache（每个线程都有自己的 binlog cache，binlog cache 大小由参数binlog_cache_size控制，如果超过了这个大小就要暂存磁盘）。
2. 在事务提交时：
   • 执行器把 binlog cache 里完整的事务写入 binlog 文件中，并清空 binlog cache。

• • 由参数sync_binlog控制真正刷盘（write 后进行 fsync）的时机：
    • 当 sync_binlog = 0 时，每次提交事务都只 write，不 fsync；如果操作系统崩溃，可能丢失部分事务的 binlog 。
    • 当 sync_binlog = 1 时，每次提交事务都会执行 fsync，保证 binlog 完整持久化；这是最安全但性能相对低的方式。
    • 当 sync_binlog = n（n > 1）时，表示每次提交事务都 write，但累积 n 个事务后才 fsync；这种方式可以减少磁盘 IO 操作次数提升性能，但如果主机发生异常重启，会丢失最近 n 个事务的 binlog 日志。