mysql的replication

mysql的replication"/>

mysql的replication

Replication的思想是将数据在集群的多个节点同步、备份，以提高集群数据的可用性(HA)；Mysql使用Replication架构来实现上述目的，同时可以提升了集群整体的并发能力。5.6版本作为一个里程碑，对replication做了不少的优化调整，提高了集群数据的一致性、同步的性能以及数据自动恢复(recovery)的能力。(本文内容基于MySQL 5.6+，不过在5.7+版本仍有部分调整)

Replication架构通常由一个master和一个或者多个slaves构成，master接收应用的writes操作(事务中的read、write操作均有master处理)，slaves接收read操作。在master上发生的数据变更，都将会复制给slaves，从直观而言，replication架构解决了：1)数据多点备份，提高数据可用性。 2)读写分流，提高集群的并发能力。(并非是负载均衡)3)让一些非实时的数据操作，转移到slaves上进行。

下文中提到的“变更操作”为“insert”、“update”、“delete”等，与MySQL中的“update events”、“事务操作”、“writes”同义。

Replication具有如下优点：

1)扩展：将负载分布在多个slaves上以提高性能，所有的writes以及事务中的read操作都将有master处理，其他reads将转发给slaves；对于“读写比”较高的应用，replication可以通过增加slaves节点来提高并发能力；因为write只能在master上提交，因此架构扩展对提升write并发能力并不明显，对于writes密集性应用我们应该考虑其他架构。

2)数据安全：slave可以中断自己的replication进程，这不会打断master上的数据请求，所以可以在slave上运行backup服务，定期全量backup是保护数据的手段之一。(如果在master上执行backup，需要让master处于readonly状态，这也意味这所有的write请求需要阻塞)。

3)分析：数据在master上创建，那么数据分析可以在slave上进行，这将不会影响master的性能。利用mysql做数据分析(或者数据分析平台的源数据)，通常都是将某个slave作为数据输入端。

4)远距数据分布：如果master的物理位置较远，你可以在临近需求的地方部署slaves，以便就近使用数据，而不需要总是访问远端的master，这在数据分析、数据备份与容灾等方面有很大帮助。

MySQL架构的演变分多个阶段，目前基于replication架构模式的更高级架构设计有“MySQL Fabric”和“MySQL Cluster”。本文主要讲解基本的replication模式，如下为replication与Fabirc、Cluster的区别，以便我们做技术选型：

1、MySQL Fabirc

Farbic由replication基础特性和一些扩展框架构建而成，用于管理MySQL Servers Farms，与基本的replicaiton相比，它实现了2个核心的特性：HA和sharding。Fabric集群中任何时候只有一个Primary(即master)，其他的实例为Secondaries(即slaves)；通过使用replication，将数据在多个节点上备份，HA总是保持集群的数据可用性。如下特性是replication所不具备的：

1)故障检测和角色迁移(Failover)：Fabric进程用于监控集群中的所有节点，如果发现primary失效，稍后他将从Secondaries中选择一个“数据最新”的节点，并提升为primary；此后其他的secondaries将从新的priamry上同步数据变更操作。Connectors(比如Connector/J客户端)发现primary故障时也会通知Fabirc，那么Fabric将通知信息作为决策的一部分来判定priamry的状态。这个特性简称为“自动Failover”，是replication架构中必备的手段之一。

2)数据库请求路由(Router)：当Fabric提升一个新的primary后，它将会更新state store(存储replication的节点状态等)，此后Connectors将会获取新的state数据并在客户端本地cache。因此，application不需要时刻关注(aware)集群中servers拓扑结构的变化，只需要根据state cache中的server状态，将writes发送给相应的primary即可。这种特性有Connectors客户端与与Fabric共同实现，在普通的replication架构中，客户端自动角色路由是无法完成的。如果cache中拓扑不是最新的，application的操作异常将会反馈给Fabirc，参考1)。

Fabirc支持sharding，对较大规模的数据可以非常便捷的在集群中分布而无需太多人工干预，我们可以简单的认为Fabric是replication模式的完善，支持自动Failover。对于互联网应用，Fabric架构简单而且有效，是首选方案。

2、MySQL Cluster

相对于Fabirc，MySQL Cluster支持更大规模的数据，其架构模式和原理也更加复杂。Cluster是一个易于扩展、实时的、ACID兼容的事务性数据库，支持“全分布式”、“多Master”架构，无单点问题；MySQL Cluster可以部署在普通的商业机器上，多节点水平扩展、Server间数据自动sharding和负载均衡，用于服务read、write都密集的应用，可以使用SQL和NOSQL接口访问数据。Cluster的架构思想与Hadoop非常类似，它设计的前提是“认为每个Node都是易于出错的”、集群规模巨大、多租户，所以它提供了数据备份机制、自动迁移、自动Failover等特性，来保证可用性、健壮性。

MySQL Cluster使用了一个插件式的存储引擎，与MySQL 存储引擎(InnoDB、MySAM)架构有很大不同，我们在此不做详细介绍，只需要知道它的核心特性为：数据集并不是存储某个特定的MySQL实例上，而是被分布在多个Data Nodes中，即一个table的数据可能被分散在多个物理节点上，任何数据都会在多个Data Nodes上冗余备份。任何一个数据变更操作，都将在一组Data Nodes上同步(严格意义上的同步，synchronous，二阶段提交？)以保证数据的一致性。

由此可见，Replication