技术分享 | mysqlbinlog 技巧

如果只是解析出来查看，可以加 --base64-output=decode-rows 不显示行格式的内容： mysqlbinlog --no-defaults -vv --base64-output=decode-rows mysql-bin.000201

用来分析某个事务做了什么： mysqlbinlog --no-defaults -vv --base64-output=decode-rows --include-gtids='b0ca6715-7554-11ea-a684-02000aba3dad:614037' mysql-bin.000199

a. 时间范围

--start-datetime、--stop-datetime 解析出指定时间范围内的 binlog，这个只适合粗略的解析，不精准，因此不要用来回放 binlog。有个小技巧：如果只能确定大概的时间范围，而且不确定在哪个 binlog 中，可以直接解析多个 binlog。比如大概在 11:20-12:00 内做了个表删除 *** 作，但这个时间内有多个 binlog，可以这样：

mysqlbinlog --no-defaults -vv --base64-output=decode-rows --start-datetime='2020-08-18 11:20:00' --stop-datetime='2020-08-18 12:00:00' mysql-bin.000203 mysql-bin.000204 mysql-bin.000205

b. 偏移量范围

--start-position、--stop-position 解析 binlog 指定偏移量范围内的 binlog。如果同时指定了 --start-position 和 --stop-position，并且是解析多个 binlog，则 --start-position 只对第一个 binlog 生效，--stop-position 只对最后一个 binlog 生效。

这个常用场景是：已经解析过一次 binlog 并取得目标事务的 起始 position 后，精确的解析这一段 binlog：

c. GTID 范围

--include-gtids、--exclude-gtids 详细看参数解释。

mysqlbinlog --no-defaults --skip-gtids mysql-bin.000203 | mysql -S /data/mysql/data/3306/mysqld.sock -proot

1. --no-defaults

可以避免 my.cnf 里配了 [client] 某些 mysqlbinlog 没有的参数导致 mysqlbinlog 失败

2. -v

不加，只显示行格式（即那一串字符串），无法得到伪 SQL ：

加 -v，从行格式中重建伪SQL(带注释)，不显示 binlog_rows_query_log_events 参数效果：

加 -vv，从行格式中重建伪SQL并添加字段数据类型的注释，可以显示 binlog_rows_query_log_events 参数效果：

3. 加 --base64-output=decode-rows

不显示行格式，如果同时加 -v 参数，可以从行格式中解码为带注释的伪SQL：

4. --skip-gtids

不保留 GTID 事件信息，这样回放 binlog 时会跟执行新事务一样，生成新的 GTID。对比如下：

5. --include-gtids

只解析出指定的 GTID 的事务：

不解析指定的 GTID 的事务

你进入mysql /bin目录下你可以看到有一个mysqlbinlog可执行文件，只要 在命令下 ~ mysqlbinlog binlog文件 就可以查看咯，一般做增量备份，查看数据 *** 作或是恢复数据才看这个的吧

可以说mysql的多数特性都是围绕日志文件实现，而其中最重要的有以下三种

innodb 为了提高磁盘I/O读写性能，存在一个 buffer pool 的内存空间，数据页读入会缓存到 buffer pool，事务的提交则实时更新到 buffer pool，而不实时同步到磁盘（innodb 是按 16KB 一页同步的，一事务可涉及多个数据页，实时同步会造成浪费，随机I/O）。事务暂存在内存，则存在一致性问题，为了解决系统崩溃，保证事务的持久性，我们只需把事务对应的 redo 日志持久化到磁盘即可（redo 日志占用空间小，顺序写入磁盘，顺序I/O）

sql 语句在执行的时候，可能会修改多个页面，还会更新聚簇索引和二级索引的页面，过程产生的redo会被分割成多个不可分割的组（Mini-Transaction）。MTR怎么理解呢？如一条 insert 语句可能会使得页分裂，新建叶子节点，原先页的数据需要复制到新数据页里，然后将新记录插入，再添加一个目录项指向新建的页子。这对应多条 redo 日志，它们需要在原子性的 MTR 内完成

MTR 产生的 redo 日志先会被复制到一个 log buffer 里(类似 buffer pool)。而同步到磁盘的时机如下：

事务需要保证原子性，也是说事务中的 *** 作要么全部完成，要么什么也不做。如果事务执行到一半，出错了怎么办-回滚。但是怎么回滚呢，靠 undo 日志。undo 日志就是我们执行sql的逆 *** 作

binlog有三种格式：Statement、Row以及Mixed。

redolog 中的事务如果经历了二阶段提交中的prepare阶段，则会打上 prepare 标识，如果经历commit阶段，则会打上commit标识（此时redolog和binlog均已落盘）。崩溃恢复逻辑如下：

---