Mysql Classic Replication
一、传统复制的组成：
1、master server：
用户写数据。
生成binlog。
2、slave server：
接收master传来的binlog。
应用这些binlog从而达到重现master的用户操作。
二、传统复制的原理：
1、master跟新的数据，要写binlog。
2、slave在master注册一个i/o_thread进程，来捕获binlog日志的变更。
3、i/o_thread截取日志变更之后写入到本地的relay log里。
4、然后通过sql_thread到relay log 里进行解析执行到slave端。
5、在解析的过程中会判断是否存在主键，如果没有，在查看是否有二级索引，如果没有，就直接全表扫描。
三、binlog的主要作用：
1、记录master变更的日志文件。
2、记录的格式分为statement(SBR)、ROW（RBR）、MIXED格式。
3、Event是binlog的最小单位。
4、transaction是由多event组成。
5、binlog由两种文件组成：一种是binary log file；另一种是binary log index
四、binlog的三种日志格式：
1、STATEMENT：记录的是逻辑操作，即用户执行过的sql。
2、ROW：记录的是物理操作，即用户实际修改的数据。
3、MIXED：默认使用statement记录，当遇见不确定的数据时，自动幻化为ROW格式。
注意：
所有的DCL和DDL都是用statement格式记录。
statement是一个sql对应一个event。
row是一个sql对应多个event。
五、statement和row格式的优缺点：
（一）、statement格式：
优点：
1、binlog文件较小。
2、包含所有用户执行的原始sql，方便统计和审计。
3、可以认为听过binlog数据还原某些操作。
4、主从的binlog 版本协议兼容性较好。
缺点：
1、存在安全隐患，可能导致主从不一致。（非常严重了，一般不适用生产环境）
2、对一些特殊函数赋值不准确或者不能复制。
例如：
LOAD_FILE()
UUID()
USER()
FOUND_ROWS()SYSDATA()
（二）、row格式：
优点：
1、相比statement更加安全的复制格式。（选row模式的更大原因）
2、在某些情况下复制速度更快。（复杂sql，表有主键）
3、产生比statement更少的锁。
4、所有特殊函数都能复制。
缺点：
1、binlog文件较大。在MySQL-5.6新特性参数binlog_row_image解决此问题。
2、单sql全表更新会产生大量binlog。
3、无法从binlog看见用户执行的sql。MySQL-5.6新特性参数binlog_rows_query_log_event解决此问题。
4、由于binlog太大，容易造成主从复制端的延迟。
六、搭建传统方式必要的参数：（一个是数据file，一个是位置pos）
（一）、master端：
1、获取master当前的数据快照，并获取当前的binlog号和pos号。
2、数据快照可以通过mysqldump或者Xtrabackup获取。
3、也可以停机考配数据文件。（此功能在5.6已经不能使用）
（二）、slave端：
1、通过获取数据快照搭建一个mysql服务器。
2、然后通过快照的master的binlog文件和pos来开启复制。
七、传统复制日志补齐的方式：
问题：（一主两从结构）
当master1挂掉了，需要slave1专程master，但是发现slave1的binlog记录已经到了100，而slave2记录的binlog只到90，基于传统日志怎么样进行补齐？
解决方法：
1、如果没有用到mha，就会选择slave1作为主库。
2、并在slave1上做show master status得到master的log便宜量。
3、然后在slave2上执行change语句。挂在到slave1上。
注意：
1、按照传统的方式很容易出现数据不一致，因为slave2上的90~100之间的数据已经不能同步到slave2上了。
2、这个时候可以利用mha来补救之间的数据。
3、但是在GTID出现之后，MHA已经没有价值了，因为GTID会在master_auto_postion=1;然后自己去匹配GTID的断点，进行数据的不救。