你知道Mysql如何保证主备一致吗？

大家都知道Mysql的binlog可以用来存档，也可以用来主备同步。但是你知道为什么备份库执行了binlog后就可以和主库保持一致了吗？

一、binlog

binlog是Mysql自带的日志，而比如redolog是Innodb引擎实现的。搜索引擎是插件的形式集成进入Mysql的。

1.写入过程

binlog在事务的执行过程中，先写入binlog_cache，然后再事务提交的时候，一次性写入binlog日志文件中。

因为binlog是逻辑日志，记录的是一个个的执行逻辑（一条条sql语句或者是行记录从xx改为了xx），所以一个事务不管多大，这个事务中的binlog必须放在一起。

每个线程都会有一个binlog_cache, 如果一个事务过大，binlog_cache存不下，就会存入临时文件中，当事务提交的时候，会将缓存或者临时文件中的binlog写入binlog日志文件中，最后清空binlog_cache或者临时文件。

如果生产库使用delete删除大量的数据，那么这就是一个大事务。你开启binlog的话（一般都是开启的），就会有大量的磁盘空间被占据，也就会生成大量的临时文件。而事务提交的时候，由于是写入完成后才会删除，这部分磁盘占用还会x2。容易把磁盘打满。

2. binlog写入时机

mysql属于用户空间，所以binlog_cache真正写入文件的时候，还会经过系统缓存（os cache）,最后再刷入（fsync）文件。

binlog有一个参数sync_binlog，通过它来设置binlog写入时机：

0：每次事务提交的时候，只会写入系统缓存，由系统去控制刷入磁盘（文件）的时机，mysql不管。

1：每次事务提交，都会写入系统缓存，并调用fsync刷入磁盘

N（N>1）：每次提交事务都会写入系统缓存，积攒N个事务之后调用fsync刷入磁盘。

一般都不会设置为0，不可控。我们知道写入磁盘是一个比较耗时的过程，因此再IO瓶颈的场景中可以将N设置的大一些，可以提升性能，但坏处是一旦宕机，会丢失最近N个事务的日志。

二、主备基本原理

假设有2个节点A和B，A为主节点，B为备份节点。A有读写权限，B只有读的权限。注意，这里的读写权限针对的是我们业务的普通用户，而mysql的读写不会限制。

1.主备同步过程

两个数据库AB之间会保持一个长连接，A主库中会有一个线程专门服务这个长连接

1. B备库中有一个线程io_thread，会将需要同步binlog位置发送给A
2. A收到请求后，根据位置，读取本地的binlog，发送给B
3. B手到数据库，io_thread记录到中转日志中
4. B还会有一个sql_thread读取中转日志，然后解析执行。

sql_thread会有多个线程

2. binlog格式问题

binlog有三种格式：

• statement：记录的是执行的语句。

• row: 记录的是某个数据修改，从xx改为xx。

• mixed: 以上2中的混合

 statement：

这个格式下，如果主库执行了delete语句，但是where语句中没有用主键做条件，那么从库同步的时候，可能会造成主从执行结果不同。

row:

这个记录的是某条数据的变化情况，就不会有statement的问题。但是使用的日志空间会变大。比如删除语句，statement只记录一条，row格式需要记录每一条删除的数据。

mixed:

因此有了mixed，mysql会自己判断sql语句是否安全，然后选择不同的格式记录。

快看看你们公司使用的是什么格式吧：show global variables like 'binlog_format'

3. 函数问题

如果我们使用statement格式的binlog，然后执行下面的语句后：

insert into test values(5,now())

 会不会造成主从获取的时间不同那？

答案是不会的，statement在记录执行语句的时候，也会把当前获取的时间记录下来。

4.循环复制问题

如果AB互相为主备，A产生binlog后，会同步给B，B拿到A的binlog后还会产生新的binlog，然后又同步给A，A又接着同步产生新的binlog，然后造成死循环，Mysql如何解决那？

Mysql会给每个节点生成serviceid，规定两个serviceid相同的节点不能互相备份。

1. A节点记录binlog的时候，会记录生成binlog的serviceid
2. B拿到binlog后，产生的binlog记录的还是A节点的serviceid
3. A节点再次拿到B的binlog后，不会执行和自己serviceid相同的binlog

---

觉得有帮助的小伙伴点个赞支持下吧！！！