Replication[复制]使得数据可以从一个Master服务器上复制到一个或多个Slave上，默认是异步复制，不需要与Master建立永久连接；基于配置，可以作用于所有库，指定的库或库中的某些表。
优点：
可扩展的解决方案：将负载分摊到多个Slave上以提高性能；在这种方案中Master只负责Write和Update, 所有的Read都分摊在多个Slave上。
数据安全性：由于数据审美观点 复制到Salve上，并且Slave可以终止复制进程。
可解析性【Analytics】：Master是数据的产生源，可将耗时的分析工作放在Slave上，这样就不会对Master有影响。
跨地域的数据分布【Long-distance data distribution】，你可以创建一个本地复本用于业务处理，而不时实使用Master。
实现方式：
MySql5.7有两种
传统的通过Master的binary Log 在Master与Slave上同步复制；
新的基于GTIDs[global transaction identifiers] ,使用GTIDs保证数据在Master和slave上的一致性。
Mysql支持不同类型的同步复制，最原始的一种：One-way异步复制【一个作为Master，其他为Slave】，此与Mysql Cluster NDB7.5的同步复制相反；
半同步【Semisynchronous】复制，事务被阻塞直到有一个Slave确认。
延迟复制【delay replication】,故意在Master之后的一段时间执行。
从本质上看，最基本的有两种复制方式：SBR【Statement Based Replication】，基于sql语句的复制；RBR【Row Based Replication】，只对改变的行复制。
当然也可以将两者混合，就延生出了第三种方式 MBR【Mixed Based Replication】。
Prior to MySQL 5.7.7, statement-based format was the default. In MySQL 5.7.7 and later, row-based format is the default.
在复制服务中有三种线程参与：BinLog dump thread , Slave I/O thread和 Slave SQL thread.
BinLog dump thread:当Slave连接Master时，Master会创建该线程用于传输BinLog到Slave上。
Slave I/O thread :当在Slave上运行START SLAVE时创建，用于连接Master并请求BinLog，之后再把Log写到本地的relay log中供Slave SQL thread 使用。
Slave SQL thread: 读取relaylog并执行Events。
复制通道【Replication Channels】