聊聊BINLOG

binlog记录什么？

MySQL server中所有的搜索引擎发生了更新（DDL和DML）都会产生binlog日志，记录的是语句的原始逻辑

为什么需要binlog？

binlog主要有两个应用场景，一是数据复制，在MySQL主从复制的场景下我们通过master来写binlog，slaver

读取master的binlog来完成数据一致性。二是数据恢复，通过mysqlbinlog工具来恢复数据，通过确定start-position和end-position来执行

binlog的记录格式

statement

设置为statement记录的是语句SQL语句原文，同步数据时会执行记录的SQL语句，但是有一些语句直接执行会和原语句不同，比如（UUID，update_time = now()等）所以这种简单的记录形式无法保证数据的一致性，我们有row格式

row

row格式记录的是修改的具体数据，这样保证了数据库恢复和复制的数据的可靠性，但是这种格式需要占用大量的容量来记录，并且恢复和同步更消耗IO资源。所以又有了一种折中方案，设置为mixed，记录的内容是前两者的混合。

mixed

MySQL会判断这条SQL语句是否会引起数据不一致，如果是就用row格式，否则就用statement`格式。

binlog的写入机制

一个事务的binlog不能被拆开，无论这个事务多大，也要确保一次性写入，所以系统会给每个线程分配一块内存作为binlog cache。可以通过binlog_cache_size参数控制单线程binlog_cache大小，如果存储内容超过了这个参数，就要暂存到磁盘。

binlog的写入时机是事务执行中，在执行事务中第一个dml语句时会分配空间binlog cache，将日志写到binlog cache，事务提交的时候再把binlog cache写到binlog文件中同时释放binlog cache

write是指将日志写入到系统的page cache

fsync是将日志刷新到binlog日志文件中完成持久化

write和fsync的时机可以由参数sync_binlog控制，可以配置成0、1、N(N>1)。

• 设置成0时：表示每次提交事务都只会write，由系统自行判断什么时候执行fsync。
• 设置成1时：表示每次提交事务都会执行fsync，就和redo log日志刷盘流程一样。
• 设置成N时：表示每次提交事务都会write，但是积累N个事务后才fsync。

什么是两阶段提交？

在执行更新语句时，会记录到redo log和binlog两块日志，以基本事务为单位，redo log在事务的执行过程中能够不断写入，binlog只能在事务提交的时候写入

为了解决两份日志之间逻辑一致问题，innodb存储引擎采用了两阶段提交方案，将redo log写入拆成了prepare和commit两个阶段，这就是两阶段提交

使用两阶段提交后，写入binlog发生异常也没有影响，因为MySQL根据redo log恢复数据时，发现redo log还处于prepare阶段，没有对应的binlog日志，则回滚事务

binlog和redo log的区别

binlog是逻辑日志，记录的是原始语句，属于MySQL server层，所有存储引擎有更新操作都会记录；redo log是物理日志，记录的是在某个数据页上做的修改，属于innodb存储引擎层

虽然它们都是持久化的保证但侧重点有所不同：

redo log使innodb有了崩溃后恢复的能力

binlog保证了集群架构下数据一致性