MySQL日志

发表于： 分类于：
字数： 944 阅读：≈ 2分钟

所有DML操作（INSERT/UPDATE/DELETE）都先在Buffer Pool中完成

redo log

视频讲解 Alt text

  1. 实现事务的持久性。redo log先刷盘，脏页再刷盘

物理存储特性

  1. 文件结构

    • 由固定大小的文件组成(如 ib_logfile0, ib_logfile1)
    • 循环写入(ring buffer)设计
    • 物理写入总是追加到文件末尾

  2. 写入模式

1
2

// 伪代码表示物理写入
write(log_file, log_record, log_size); // 总是追加写

Write-Ahead Logging (WAL)：

  • 在Buffer Pool中更新数据页，该数据页成为脏页。
  • 将数据页的物理变更（如“页号 X，偏移 Y 写入数据 Z”）顺序写入 redo log buffer。
  • 当执行 COMMIT 时，根据配置参数 innodb_flush_log_at_trx_commit 决定行为（通常默认值为 1）
参数值行为持久性保证
1 (默认)1. 写 PageCache
2. 立即 fsync() 刷盘		完全持久
0每秒批量写入+刷盘可能丢失1秒数据
2写 PageCache 但延迟刷盘仅保证OS不崩溃
  • 异步脏页刷盘， 后台线程把BufferPool中的数据刷新到硬盘上

Alt text

undo log

  1. 实现事务回滚，保证事物的原子性
  2. 结合 ReadView实现 MVCC，为record保留版本链

Binlog

基本概念

Binlog (Binary Log) 是MySQL Server层实现的二进制日志，记录所有修改数据的SQL语句（逻辑日志）,事务提交的时候写入。

核心特性

  1. 记录内容：

    • 所有DDL（CREATE/ALTER等）和DML（INSERT/UPDATE等）语句
    • 以事件形式存储，包含执行耗时、错误码等元信息

  2. 与Redo Log对比：

    BinlogRedo Log
    层级Server层InnoDB引擎层
    类型逻辑日志（SQL语句）物理日志（页修改）
    用途主从复制/数据恢复崩溃恢复

  3. 三种格式：

    • STATEMENT：记录原始SQL（可能主从不一致，如果从库执行这些语句的环境和主库稍有不同，可能会导致数据不一致
    • ROW：记录行数据变化（默认推荐）
    • MIXED：混合模式

主从复制

server-id 是 MySQL 实例的唯一标识，主从库都得有且不能重复，用来区分不同节点。

主库开启一个线程来处理 binlog 分发，叫 Binlog Dump 线程。

从库这边有两个关键线程，一个是 I/O 线程，负责跟主库建立连接，请求主库 binlog，然后写到自己的中继日志里；另一个是 SQL 线程，从 I/O 线程写的中继日志里读取内容，在从库执行 SQL 语句来更新数据。

主库参数

log-bin 开启二进制日志，binlog-format 设置日志格式

从库参数

  1. Master_Host是主库的ip
  2. Master_User是用户
  3. Master_Port是端口
  4. Master_Log_File是主库binlog文件名