描述提供各類複製功能的支持對於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:mysql
$ 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>sql