描述提供各种复制功能的支持对于Trove来说是很关键的.本章节将描述各种使用案例和相关的用户需求。并依次提出了MySQL的初始阶段的实现。
Mysql的复制功能介绍概述
先介绍一下MySQL的复制功能原理，以便更好的理解Trove 的Mysql的复制功能。
MySQLReplicaion本身是一个比较简单的架构，就是一台MySQL服务器（Slave）从另一台MySQL服务器（Master）进行日志的复制然后再解析日志并应用到自身。一个复制环境仅仅只需要两台运行有MySQLServer的主机即可，甚至更为简单的时候我们可以在同一台物理服务器主机上面启动两个mysqldinstance，一个作为Master而另一个作为Slave来完成复制环境的搭建。但是在实际应用环境中，我们可以根据实际的业务需求利用MySQLReplication的功能自己定制搭建出其他多种更利于ScaleOut的复制架构。如DualMaster架构，级联复制架构等。
常规复制架构 Master - Slaves
在实际应用场景中，MySQL复制90%以上都是一个Master复制到一个或者多个Slave的架构模式，主要用于读压力比较大的应用的数据库端廉价扩展解决方案。因为只要Master和Slave的压力不是太大（尤其是Slave端压力）的话，异步复制的延时一般都很少很少。尤其是自从Slave端的复制方式改成两个线程处理之后，更是减小了Slave端的延时问题。而带来的效益是，对于数据实时性要求不是特别Critical的应用，只需要通过廉价的pcserver来扩展Slave的数量，将读压力分散到多台Slave的机器上面，即可通过分散单台数据库服务器的读压力来解决数据库端的读性能瓶颈，毕竟在大多数数据库应用系统中的读压力还是要比写压力大很多。这在很大程度上解决了目前很多中小型网站的数据库压力瓶颈问题，甚至有些大型网站也在使用类似方案解决数据库瓶颈dualMaster复制架构 Master - Master
有些时候，简单的从一个MySQL复制到另外一个MySQL的基本Replication架构，可能还会需要在一些特定的场景下进行Master的切换。如在Master端需要进行一些特别的维护操作的时候，可能需要停MySQL的服务。这时候，为了尽可能减少应用系统写服务的停机时间，最佳的做法就是将我们的Slave节点切换成Master来提供写入的服务。
但是这样一来，我们原来Master节点的数据就会和实际的数据不一致了。当原Master启动可以正常提供服务的时候，由于数据的不一致，我们就不得不通过反转原Master-Slave关系，重新搭建Replication环境，并以原Master作为Slave来对外提供读的服务。重新搭建Replication环境会给我们带来很多额外的工作量，如果没有合适的备份，可能还会让Replication的搭建过程非常麻烦。
为了解决这个问题，我们可以通过搭建DualMaster环境来避免很多的问题。何谓DualMaster环境？实际上就是两个MySQLServer互相将对方作为自己的Master，自己作为对方的Slave来进行复制。这样，任何一方所做的变更，都会通过复制应用到另外一方的数据库中。
如何避免两台MySQL之间的循环复制？MySQL实现是在MySQL的BinaryLog中记录了当前MySQL的server-id，而且这个参数也是我们搭建MySQLReplication的时候必须明确指定，而且Master和Slave的server-id参数值比需要不一致才能使MySQLReplication搭建成功。一旦有了server-id的值之后，MySQL就很容易判断某个变更是从哪一个MySQLServer最初产生的，所以就很容易避免出现循环复制的情况。而且，如果我们不打开记录Slave的BinaryLog的选项（--log-slave-update）的时候，MySQL根本就不会记录复制过程中的变更到BinaryLog中，就更不用担心可能会出现循环复制的情形了。级联复制架构 Master –Slaves – Slaves
在有些应用场景中，可能读写压力差别比较大，读压力特别的大，一个Master可能需要上10台甚至更多的Slave才能够支撑注读的压力。这时候，Master就会比较吃力了，因为仅仅连上来的SlaveIO线程就比较多了，这样写的压力稍微大一点的时候，Master端因为复制就会消耗较多的资源，很容易造成复制的延时。
遇到这种情况如何解决呢？这时候我们就可以利用MySQL可以在Slave端记录复制所产生变更的BinaryLog信息的功能，也就是打开—log-slave-update选项。然后，通过二级（或者是更多级别）复制来减少Master端因为复制所带来的压力。也就是说，我们首先通过少数几台MySQL从Master来进行复制，这几台机器我们姑且称之为第一级Slave集群，然后其他的Slave再从第一级Slave集群来进行复制。从第一级Slave进行复制的Slave，我称之为第二级Slave集群。如果有需要，我们可以继续往下增加更多层次的复制。这样，我们很容易就控制了每一台MySQL上面所附属Slave的数量。这种架构我称之为Master-Slaves-Slaves架构dualMaster与级联复制结合架构(Master-Master-Slaves)
级联复制在一定程度上面确实解决了Master因为所附属的Slave过多而成为瓶颈的问题，但是他并不能解决人工维护和出现异常需要切换后可能存在重新搭建Replication的问题。这样就很自然的引申出了DualMaster与级联复制结合的Replication架构，我称之为Master-Master-Slaves架构和Master-Slaves-Slaves架构相比，区别仅仅只是将第一级Slave集群换成了一台单独的Master，作为备用Master，然后再从这个备用的Master进行复制到一个Slave集群。下面的图片更清晰的展示了这个架构的组成：
实现的理由/实现的好处大多数Trove 支持的datastore目前都具有复制能力来实现以下使用场景:
通过读复制来扩容操作恢复离线备份
为了完善产品， Trove需要支持这些场景的简单配置和管理. 目前Amazon RDS 已经实现了MySQL的第一种使用场景和部分第二种使用场景. 最终这些需求都要被评估是否实现; 本章节的目标聚焦于MySQL 的通过读复制来扩容功能。可以期待的是：其他datastore的本范围的功能也将被逐渐实现，进而逐渐实现余下的需求。.
使用场景的需求下面是使用数据库复制功能的场景。 读复制 (备机)主机在备机之前就上电，且主机已经包含数据
一主对N备的模式在第一阶段的实现将允许N个独立的calls. 再以后的实现中可以继续优化。
备机能够被设置为只读（也许是缺省的选项）
一个备机能够从复制组中分离，从而作为一个独立的节点运行。
一个预先就存在的非复制组中的节点能够作为新的复制组中的主机
备机的健康状态是可监控的
多域的容灾一个域中的主机可以被不同的域中的备机所镜像。
域配置将被实现，用户能够简单的选择"MultiZone DR" ，Trove 能够知道主机和备机放到何处。
能够从备机恢复数据到主机，通过直接方式或者通过制作存在Swift 里的备份来实现。
能够在已经运行的mysql 实例上实现倒换功能。
单域的切换能够在两个同一域中的两个实例上实现主主复制；
能够在预先存在的实例上安装本功能；
能够切换激活的主机为备机；
范围第一阶段实现：目标Juno release。 将实现Use Case A 核心功能 和MySql 的复制功能。其他datastore的复制功能将不再本规划范围内。
影响这些改动将影响所有的 Trove组件. 配置需要的配置文件将没有改动.
使用例子Trove中最初被实施的复制（replication）使用了mysql内置的复制（replication）特性，用于MysqL数据储存。后续阶段将此功能扩展到包括聚合和复制所有Trove支持的数据储存。第一个版本的这个特性,用户可以创建一个单独的MySQL实例,然后创建一个从属的实例。创建从属（slave）的行为会建立一个新的与最初的实例同等的复制实例 以下命令说明用户将如何做到这一点。以下的Trove实例运行一个mysql5.5：
$ trove list+--------------+------+-----------+-------------------+--------+-----------+------+| ID | Name | Datastore | Datastore Version | Status | Flavor ID | Size |+--------------+------+-----------+-------------------+--------+-----------+------+| f0726c91d322 | m1 | mysql | 5.5 | ACTIVE | 7 | 2+-- -----------+------+-----------+-------------------+--------+-----------+------+ 现在将创建第二个(slave)实例引用上面提供的master,如下。 $ trove create s1 7 --size 2 --slave_of f0726c91d322+-------------------+--------------------------------------+| Property | Value |+-------------------+--------------------------------------+| created | 2014-06-13T14:33:27 || datastore | mysql || datastore_version | 5.5 || flavor | 7 || id | 521f95755c43 || name | s1 || slaveOf | f0726c91d322 || status | BUILD || updated | 2014-06-13T14:33:27 || volume | 2 |+-------------------+--------------------------------------+ 用户可以现在查看复制的状态对（replicated pair）如下所示。 $ trove show 521f95755c43+-------------------+---------------------------------------------+| Property | Value |+-------------------+---------------------------------------------+| created | 2014-06-13T14:33:27 || datastore | mysql || datastore_version | 5.5 || flavor | 7 || id | 521f95755c43 || name | s1 || slaveOf | f0726c91d322 || status | ACTIVE || updated | 2014-06-13T14:33:27 || volume | 2 |+-------------------+---------------------------------------------+$ trove show f0726c91d322+-------------------+---------------------------------------------+| Property | Value |+-------------------+---------------------------------------------+| created | 2014-06-13T14:33:27 || datastore | mysql || datastore_version | 5.5 || flavor | 7 || id | f0726c91d322 || name | s1 || slaves | 521f95755c43 || status | ACTIVE || updated | 2014-06-13T14:33:27 || volume | 2 |+-------------------+--------------------------------------------+ 断开一个slave与master的连接,用户将会“分离（detach）”: $ trove detach_replication <slave instance>
