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