【mysql】MySQL 中Redo日志与Binlog日志顺序一致性问题
发布日期:2021-05-08 11:05:05 浏览次数:24 分类:精选文章

本文共 874 字,大约阅读时间需要 2 分钟。

MySQL 二进制日志与事务日志深入解析

为什么有二进制日志和事务日志?

在MySQL体系结构中,二进制日志(Binary Log)和事务日志(Redo Log)各有其重要作用。二进制日志属于服务器层,主要用于主从复制和即时点恢复。事务日志则属于InnoDB存储引擎层,负责保证事务的安全性。了解了这些基础后,我们可以深入探讨MySQL主从复制的工作原理。

在此过程中,以下问题值得深入探讨:

  • 为什么需要二进制日志和事务日志?
  • 事务提交的过程是怎样的?二者是否存在先后顺序问题?
  • 主从复制环境下如何保障数据安全与故障恢复?
  • 为什么要确保二进制日志的写入顺序与InnoDB事务提交顺序保持一致?
  • 事务提交过程及其顺序保证

    MySQL没有开启二进制日志的情况

    在没有开启二进制日志的环境下,InnoDB引擎通过Redo Log和Undo Log来保证CrashSafe特性:

  • CrashSafe机制
    • 所有已提交事务的数据仍然存在。
    • 所有未提交事务的数据自动回滚。
  • InnoDB通过两种机制实现这一点:

    • Redo Log:在每次事务提交时,将日志内容写入硬盘。
    • Undo Log:记录未提交事务的操作,允许在故障恢复时回滚。

    为了平衡性能与CrashSafe特性,InnoDB提供了innodb_flush_log_at_trx_commit变量,用户可根据需求选择合适的设置。

    开启二进制日志的情况

    在开启二进制日志的情况下,MySQL引入了两阶段提交(2PC)机制,确保二进制日志与事务日志的一致性:

  • 两阶段提交流程

    • Prepare阶段:生成事务ID(XID),执行Redo Log刷盘操作。
    • Commit阶段
      • 将SQL语句写入二进制日志。
      • 进行事务提交,清除Undo信息,刷盘Redo Log。
  • Crash恢复过程

    • 主库在二进制日志写入前崩溃:事务自动回滚,主库数据不变,备库无此事务数据。
    • 主库在二进制日志写入后崩溃:事务被认为已提交,备库根据二进制日志完成数据同步。
  • 通过两阶段提交,MySQL确保了主从复制环境下的数据一致性与安全性。

    上一篇:【mysql】谈谈传说中的redo log日志是什么?有啥用?
    下一篇:【mysql】MYSQL的日志(redo log,binlog)顺序读写,数据文件随机读写以及linux底层原理

    发表评论

    最新留言

    能坚持,总会有不一样的收获!
    [***.219.124.196]2025年05月16日 16时24分13秒