一、复制机制的实现原理
从高层来看，复制分成三步：
(1) master
将改变记录到二进制日志
(binary log)
中（这些记录叫做二进制日志事件，
binary log events
）；
(2) slave
将
master
的
binary log events
拷贝到它的中继日志
(relay log)
；
(3) slave
重做中继日志中的事件，将改变反映它自己的数据。
二、复制实现级别
1. Row
日志中会记录成每一行数据被修改的形式，然后在 slave 端再对相同的数据进行修改。
优点：在 row 模式下，bin-log 中可以不记录执行的 SQL 语句的上下文相关的信息，仅仅只需要记录哪一条记录被修改了，修改成什么样了。所以 row 的日志内容会非常清楚的记录下每一行数据修改的细节，非常容易理解。而且不会出现某些特定情况下的存储过程或 function ，以及 trigger 的调用和触发无法被正确复制的问题。
缺点：在 row 模式下，所有的执行的语句当记录到日志中的时候，都将以每行记录的修改来记录，这样可能会产生大量的日志内容
2. Statement
每一条会修改数据的 SQL 都会记录到 master 的 bin-log 中。slave 在复制的时候 SQL 进程会解析成和原来 master 端执行过的相同的 SQL 再次执行。
优点：在 statement 模式下，首先就是解决了 row 模式的缺点，不需要记录每一行数据的变化，减少了 bin-log 日志量，节省 I/O 以及存储资源，提高性能。因为他只需要记录在 master 上所执行的语句的细节，以及执行语句时候的上下文的信息。
缺点：在 statement 模式下，由于他是记录的执行语句，所以，为了让这些语句在 slave 端也能正确执行，那么他还必须记录每条语句在执行的时候的一些相关信息，也就是上下文信息，以保证所有语句在 slave 端杯执行的时候能够得到和在 master 端执行时候相同的结果。复制容易问题
3. mixed
在 Mixed 模式下，MySQL 会根据执行的每一条具体的 SQL 语句来区分对待记录的日志形式，也就是在 statement 和 row 之间选择一种。新版本中的 statment 还是和以前一样，仅仅记录执行的语句。而新版本的 MySQL 中对 row 模式也被做了优化，并不是所有的修改都会以 row 模式来记录，比如遇到表结构变更的时候就会以 statement 模式来记录，如果 SQL 语句确实就是 update 或者 delete 等修改数据的语句，那么还是会记录所有行的变更。
三、复制常用架构
1、单一
master
和多
slave
由一个
master
和一个
slave
组成复制系统是最简单的情况。
Slave
之间并不相互通信，只能与
master
进行通信。如下：
如果写操作较少，而读操作很时，可以采取这种结构。你可以将读操作分布到其它的
slave
，从而减小
master
的压力。但是，当
slave
增加到一定数量时，
slave
对
master
的负载以及网络带宽都会成为一个严重的问题。
这种结构虽然简单，但是，它却非常灵活，足够满足大多数应用需求。一些建议：
(1)
不同的
slave
扮演不同的作用
(
例如使用不同的索引，或者不同的存储引擎
)
；
(2)
用一个
slave
作为备用
master
，只进行复制；
(3)
用一个远程的
slave
，用于灾难恢复；
2、Dual Master (Master-Master)
Master-Master 复制的两台服务器，既是 master ，又是另一台服务器的 slave
