binlog的作用？和undolog和redolog的区别？mysql中从库的作用？

阅读目录

• Binlog 的作用及其与 Undo/Redo Log 的区别
  • 1. Binlog（二进制日志）
  • 2. Redo Log（重做日志）
  • 3. Undo Log（撤销日志）
  • 4. 三者的核心区别
  • 5. 协作机制：两阶段提交（2PC）
  • 6. 应用场景对比
  • 7. 总结
• mysql中从库是干什么的
  • 一、从库的核心作用
  • 二、从库的工作原理
  • 三、从库的复制模式
  • 四、从库的使用注意事项
  • 五、从库的高可用扩展

 

回到顶部

Binlog 的作用及其与 Undo/Redo Log 的区别

在 MySQL 中，Binlog（二进制日志）、Undo Log（撤销日志） 和 Redo Log（重做日志） 是三个不同层级的日志机制，各自承担不同的职责。以下是它们的核心区别及协作关系：

1. Binlog（二进制日志）

定义与作用

• 定义：由 MySQL Server 层 记录的日志（与存储引擎无关），以二进制格式存储。
• 核心作用：
  • 主从复制（Replication）：从库通过拉取主库的 Binlog 实现数据同步。
  • 数据恢复：通过 mysqlbinlog 工具解析日志，按时间点恢复数据。
  • 审计：记录所有数据库结构变更（DDL）和数据修改（DML）。

特点

• 逻辑日志：记录的是 SQL 语句或行变更前后的逻辑数据（如 UPDATE 前后的整行数据）。
• 追加写入：Binlog 文件按顺序追加，不会覆盖旧日志（需手动或自动清理）。
• 支持多种格式：
  • Statement：记录原始 SQL 语句。
  • Row：记录每行数据的变更（默认推荐）。
  • Mixed：混合模式，根据场景自动选择。

2. Redo Log（重做日志）

• 层级：InnoDB 存储引擎层。
• 作用：记录事务对数据页的 物理修改，用于崩溃恢复。
• 特点：
  • 物理日志（记录数据页的二进制变化）。
  • 顺序写入、循环覆盖。
  • 保证事务的持久性（Durability）。

3. Undo Log（撤销日志）

• 层级：InnoDB 存储引擎层。
• 作用：
  • 记录事务修改前的 逻辑状态（旧值），用于事务回滚。
  • 支持 MVCC（多版本并发控制），提供一致性读。
• 特点：
  • 逻辑日志（记录反向操作或旧值）。
  • 链式存储，支持版本回溯。
  • 事务提交后可能保留到不再被 MVCC 依赖。

4. 三者的核心区别

维度	Binlog	Redo Log	Undo Log
层级	MySQL Server 层	InnoDB 存储引擎层	InnoDB 存储引擎层
日志类型	逻辑日志（SQL 或行变更）	物理日志（数据页修改）	逻辑日志（旧值或反向操作）
主要作用	主从复制、数据恢复、审计	崩溃恢复，保证持久性	事务回滚、MVCC
生命周期	长期保留（可配置过期时间）	循环覆盖	事务提交后可能保留
写入时机	事务提交后（两阶段提交）	事务修改数据前（WAL 原则）	事务修改数据前
存储位置	独立文件（如 binlog.000001）	独立文件（如 ib_logfile0）	Undo 表空间（ibdata1 或独立文件）

5. 协作机制：两阶段提交（2PC）

为了保证 Redo Log 和 Binlog 的一致性，InnoDB 使用 两阶段提交（Two-Phase Commit, 2PC）：

1. Prepare 阶段：
   InnoDB 将事务的 Redo Log 写入磁盘（ib_logfile），标记为 PREPARE 状态。
2. Commit 阶段：
   MySQL Server 将事务的 Binlog 写入磁盘。
   InnoDB 将 Redo Log 标记为 COMMIT 状态，事务提交完成。

崩溃恢复逻辑：

• 如果 Redo Log 是 PREPARE 状态但 Binlog 完整 → 提交事务。
• 如果 Redo Log 是 PREPARE 状态但 Binlog 不完整 → 回滚事务。

6. 应用场景对比

Binlog：

• 主从同步：从库通过 Binlog 重放主库的操作。
• 数据恢复：恢复到任意时间点（需定期备份 + Binlog）。
  Redo Log：
• 崩溃恢复：确保已提交事务的修改不丢失。
  Undo Log：
• 事务回滚：撤销未提交的修改。
• MVCC：查询历史版本数据，避免读写冲突。

7. 总结

• Binlog 是 MySQL 跨存储引擎的日志，用于复制和恢复，记录逻辑操作。
• Redo Log 是 InnoDB 的物理日志，确保崩溃恢复和持久性。
• Undo Log 是 InnoDB 的逻辑日志，支持事务回滚和 MVCC。
• 协作关系：通过两阶段提交保证 Redo Log 和 Binlog 的一致性，共同实现高可靠的事务处理

回到顶部

mysql中从库是干什么的

在 MySQL 主从复制架构中，从库（Slave） 是一个关键组件，主要用于扩展读能力、保障数据高可用性及提升系统容灾能力。以下是其核心作用和工作原理：

一、从库的核心作用

1. 读写分离，分担主库压力
   场景：主库（Master）处理写操作，从库（Slave）处理读操作。
   优势：避免读写冲突，提升并发性能。
   工具支持：通过中间件（如 MyCat、ProxySQL）或代码层路由读写请求。
2. 数据备份与容灾
   实时备份：从库通过复制主库的 binlog 实现数据准实时同步。
   容灾恢复：主库故障时，可快速切换从库为新的主库（需配合高可用工具如 MHA、Orchestrator）。
3. 数据分析与离线查询
   不影响线上业务：在从库执行复杂查询或大数据分析，避免主库性能抖动。
4. 多地域部署
   就近访问：在不同地域部署从库，减少跨地域访问延迟（如国内主库 + 海外从库）。
5. 版本升级与测试
   安全验证：在从库测试新版本 MySQL 或业务变更，验证通过后再更新主库。

二、从库的工作原理

从库通过 主从复制 机制同步主库数据，流程如下：

1. 主库生成 binlog
   主库将所有数据变更（DML、DDL）以事件形式记录到 binlog。
2. 从库拉取 binlog
   I/O 线程：从库连接主库，请求 binlog 内容并写入本地的 relay log（中继日志）。
3. 从库回放 relay log
   SQL 线程：解析 relay log 中的事件，按顺序执行 SQL 操作，更新从库数据。

三、从库的复制模式

1. 异步复制（默认）
   特点：主库提交事务后，无需等待从库确认，直接返回客户端成功。
   优势：高性能，主库无额外延迟。
   缺点：数据同步存在延迟（主从不一致风险）。
2. 半同步复制（Semisynchronous）
   特点：主库提交事务后，至少等待一个从库确认收到 binlog 后才返回成功。
   优势：降低数据丢失风险。
   配置：需启用插件 rpl_semi_sync_master/rpl_semi_sync_slave。
3. 全同步复制（Group Replication）
   特点：基于组复制技术（InnoDB Cluster），所有节点数据强一致。
   优势：高可用、数据零丢失。
   适用场景：金融级高一致性要求场景。

四、从库的使用注意事项

1. 主从延迟问题
   监控：通过 SHOW SLAVE STATUS 查看 Seconds_Behind_Master 字段。
   优化：提升从库硬件性能、调整并行复制参数（slave_parallel_workers）。
2. 数据一致性校验
   工具：使用 pt-table-checksum 定期校验主从数据一致性。
3. 复制中断处理
   错误定位：检查 Last_IO_Error 或 Last_SQL_Error 字段。
   修复方法：手动跳过错误或重建从库。
4. 从库只读限制
   配置：设置 read_only=ON，禁止从库写操作（超级用户仍可写）。

五、从库的高可用扩展

1. 级联复制（主 → 从 → 从）
   减轻主库推送 binlog 的压力，适合多从库场景。
2. 多源复制（Multi-Source Replication）
   一个从库可同时复制多个主库的数据（MySQL 5.7+ 支持）。
3. GTID 复制（Global Transaction Identifier）
   通过全局事务ID简化复制故障恢复，避免 binlog 文件位置依赖。

在完成主从复制之后，你就可以在写数据时只写主库，在读数据时只读从库，这样即使写请求会锁表或者锁记录，也不会影响读请求的执行。

从库是不是越多越好?
不是的。
因为从库数量增加，从库连接上来的 //0 线程也比较多，主库也要创建同样多的 log dump 线程来处理复制的请求，对主库资源消耗比较高，同时还受限于主库的网络带宽。所以在实际使用中，一个主库一般跟2~3个从库(1套数据库，1主2从1备主)，这就是一主多从的MySQL 集群结构。