当前位置：首页 > article >正文

Mysql-redo logs,binlog以及undo logs的作用及区别

article 2024/11/14 6:15:49

提到mysql，常常会提到它的三种日志，Redo Logs,Binlog以及Undo Logs.
这三种日志的用途具体是什么？以及有什么样的区别，在接下去的文章当中就能看明白。

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

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

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

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

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

配置文件：
- 通常在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文件。

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

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

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

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

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