MySQL复制是基于主库上的二进制日志来完成,复制是异步的,可能存在延迟

MySQL日志分为:

  1、服务层日志:二进制日志、通用日志、慢查日志

  2、存储引擎层日志:innodb中重做日志和回滚日志

二进制日志:

  记录了所有对数据库修改的事件,包括DML和DDL,但是不包含因为出错回滚的日志。二进制日志格式分类:

STATMENT:SBR

基于段的格式binlog_format=STATMENT,MySQL5.7之前默认

在数据修改时执行的SQL语句,不论使用的时那种日志格式,在使用DDL语句都是基于段的格式

优点:

  日志记录量相对较小,解决磁盘及网络I/O,因为只是记录SQL语句,而不是每一行数据的变化

  不强制要求主从数据库的表的定义完全相同

缺点:

  必须要记录上下文信息,保证语句在从数据库上执行结果和主数据库上相同

  特定函数如UUID(),user()这类函数还是无法复制,会在主从数据库上产生差异

  对于存储过程、触发器,自定义函数在主从数据库进行的修改可能造成数据不一致

  相比基于row的复制方式需要更多地行锁

SHOW VARIABLES LIKE 'binlog_format';    //查看binlog是否开启,使用的是哪种
SET SESSION binlog_format=statement;    //设置binlog使用statement
SHOW BINARY LOGS;						//查看binlog文件有哪些
mysqlbinlog binlog.000097;				//查看binlog文件,通过cmd或者在Linux环境使用,无法在连接工具上使用
SHOW BINLOG EVENTS in 'binlog.000097';	//查看binlog文件,在连接工具上使用
FLUSH LOGS;								//刷新logs,新产生一个binlog文件
//下面是SQL语句
DROP TABLE IF EXISTS temp;
CREATE TABLE temp(id int, name VARCHAR(10));
INSERT INTO temp VALUES(1, 'sam');
INSERT INTO temp VALUES(2, 'jesen');

SHOW BINLOG EVENTS in 'binlog.000103';	//查看binlog.000103文件内容

 MySQL系列(五)--二进制日志对主从复制的影响-LMLPHP

ROW:RBR

  基于行的日志格式,如果因为误操作而修改了数据库中的数据,同时又没有备份可以恢复,通过日志中记录的日志操作,进行反向处理达到

数据恢复的目的

优点:

  主从复制更加安全,适用于任何SQL的使用,包括存储过程、触发器,自定义函数等

  对每行数据的修改比基于段的复制高效,减少从数据库锁的使用

缺点:

  要求主从表结构一致

  无法在从服务器上单独执行触发器

  记录日志量很大,因为这个问题,在MySQL5.7版本之后,通过参数binlog_row_image=[FULL|MINIMAL|NOBLOB]

Full:代表记录一行中所有列,无论这个列是否被修改,默认

Minimal:只记录修改的列

NoBlob:和full差不多,只是如果blob/text没有被修改,不会记录该列

PS:对于row的格式,如果通过mysqlbinlog查看日志,需要-vv参数,否则显示内容人工无法识别,例如:mysqlbinlog -vv binlog.000097;

mixed: 

  混合日志格式binlog_format=mixed,根据SQL语句由系统决定使用基于row还是statement

综上:

  建议使用row,而非statement

03-17 03:58