Mysql的 Replication 是一个异步的复制过程，从一个 Mysql instace(我们称之为 Master)复制到另一个 Mysql instance(我们称之 Slave)。在 Master 与 Slave 之间的实现整个复制过程主要由三个线程来完成，其中两个线程(Sql线程和IO线程)在 Slave 端，另外一个线程(IO线程)在 Master 端。
要实现 MySQL 的 Replication ，首先必须打开 Master 端的Binary Log(mysql-bin.xxxxxx)功能，否则无法实现。因为整个复制过程实际上就是Slave从Master端获取该日志然后再在自己身上完全 顺序的执行日志中所记录的各种操作。打开 MySQL 的 Binary Log 可以通过在启动 MySQL Server 的过程中使用 “—log-bin” 参数选项，或者在 my.cnf 配置文件中的 mysqld 参数组([mysqld]标识后的参数部分)增加 “log-bin” 参数项。
MySQL 复制的基本过程如下：
1. Slave 上面的IO线程连接上 Master，并请求从指定日志文件的指定位置(或者从最开始的日志)之后的日志内容;
2. Master 接收到来自 Slave 的 IO 线程的请求后，通过负责复制的 IO 线程根据请求信息读取指定日志指定位置之后的日志信息，返回给 Slave 端的 IO 线程。返回信息中除了日志所包含的信息之外，还包括本次返回的信息在 Master 端的 Binary Log 文件的名称以及在 Binary Log 中的位置;
3. Slave 的 IO 线程接收到信息后，将接收到的日志内容依次写入到 Slave 端的Relay Log文件(mysql-relay-bin.xxxxxx)的最末端，并将读取到的Master端的bin-log的文件名和位置记录到master- info文件中，以便在下一次读取的时候能够清楚的高速Master“我需要从某个bin-log的哪个位置开始往后的日志内容，请发给我”
4. Slave 的 SQL 线程检测到 Relay Log 中新增加了内容后，会马上解析该 Log 文件中的内容成为在 Master 端真实执行时候的那些可执行的 Query 语句，并在自身执行这些 Query。这样，实际上就是在 Master 端和 Slave 端执行了同样的 Query，所以两端的数据是完全一样的。
（需要自定义不同的端口，主：3306，从：3307）；
远程连接mysql： mysql -h127.0.0.1 -uroot -padmin -P3307 （在mysql的bin文件夹下执行）
create user ‘repl’@’127.0.0.1’ identified by ‘admin’;
GRANT REPLICATION SLAVE ON . TO ‘repl’@’127.0.0.1’; 【这里我指定数据库（rtzc_pnc_base .）时报错，而指定全库（.*）时会成功。】
一般是先将所有的表加锁（只读），然后copy磁盘上的数据库文件夹。我这里直接停止服务，然后将数据文件拷贝过去
（注意有\G后面不加;，否则报错） 记下file和position字段对应的参数
change master to master_host=’127.0.0.1’, master_port=3306, master_user=’repl’, master_password=’admin’, master_log_file=’mysql-bin.000001’, master_log_pos=154;
注意：master_port对应主库的端口，master_log_file和master_log_pos对应刚才show master status记下的参数。
start slave; （mysql5.5是slave start;启动）
在从库可以通过show slave status\G来查看一些参数。
寻找问题的方法：到从库的data目录下找到WIN-20151017TLX.err文件，发现里面有一行error日志，如下
解决问题方法：
只有按照原格式修改data目录下的auto.cnf文件里面的server-uuid，随便写就ok了。
参考：http://www.jb51.net/article/39935.htm
参考：http://www.cnblogs.com/yuechaotian/archive/2013/05/15/3080056.html
主从间的数据库不是实时同步，就算网络连接正常，也存在瞬间，主从数据不一致。 * 如果主从的网络断开，从会在网络正常后，批量同步。 * 如果对从进行修改数据，那么很可能从在执行主的bin-log时出现错误而停止同步，这个是很危险的操作。所以一般情况下，非常小心的修改从上的数据。
参考：http://bbs.chinaunix.net/thread-2297959-1-1.html
当主库的TPS并发较高时，产生的DDL数量超过slave一个sql线程所能承受的范围，那么延时就产生了，当然还有就是可能与slave的大型query语句产生了锁等待。
3.2.1 插入后，更新缓存服务如redis，其他节点需先读缓存中的数据。然后再写入从mysql。
丁奇的transefer是一个不错的方案，不过一般公司受限于对mysql的代码修改能力的限制和对mysql的掌控能力，还是不太适合；
最简单的减少slave同步延时的方案就是在架构上做优化，尽量让主库的DDL快速执行。还有就是主库是写，对数据安全性较高，比如
sync_binlog=1，innodb_flush_log_at_trx_commit=1 之类的设置，而slave则不需要这么高的数据安全，完全可以讲sync_binlog设置为0或者关闭binlog，innodb_flush_log_at_trx_commit 也可以设置为0来提高sql的执行效率。
另外就是使用比主库更好的硬件设备作为slave；
mysql-5.6.3已经支持了多线程的主从复制。原理和丁奇的类似，丁奇的是以表做多线程，oracle使用的是以数据库(schema)为单位做多线程，不同的库可以使用不同的复制线程。
参考：http://www.jb51.net/article/41545.htm
参考：http://ju.outofmemory.cn/entry/56176