Trove系列（七）——Trove的Mysql的复制功能介绍

描述提供各类复制功能的支持对于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>