数据库篇：mysql日志类型之 redo、undo、binlog

我上周告诉过你mysql日志的事。

重做日志发生了什么？ 目标是优化磁盘 I/O。
确保交易一致性。

首先将其保存到日志缓冲区。
如果满足条件，就会同步到磁盘。

占用空间很小。
顺序写入非常高效。
数据页同步，日志回收。

撤消日志在哪里？ 作用是实现原子性。
支持回滚和多版本控制。

保存到与页面撤消关联的专用列表。
交易完成后，大部分内容都会被删除。
但那些 MVCC 保留了下来。

什么是binlog日志？ 记录数据库变更历史。
用于恢复和主从复制。

共有三种格式。
语句、行、混合。

语句记录 SQL 语句。
行记录数据行的更改。
混合结合了两者。

Binlog在主从复制中非常重要。
但格式不同，会影响复制性能和稳定性。
Redo和undo主要是关于事务和恢复。
它保证数据的完整性和一致性。

Binlog主要是恢复和主从复制。
确保数据的一致性和可用性。

就是这样。

深入理解MySQL binlog

说白了，MySQL的binlog就是数据库活动的“录像带”，只不过这个录像带是以二进制格式记录的。
其实很简单。
它主要做两件事：一是帮助数据恢复或者将数据从主库同步到从库。

首先，最重要的是binlog有三种格式：STATMENT（默认）记录诸如“insert into user value(1 ,'test')”这样的SQL语句的原文，并直接从数据库重放。
我们去年做的一个项目就用过这个，但是数据量一到3 000级别就出现了问题。
像 NOW() 这样的函数每次执行的方式都不同，搞乱了主从结果。
还有一点就是ROW格式记录了数据行的变化，完美解决了动态特征的问题。
然而，UPDATE等操作会产生很多事件，binlog可以直接扩展到几GB。
还有一个非常重要的细节。
MIXED是像智能编辑器一样的自动模式，记录简单的SQL STATENT，复杂操作切换到ROW，还具有压缩功能。
这是为了与新发布的主从集群一起使用。

一开始我以为binlog是由QUERY和XID事件组成的，后来发现我错了。
文件头事件（例如 FORMAT_DESCRIPTION）、文件转换标记（例如 ROTATE）以及自增量 ID 记录（例如 INTVAR）实际上在实际使用中具有更大的影响。
等等，还有一件事。
要浏览“本地录像带”中继日志，实际上需要两个 .info 文件。
master.info记录主库中记录的位置，Relay-log.info记录本地记录的位置。
这个设计……老实说很令人困惑。

最好先了解 MIXED 模式的触发条件。
很多人没有注意到这一点。
这不是基于SQL类型，而是基于操作本身是否具有动态特性。