mysql复制功能（待完成，挖个坑 不定期填上）

MYSQL复制功能提供分担读负载

可以进行水平扩展，增加一个或多个备库，备库可以分担读负载

为高可用，灾难恢复，备份提供更多的选择

复制基于主库的二进制日志，在备库上存放这些日志，复制是异步的，所以同一时间点，备库与主库不一致，并且无法保证主库和备库延迟

影响主库延迟的因素很多

复制解决了：在不同服务器的数据分布，利用二进制日志增量，不需要太多的带宽，但是使用基于行的复制在进行大批量的更改时会对带宽带来一定压力，这个压力在同一个IDC机房可以忽略，跨IDC就要注意了，应该分批进行

解决了数据读取的负载均衡，需要其他组件配合完成，利用DNS轮询的方式吧程序的读连接到不同备份数据库

使用LVS(Linux Virtual Server) haproxy这样的代理方式都可以达到，非共享架构，同样的数据分布在多个数据库上

增加了数据的安全性，利用备库的备份来减少主库负载，复制并不能代替备份，因为备份和复制的工作是不同的，如果在主库不小心错误的修改了，删除了数据，由于备库通常延迟很小，很难通过备库来恢复错误数据，必须依靠备份。数据库备份任何时候都非常重要，方便进行数据库高可用架构的部署，避免MYSQL单点失败

实现数据库高可用和故障切换

实现数据库在线升级 我们可以使用高版本mysql来作为主库的备库，再养在配置高可用工具的时候，就可以在很短的时候进行升级。同时测试兼容性

二进制日志：记录了所有对Mysql数据库的修改事件，包括增删查改事件和对表的结构的修改事件

二进制日志的格式：基于段的格式binlog_format=STAMTEMENT

优点：日志记录量相对较小，节约磁盘以及网络I/O

只对一条记录修改或者插入

row格式所产生的日志量小于端产生的日志量

缺点：必须记录上下文信息，保证语句在从服务器上执行结果和在主服务器上相同

            特定函数UUID()，user()这样的非确定性函数还是无法复制

            可能会造成mysql复制的主备服务器数据不一致

基于行 binlog_format=ROW

可以避免MYSQL复制出现主从不一致 默认的 纪录的是修改信息

同一条SQL语句修改了1W条数据，则基于段就会纪录这个sql语句 一条

基于行就会有10000条记录分别记录每一行数据修改

优点：使主从复制更加安全

            对每一行数据的修改比基于段的复制高效

        当失误操作我们可以通过分析二进制日志，来对日志中的纪录的数据修改操作做反向处理的方式来达到恢复数据的目的。

缺点：记录日志量大 增加了binlog_row_image = [FULL|MINIMAL|NOBLOB]

FULL所有，无论是否修改过

MINIMAL，纪录修改的

NOBLO    BLOB和TEST列没修改就不会记录他们

混合日志格式 binlog_format = MIXED

折中的选择 根据sql语句由系统决定是基于段还是基于行

大部分都会基于段，除了非线性函数这种，会基于行

数据量的大小由所执行的SQL语句决定

建议使用混合 和row，如果考虑安全性且在内外复制，可以用row格式，最好使用minimal

复制工作三步骤：

1：主服务器将变更写入二进制日志（需要开启，默认是不开的）

2.从读取主的二进制日志变更并写入到ready_log中，首先要启动工作线程I/O线程，和主库建立客户端连接

如果该线程追赶上主库就sleep直到通知其又有新事件产生

分为基于日志点和基于GTID的复制

3.在从上重放relay_log中的日志

未完待续  挖个坑