mysql主从复制及binlog格式

目录

一个事务日志同步的完整过程

binlog的三种格式对比

当binlog_format=statement

binlog_format=‘row’

binlog_format=‘mixed’   它就是前两种格式的混合


一个事务日志同步的完整过程

  1. 在备库B上通过change master命令,设置主库A的IP、端口、用户名、密码,以及要从哪个位置开始请求binlog,这个位置包含文件名和日志偏移量。

  2. 在备库B上执行start slave命令,这时候备库会启动两个线程,就是图中的io_thread和sql_thread。其中io_thread负责与主库建立连接。

  3. 主库A校验完用户名、密码后,开始按照备库B传过来的位置,从本地读取binlog,发给B。

  4. 备库B拿到binlog后,写到本地文件,称为中转日志(relay log)。

  5. sql_thread读取中转日志,解析出日志里的命令,并执行。

 

binlog的三种格式对比

一种是statement,一种是row。另一种叫作mixed,其实它就是前两种格式的混合。

当binlog_format=statement

binlog里面记录的就是SQL语句的原文。

由于statement格式下,记录到binlog里的是语句原文,因此可能会出现这样一种情况:在主库执行这条SQL语句的时候,用的是索引a;而在备库执行这条SQL语句的时候,却使用了索引t_modified。因此,MySQL认为这样写是有风险的。

binlog_format=‘row’

前后的BEGIN和COMMIT是一样的。但是,row格式的binlog里没有了SQL语句的原文,而是替换成了两个event:Table_map和Delete_rows。

  1. Table_map event,用于说明接下来要操作的表是test库的表t;

  2. Delete_rows event,用于定义删除的行为。

需要借助mysqlbinlog工具,解析和查看binlog中的内容

binlog_format=‘mixed’   它就是前两种格式的混合

  • 因为有些statement格式的binlog可能会导致主备不一致,所以要使用row格式。
  • 但row格式的缺点是,很占空间。比如你用一个delete语句删掉10万行数据,用statement的话就是一个SQL语句被记录到binlog中,占用几十个字节的空间。但如果用row格式的binlog,就要把这10万条记录都写到binlog中。这样做,不仅会占用更大的空间,同时写binlog也要耗费IO资源,影响执行速度。
  • 所以,MySQL就取了个折中方案,也就是有了mixed格式的binlog。mixed格式的意思是,MySQL自己会判断这条SQL语句是否可能引起主备不一致,如果有可能,就用row格式,否则就用statement格式。

 

 

 

 

你可能感兴趣的:(mysql)