我们知道binlog有两种常用的格式,一种是statement(默认),一种是row,很多人都说建议你修改为row格式,那么是为什么呢?

首先我们需要知道它们两个之间有什么不同? statement格式记录的我们写的SQL语句,而row格式记录的则是实际受影响的数据的变化前后值

这里举两个例子说明一下:

删除

statement记录的是这个删除的语句,例如:

delete from t where age>10 and modified_time<='2020-03-04'  limit 1
1

使用这个格式的binlog很可能出现下面这种问题:

  1. 在主库执行这条SQL语句的时候,用的是索引age,而在备库执行这条SQL语句的时候,却使用了索引modified_time
  2. 主备同步本身就存在一部分延迟,limit语句很可能受延迟的影响

而row格式记录的是实际受影响的数据是真实删除行的主键id,例如:

delete from t where id=3 and age=12 and modified_time='2020-03-05'
1

这样 binlog传到备库去的时候,就肯定会删除id=3的行,不会存在主备删除不同行的问题

修改

注意这个例子数据库隔离级别为读提交

1

statment格式记录的binlog可能会是这样:

会话二:
begin;
update t set d=5 where id=0;
commit;

会话一:
begin;
update t set d=100 where d=5;
commit;
1
2
3
4
5
6
7
8
9

通过上面解析出来的binlog执行就有问题了,最终结果是2行数据d变成了100,明显与期望不一致。

如果是row格式,那么伪日志记录如下:

会话二:
begin;
update t where id=0 and c=0 and d=0
set id=0,c=0,d=5
commit;

会话一:
begin;
update t where id=5 and c=5 andd=5
set id=5,c=5,d=100
commit;
1
2
3
4
5
6
7
8
9
10
11

显然row格式记录方式按照这个binlog执行明显是正确的,也符合预期

注意:为什么这个例子强调了数据库隔离级别为读提交呢?

可重复读级别下会存在间隙锁,会话2必须等会话1释放锁后才能执行,自然也不会出问题

数据恢复

除了避免主备不一致外,使用row格式的binlog对恢复数据也很友好

delete

row格式的binlog会把被删掉的行的整行 信息保存起来。所以,如果你在执行完一条delete语句以后,发现删错数据了,可以直接把binlog中记录的delete语句转成insert

insert

row格式下,insert语句的binlog里会记录所有的字段信息,这些信息可以用来精确定位刚刚被插入的那一行。这时,你直接把insert语句转成delete语句,删除掉这被误插入的一行数据就可以了

update

row格式下,binlog里面会记录修改前整行的数据和修改后的整行数据。所 以,如果你误执行了update语句的话,只需要把这个event前后的两行信息对调一下,再去数据库里面执行,就能恢复这个更新操作了

目录