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

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文件内容

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