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】

 

posted @ 2016-10-24 21:25 tjc123 阅读(...) 评论(...) 编辑 收藏