mysql binlog 复制

1  基本概念

（1）redolog、 undolog和binlog

         undolog 实现原子性。每当操作数据前，首先将数据备份到一个地方（这个存储数据备份的地方称为undolog）。然后再修改数据。如果出现了错误或者用户执行了rollback语句，可以利用undolog中的备份将数据恢复到事务开始之前的状态。

        redolog 实现持久性。每当操作数据前，将数据真正更改时，先前相关操作写入重做日志。这样当断电，或者一些意外，导致后续任务无法完成时，系统恢复后，可以继续完成这些更改执行这些操作来恢复数据。 

       比如某一时刻数据库down机了，有两个事务，一个事务已经提交，另一个事务正在处理数据库重启的时候就要根据日志进行前滚及回退，把已提交事务的更改写到数据文件，未提交事务的更改恢复到事务开始前的状态。

（2）binlog的三种模式

       一 row模式

       日志中会记录成每一行数据被修改的形式，然后在 slave 端再对相同的数据进行修改。 如果是insert或者delete操作，会记录插入或者删除的记录的所有字段内容完整内容，如果是update操作，会记录修改前的数据和修改后的数据（修改前的数据包括没有发生变更的字段），例如有A，B，C三个字段，只修改了A字段，那么binlog里会记录改前的A，B，C三个字段的值，以及A字段修改后的值。

      二 statement模式

      每一条会修改数据的SQL会记录到master的binlog中。slave在复制的时候SQL进程会解析成和原来master端执行过的相同的SQL再次执行。优点是传输的数据比较少，缺点是很难做到主从一致。

      三 mixed 模式

      实际上就是前两种模式的结合。在 Mixed 模式下，MySQL 会根据执行的每一条具体的 SQL 语句来区分对待记录的日志形式，也就是在 statement 和 row 之间选择一种。新版本中的 statment 还是和以前一样，仅仅记录执行的语句。而新版本的 MySQL 中对 row 模式也被做了优化，并不是所有的修改都会以 row 模式来记录，比如遇到表结构变更的时候就会以 statement 模式来记录，如果 SQL 语句确实就是 update 或者 delete 等修改数据的语句，那么还是会记录所有行的变更。

        New Optimized Row-based Replication – MySQL 5.6 provides a new option variable binlog-row-image=minimal that enables applications to replicate only data elements of the row image that have changed following DML operations.  This improves replication throughput for both the master and slave(s) and minimizes binary log disk space, network resource and server memory footprint.

        新的基于行模式，用法是 binlog-row-image=minimal 设置该选项后，对于DML操作修改的数据，只有发生变化的字段才保存到binlog里面，（insert和delete还是全字段）。这提高了master和slave的复制吞吐量，减小了binlog的磁盘占用，网络资源和内存使用。

2  mysql主备复制结构

         Mysql的复制（replication）是一个异步的复制，从一个Mysql instace（称之为Master）复制到另一个Mysql instance（称之Slave）。实现整个复制操作主要由三个进程完成的，其中两个进程在Slave（Sql进程和IO进程），另外一个进程在 Master（IO进程）上。
         要实施复制，首先必须打开Master端的binary log（bin-log）功能，否则无法实现。因为整个复制过程实际上就是Slave从Master端获取该日志然后再在自己身上完全顺序的执行日志中所记录的各种操作。
         复制的基本过程如下：
（1）Slave上面的IO进程连接上Master，并请求从指定日志文件的指定位置（或者从最开始的日志）之后的日志内容；
（2）Master接收到来自Slave的IO进程的请求后，通过负责复制的IO进程根据请求信息读取制定日志指定位置之后的日志信息，返回给Slave 的IO进程。返回信息中除了日志所包含的信息之外，还包括本次返回的信息已经到Master端的bin-log文件的名称以及bin-log的位置；
（3）Slave的IO进程接收到信息后，将接收到的日志内容依次添加到Slave端的relay-log文件的最末端，并将读取到的Master端的 bin-log的文件名和位置记录到master-info文件中，以便在下一次读取的时候能够清楚的高速Master“我需要从某个bin-log的哪个位置开始往后的日志内容，请发给我”；
（4）Slave的Sql进程检测到relay-log中新增加了内容后，会马上解析relay-log的内容成为在Master端真实执行时候的那些可执行的内容，并在自身执行。