印刻数据库

外观

MariaDB Binlog与Redo Log ​

日志概述 ​

MariaDB 包含多种日志类型，其中 Binlog（二进制日志）和 Redo Log（重做日志）是两种最重要的日志，它们在数据恢复、复制和高可用性方面发挥着关键作用。虽然它们都用于记录数据库操作，但在设计目的、工作原理和使用场景上存在明显差异。

Binlog（二进制日志） ​

基本概念 ​

Binlog 是 MariaDB Server 层生成的二进制日志，用于记录所有数据库的修改操作，包括 DML（数据操作语言）和 DDL（数据定义语言）语句。Binlog 是逻辑日志，记录的是操作的逻辑内容，而不是物理数据页的修改。

作用 ​

  • 数据恢复：用于时间点恢复（PITR），可以将数据库恢复到指定的时间点
  • 主从复制：主库通过 Binlog 将数据变更同步到从库
  • 数据审计：记录所有数据修改操作，用于审计和合规性检查
  • 增量备份：结合全量备份，实现增量备份和恢复

Binlog 格式 ​

MariaDB 支持三种 Binlog 格式，通过 binlog_format 参数配置：

1. STATEMENT 格式 ​

  • 记录执行的 SQL 语句
  • 日志体积小，节省存储空间
  • 可能导致主从数据不一致，如使用 NOW()、RAND() 等非确定性函数
  • 适用于简单的 SQL 操作场景

2. ROW 格式 ​

  • 记录行数据的变更，而不是 SQL 语句
  • 主从数据一致性高，不受非确定性函数影响
  • 日志体积大，存储空间占用多
  • 支持细粒度的复制和恢复
  • 适用于复杂的 SQL 操作和高一致性要求场景

3. MIXED 格式 ​

  • 结合了 STATEMENT 和 ROW 格式的优点
  • 自动选择合适的格式，对于非确定性函数使用 ROW 格式，其他情况使用 STATEMENT 格式
  • 平衡了日志体积和数据一致性
  • MariaDB 默认格式

Binlog 配置 ​

启用 Binlog ​

在 my.cnf 或 my.ini 文件中添加以下配置：

ini
[mysqld]
# 启用 Binlog
log_bin = /var/lib/mysql/mysql-bin
# Binlog 格式
binlog_format = MIXED
# Server ID，主从复制必需
server_id = 1
# Binlog 过期时间（天）
expire_logs_days = 7
# Binlog 文件大小限制
max_binlog_size = 100M

动态配置 ​

sql
-- 查看当前 Binlog 配置
SHOW VARIABLES LIKE 'binlog%';
SHOW VARIABLES LIKE 'log_bin%';

-- 动态设置 Binlog 格式（仅对当前会话有效）
SET SESSION binlog_format = 'ROW';
-- 全局设置（需要重启服务生效）
SET GLOBAL binlog_format = 'ROW';

Binlog 管理 ​

查看 Binlog 信息 ​

sql
-- 查看 Binlog 文件列表
SHOW BINARY LOGS;

-- 查看当前正在使用的 Binlog 文件
SHOW MASTER STATUS;

-- 查看 Binlog 文件内容
SHOW BINLOG EVENTS IN 'mysql-bin.000001';
-- 查看指定范围内的 Binlog 事件
SHOW BINLOG EVENTS IN 'mysql-bin.000001' FROM 100 LIMIT 10;

使用 mysqlbinlog 工具查看 Binlog ​

bash
# 查看 Binlog 文件内容
mysqlbinlog /var/lib/mysql/mysql-bin.000001

# 按时间范围查看
mysqlbinlog --start-datetime='2023-01-01 00:00:00' --stop-datetime='2023-01-02 00:00:00' /var/lib/mysql/mysql-bin.000001

# 按位置范围查看
mysqlbinlog --start-position=100 --stop-position=200 /var/lib/mysql/mysql-bin.000001

# 转换为 SQL 语句
mysqlbinlog --base64-output=decode-rows --verbose /var/lib/mysql/mysql-bin.000001

手动刷新和删除 Binlog ​

sql
-- 手动刷新 Binlog，生成新的 Binlog 文件
FLUSH BINARY LOGS;

-- 删除指定的 Binlog 文件
PURGE BINARY LOGS TO 'mysql-bin.000005';

-- 按时间删除 Binlog 文件
PURGE BINARY LOGS BEFORE '2023-01-01 00:00:00';

-- 重置 Binlog（删除所有 Binlog 文件，生成新的 mysql-bin.000001）
RESET MASTER;

Redo Log（重做日志） ​

基本概念 ​

Redo Log 是 InnoDB 存储引擎生成的物理日志，用于记录数据页的物理修改。它是 InnoDB 事务持久性的保证，确保即使在数据库崩溃的情况下，也能通过 Redo Log 恢复未写入磁盘的数据。

作用 ​

  • 崩溃恢复：当数据库崩溃时，通过 Redo Log 恢复未写入磁盘的数据
  • 事务持久性：确保事务提交后，数据修改不会丢失
  • 提高性能：通过 Write-Ahead Logging (WAL) 机制，将随机写转换为顺序写，提高写入性能

Redo Log 工作原理 ​

  1. Write-Ahead Logging (WAL)：在修改数据页之前，先将修改记录写入 Redo Log
  2. Redo Log Buffer：修改操作先写入内存中的 Redo Log Buffer
  3. Redo Log File：Redo Log Buffer 中的数据定期刷新到磁盘上的 Redo Log File
  4. Checkpoint：定期将已写入 Redo Log 的数据页刷新到磁盘，释放 Redo Log 空间

Redo Log 配置 ​

基本配置 ​

在 my.cnf 或 my.ini 文件中添加以下配置：

ini
[mysqld]
# InnoDB Redo Log 文件路径（默认在数据目录下）
innodb_log_group_home_dir = /var/lib/mysql/
# Redo Log 文件数量（建议 2-4 个）
innodb_log_files_in_group = 2
# 每个 Redo Log 文件大小（建议 256M-2G）
innodb_log_file_size = 512M
# Redo Log Buffer 大小（默认 16M）
innodb_log_buffer_size = 32M
# Redo Log 刷新策略
innodb_flush_log_at_trx_commit = 1

Redo Log 刷新策略 ​

innodb_flush_log_at_trx_commit 参数控制 Redo Log 的刷新策略，有三种取值：

  1. 0：每秒将 Redo Log Buffer 刷新到 Redo Log File 并刷盘

    • 性能最高，但可能丢失最多 1 秒的数据
    • 适用于对数据安全性要求不高的场景

  2. 1：每次事务提交时将 Redo Log Buffer 刷新到 Redo Log File 并刷盘

    • 数据安全性最高，不会丢失数据
    • 性能较低，IO 开销大
    • MariaDB 默认值，适用于对数据安全性要求高的场景

  3. 2：每次事务提交时将 Redo Log Buffer 刷新到 Redo Log File，但每秒刷盘一次

    • 性能较高，可能丢失最多 1 秒的数据
    • 适用于对数据安全性有一定要求，但又需要较高性能的场景

Redo Log 管理 ​

查看 Redo Log 状态 ​

sql
-- 查看 InnoDB 状态，包含 Redo Log 信息
SHOW ENGINE INNODB STATUS;

-- 查看 Redo Log 相关配置
SHOW VARIABLES LIKE 'innodb_log%';

修改 Redo Log 配置 ​

修改 Redo Log 配置需要谨慎，特别是修改 innodb_log_file_size 时，需要按照以下步骤进行：

  1. 停止 MariaDB 服务
  2. 备份现有的 Redo Log 文件（ib_logfile0, ib_logfile1 等）
  3. 修改 my.cnf 中的 innodb_log_file_size 参数
  4. 删除现有的 Redo Log 文件
  5. 启动 MariaDB 服务，会自动生成新的 Redo Log 文件

监控 Redo Log 使用情况 ​

sql
-- 查看 Redo Log 写入量
SHOW GLOBAL STATUS LIKE 'Innodb_os_log_written';

-- 查看 Redo Log 等待情况
SHOW GLOBAL STATUS LIKE 'Innodb_log_wait%';

-- 查看 Checkpoint 信息
SHOW ENGINE INNODB STATUS LIKE 'CHECKPOINT%';

Binlog 与 Redo Log 的区别与联系 ​

特性BinlogRedo Log
所属层Server 层InnoDB 存储引擎层
日志类型逻辑日志物理日志
记录内容SQL 语句或行数据变更数据页的物理修改
作用复制、时间点恢复、审计崩溃恢复、事务持久性
开启方式可选，通过 log_bin 参数开启InnoDB 必须开启
刷新策略事务提交时写入支持多种刷新策略（innodb_flush_log_at_trx_commit）
生命周期可配置过期时间，自动清理循环使用，通过 Checkpoint 机制管理
大小限制单个文件大小限制（max_binlog_size）总大小限制（innodb_log_files_in_group * innodb_log_file_size）

联系 ​

  • 两者都是 MariaDB 数据可靠性的重要保障
  • 都采用 Write-Ahead Logging (WAL) 机制
  • 在主从复制中，Binlog 依赖于 Redo Log 保证数据一致性
  • 崩溃恢复时，先通过 Redo Log 恢复数据，再通过 Binlog 恢复未提交的事务

最佳实践 ​

Binlog 最佳实践 ​

  1. 选择合适的 Binlog 格式：

    • 对于主从复制，建议使用 ROW 格式，保证数据一致性
    • 对于简单场景，可以使用 MIXED 格式，平衡性能和一致性

  2. 合理配置 Binlog 大小和过期时间：

    • 设置合适的 max_binlog_size（建议 100M-1G）
    • 根据存储容量和恢复需求，设置合适的 expire_logs_days

  3. 定期备份 Binlog：

    • 结合全量备份，定期备份 Binlog 文件
    • 确保备份的 Binlog 与全量备份一致

  4. 监控 Binlog 使用情况：

    • 监控 Binlog 文件数量和大小
    • 监控 Binlog 写入量和延迟

  5. 谨慎使用 RESET MASTER 命令：

    • 该命令会删除所有 Binlog 文件，仅在必要时使用
    • 使用前确保已备份所有需要的 Binlog 文件

Redo Log 最佳实践 ​

  1. 合理配置 Redo Log 大小：

    • 建议 Redo Log 总大小为缓冲池大小的 25%-100%
    • 每个 Redo Log 文件大小建议为 256M-2G
    • Redo Log 文件数量建议为 2-4 个

  2. 选择合适的刷新策略：

    • 对数据安全性要求高的场景，使用 innodb_flush_log_at_trx_commit = 1
    • 对性能要求高的场景，可以考虑使用 innodb_flush_log_at_trx_commit = 2

  3. 监控 Redo Log 使用情况：

    • 监控 Redo Log 写入量和等待情况
    • 监控 Checkpoint 位置，确保 Checkpoint 正常推进

  4. 避免 Redo Log 争用：

    • 确保 Redo Log 文件存储在高性能磁盘上
    • 避免多个实例共享同一个 Redo Log 磁盘

  5. 定期检查 Redo Log 完整性：

    • 定期运行 CHECK TABLE 命令检查表完整性
    • 定期备份数据，确保数据可恢复

版本差异 ​

MariaDB 10.0+ ​

  • 引入了 GTID (Global Transaction ID)，提高了复制的可靠性和易用性
  • 增强了 Binlog 压缩功能，减少存储空间占用

MariaDB 10.1+ ​

  • 引入了 Binlog 加密功能，提高了 Binlog 的安全性
  • 增强了 Redo Log 性能，优化了 WAL 机制

MariaDB 10.2+ ​

  • 支持动态调整 Binlog 格式（无需重启服务）
  • 增强了 Redo Log 恢复机制，提高了崩溃恢复的速度

MariaDB 10.3+ ​

  • 引入了 Binlog 校验和功能，提高了 Binlog 的完整性
  • 支持 Redo Log 并行写入，提高了写入性能

MariaDB 10.4+ ​

  • 默认 Binlog 格式改为 ROW 格式，提高了主从复制的一致性
  • 优化了 Redo Log 空间管理，减少了 Checkpoint 开销

MariaDB 10.5+ ​

  • 增强了 Binlog 过滤功能，支持更细粒度的复制过滤
  • 优化了 Redo Log 刷新机制，提高了写入性能

常见问题（FAQ） ​

1. 如何选择 Binlog 格式？ ​

建议：

  • 对于主从复制，推荐使用 ROW 格式，确保数据一致性
  • 对于简单的应用场景，可以使用 MIXED 格式，平衡性能和一致性
  • 避免使用 STATEMENT 格式，可能导致主从数据不一致

2. Redo Log 文件大小如何设置？ ​

建议：

  • 总大小为缓冲池大小的 25%-100%
  • 每个文件大小建议为 256M-2G
  • 文件数量建议为 2-4 个
  • 确保 Redo Log 能够容纳至少 1 小时的写入量

3. Binlog 占用空间过大怎么办？ ​

解决方案：

  • 设置合适的 expire_logs_days 参数，自动清理过期的 Binlog 文件
  • 定期手动清理不需要的 Binlog 文件，使用 PURGE BINARY LOGS 命令
  • 考虑使用 Binlog 压缩功能，减少存储空间占用
  • 增加存储空间，确保有足够的空间存储 Binlog 文件

4. 如何监控 Binlog 和 Redo Log 的使用情况？ ​

建议：

  • 使用 MariaDB 自带的状态变量监控：SHOW GLOBAL STATUS LIKE 'Binlog%' 和 SHOW GLOBAL STATUS LIKE 'Innodb_log%'
  • 使用第三方监控工具，如 Prometheus、Grafana 等
  • 定期查看 SHOW ENGINE INNODB STATUS 输出，了解 Redo Log 状态

5. 数据库崩溃后，如何使用 Redo Log 恢复数据？ ​

恢复过程：

  • 数据库启动时，会自动执行崩溃恢复
  • 首先读取 Redo Log，恢复所有已提交的事务
  • 然后读取 Undo Log，回滚未提交的事务
  • 最后更新数据字典，完成恢复

6. 如何备份和恢复 Binlog？ ​

备份：

  • 定期复制 Binlog 文件到备份目录
  • 使用 mysqlbinlog 工具将 Binlog 转换为 SQL 文件备份

恢复：

  • 先恢复全量备份
  • 然后使用 mysqlbinlog 工具将增量的 Binlog 应用到数据库
  • 示例：mysqlbinlog mysql-bin.000001 mysql-bin.000002 | mysql -u root -p

7. Redo Log 刷新策略如何选择？ ​

建议：

  • 对数据安全性要求极高的场景：innodb_flush_log_at_trx_commit = 1
  • 对性能要求较高，数据安全性要求一般的场景：innodb_flush_log_at_trx_commit = 2
  • 对数据安全性要求较低，追求极致性能的场景：innodb_flush_log_at_trx_commit = 0

8. 如何优化 Binlog 和 Redo Log 的性能？ ​

优化建议：

  • 将 Binlog 和 Redo Log 存储在高性能磁盘上（如 SSD）
  • 合理配置 Binlog 和 Redo Log 的大小和数量
  • 选择合适的刷新策略
  • 避免过度频繁的事务提交，可以考虑使用批量提交
  • 优化查询语句，减少不必要的数据修改

总结 ​

Binlog 和 Redo Log 是 MariaDB 中最重要的两种日志，它们在数据可靠性、复制和高可用性方面发挥着关键作用。理解它们的工作原理、配置和管理方法，对于 DBA 来说至关重要。

在实际生产环境中，DBA 需要根据业务需求和系统特点，合理配置和管理 Binlog 和 Redo Log，确保数据库的安全性、可靠性和性能。同时，定期监控和优化日志配置，及时发现和解决问题，也是 DBA 日常工作的重要内容。

通过本文的介绍，相信您对 MariaDB Binlog 和 Redo Log 有了更深入的了解，能够在实际生产环境中更好地配置、管理和优化这两种日志，提高数据库的整体性能和可靠性。