Mysql三个日志的作用及区别

知识背景

提到mysql，常常会提到它的三种日志，Redo Logs, Binlog以及Undo Logs .

这三种日志的用途具体是什么？以及有什么样的区别，在接下去的文章当中就能看明白。

一、什么是Redo Logs？

定义： Redo logs是InnoDB存储引擎使用的一种日志文件，记录了对数据库缓冲池中的数据页所做的物理更改。
用途：
- 崩溃恢复： 在系统崩溃后，redo logs用于恢复未完成的事务，确保数据的一致性和持久性。
- 持久性保证： 通过write-ahead logging（WAL）机制，确保所有的更改都被持久化到磁盘。

1.1 Redo Logs的工作原理

写入前置日志（Write-Ahead Logging）：
- 在对缓冲池中的数据页进行任何更改之前，更改的记录会先写入到redo log中。
- 这样做是为了确保如果系统崩溃，可以通过redo log恢复未完成的事务。
数据刷新到磁盘：
- 当数据页被修改后，它们被保存在InnoDB的缓冲池中，而不是立即写入磁盘。
- 数据页会根据一定的策略（例如定期或当缓冲池满时）刷新到磁盘。
崩溃恢复：
- 如果系统崩溃，InnoDB会在启动时扫描redo log，找到那些尚未写入磁盘的更改，并应用这些更改。
- 这个过程被称为"redo"，它确保了数据的一致性和持久性。

1.2 Redo Logs的存储

存储方式：
- Redo logs是以循环缓冲区的方式存储的，这意味着一旦日志文件被写满，新的日志记录会覆盖最旧的日志记录。
- 通常情况下，redo logs由几个固定大小的文件组成，每个文件的大小可以配置。
配置选项：
- innodb_log_file_size：设置单个redo log文件的大小。
- innodb_log_files_in_group：设置redo log文件组中的文件数量。

1.3 Redo Logs的管理

刷新策略：
- innodb_flush_log_at_trx_commit ：控制redo log何时被刷新到磁盘。
  - 0：每秒刷新一次。
  - 1：每次提交事务时立即刷新。
  - 2：每次提交事务时标记为需要刷新，但实际刷新操作延迟到下一秒。
监控和维护：
- 可以通过MySQL的性能监视器或系统变量来监控redo log的使用情况。
- 如果redo log文件满了或者出现其他问题，可能需要调整配置或进行故障排查。

1.4 总结

Redo Logs 是InnoDB存储引擎中用于崩溃恢复的重要机制。
通过write-ahead logging确保数据更改被持久化。
通过合理的配置和管理，可以确保数据的安全性和系统性能。

二、什么是Binlog？

定义： Binlog是一系列日志文件，记录了所有更改数据库表结构或数据的SQL语句。
用途：
- 数据复制（Replication）： Binlog被主服务器用来同步数据到一个或多个从服务器。
- 点在时间恢复（Point-in-Time Recovery）： Binlog可以用来恢复数据库到某个特定的时间点。

2.1 Binlog的工作原理

开启Binlog：
- Binlog必须在MySQL服务器启动时通过配置文件或命令行参数启用。
- 配置文件中的相关设置通常为 server-id 和 log_bin 或 binlog_format。
记录变更：
- 每当执行DDL（Data Definition Language）或DML（Data Manipulation Language）语句时，都会在Binlog中记录相应的SQL语句或事件。
- 根据binlog_format配置的不同（STATEMENT, ROW, MIXED），记录的内容也会有所不同：
  - STATEMENT： 记录执行的SQL语句。
  - ROW： 记录每一行数据的变化。
  - MIXED： 默认格式，根据情况选择STATEMENT或ROW格式。
同步到从服务器：
- 主服务器将Binlog发送给从服务器。
- 从服务器上的复制线程读取Binlog，并在本地重放这些SQL语句或事件。
恢复：
- Binlog可以用来将数据库恢复到故障发生前的状态。
- 使用工具如mysqlbinlog来读取Binlog并应用到数据库。

2.2 Binlog的配置与管理

配置文件：
- 通常在my.cnf或my.ini文件中配置Binlog相关选项。
- 关键配置包括：
  - server-id：唯一标识服务器的ID。
  - log_bin：指定Binlog的文件名前缀。
  - binlog_format：设置Binlog的格式。
  - expire_logs_days：设置Binlog文件自动过期删除的天数。
  - max_binlog_size：设置单个Binlog文件的最大大小。
管理命令：
- 查看状态：
  - SHOW MASTER STATUS;：查看Binlog文件的位置和偏移量等信息。
- 清理日志：
  - PURGE BINARY LOGS TO 'binlog.000004';：清理指定位置之前的Binlog文件。

2.3 Binlog与复制

复制类型：
- 异步复制： 默认模式，从服务器滞后于主服务器。
- 半同步复制： 等待至少一个从服务器确认收到Binlog后才继续。
- 全同步复制： 等待所有从服务器确认收到Binlog后才继续。
复制过滤：
- 可以通过binlog-do-db和binlog-ignore-db配置项来指定复制哪些数据库。

2.4 Binlog与恢复

恢复到特定时间点：
- 使用mysqlbinlog工具读取特定时间段内的Binlog，并应用到数据库。

2.5 总结

Binlog 是MySQL中一种非常重要的特性，主要用于数据复制和恢复。
通过正确配置和管理Binlog，可以实现高效的数据同步和可靠的数据库恢复。

三、什么是Undo Logs？

定义： Undo logs是InnoDB存储引擎使用的一种内部数据结构，记录了事务更改数据前的状态。
用途：
- 事务回滚： 如果事务需要回滚，undo logs包含的信息可用于恢复数据到事务开始前的状态。
- 读取一致性： 在多版本并发控制（MVCC）中，undo logs允许事务读取其开始时的数据版本，即使其他事务已经修改了这些数据。

3.1 Undo Logs的工作原理

事务开始：
- 当一个事务开始时，InnoDB会为该事务创建一个undo记录。
- 这个记录包含了事务开始时的数据状态。
数据更改：
- 当事务对数据进行更改时，除了更新数据外，还会在undo logs中记录这些更改前的数据状态。
- 这些记录允许事务回滚到更改前的状态。
事务提交/回滚：
- 如果事务提交，undo logs中与该事务相关的记录可以被清除。
- 如果事务回滚，undo logs中的记录被用来恢复数据到事务开始前的状态。
读取一致性：
- 当一个事务开始时，它创建了一个读取视图（read view），这个视图基于undo logs中的数据版本。
- 事务只能看到在其开始之前已经提交的事务所做的更改，这样就确保了读取一致性。

3.2 Undo Logs的存储

存储位置：
- Undo logs存储在undo表空间中，这些表空间是InnoDB系统表空间的一部分。
- InnoDB默认会为undo logs分配专门的undo表空间。
配置选项：
- innodb_undo_tablespaces：设置undo表空间的数量。
- innodb_undo_directory：指定undo表空间的目录位置。

3.3 Undo Logs的管理

保留策略：
- Undo logs中的记录会被保留，直到它们不再需要用于事务回滚或读取一致性。
- 当undo logs中的记录不再需要时，它们会被标记为可清除，并最终在适当的时机被清除。
监控和维护：
- 可以通过MySQL的性能监视器或系统变量来监控undo logs的使用情况。
- 如果undo logs使用过多或出现其他问题，可能需要调整配置或进行故障排查。

3.4 总结

Undo Logs 是InnoDB存储引擎中用于支持事务回滚和读取一致性的内部机制。
通过记录事务更改前的数据状态，undo logs允许事务回滚到更改前的状态，并确保读取一致性。
通过合理的配置和管理，可以确保数据的一致性和系统性能。

四、总结

Binlogs ：用于数据复制和某个时间点的数据恢复，记录逻辑层面的更改。
Redo Logs ：用于崩溃恢复，记录物理层面的更改。
Undo Logs：用于事务回滚和支持读取一致性，记录更改前的数据状态。

区别

用途：

Binlogs：用于数据复制和恢复。

Redo Logs：用于崩溃恢复。

Undo Logs：用于事务回滚和读取一致性。

记录内容：

Binlogs：记录逻辑层面的SQL语句。

Redo Logs：记录物理层面的更改。

Undo Logs：记录更改前的数据状态。

存储位置：

Binlogs：存储在文件系统中，由MySQL服务器管理。

Redo Logs：存储在文件系统中，通常由InnoDB管理。

Undo Logs：存储在undo表空间中，是InnoDB系统表空间的一部分。

生命周期：

Binlogs：根据配置，可能会定期过期删除。

Redo Logs：循环使用，当填满后会覆盖最早的记录。

Undo Logs：保留到不再需要用于事务回滚或读取一致性为止。