Mysql之复制服务

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】