What is Orchestrator?
orchestrator是MySQL復制結構的一個拓撲管理工具
其主要有以下幾個特征
1.自動監測數據庫復制的結構及其狀態
2.提供了GUI，CLI，API等接口來檢查復制拓撲的狀態以及做一些調整的操作
3.支持自動的master failover，當復制結構的server掛掉以后（不管手動還是自動的），能夠重新形成復制的拓撲結構
4.不依賴於特定的server版本或分支(MySQL, Percona Server, MariaDB or even MaxScale binlog servers)
5.支持多種類型的拓撲結構，不管是單個的主從還是成百上千個server組成的多級復制都不在話下
6.他的GUI不只是做向你report拓撲狀態而已，你可以在Orchestrator web頁面通過拖拽或者刪除節點來改變復制拓撲（CLI和API也能做）
從下面的動態圖能看出這一炫酷的功能
Orchestrator的manual講解非常的詳盡--他的manual已經搬家了，請看這，所以這里就不在講他的完整的安裝配置，我們只是從宏觀上來講一下Orchestrator的工作原理，同時來聊聊一些重要的、好玩的配置
How Does It Work?
1.Orchestrator是用go來寫的(binaries, including rpm and deb packages are available for download).
2.它本身需要自己的數據庫后台來存儲管理數據庫集群拓撲結構的相關信息
3.至少需要一個Orchestrator后台進程，但是推薦在多個不同的主機上運行多個Orchestrator后台，這些后台節點共用一個后台數據庫，但是同時只有一個是active的（可以在web界面的status菜單中查看哪一個節點是active的，也可以通過數據庫中的active_node表查看）
Using MySQL As Database Backend, Isn’t That A SPOF?
中間件的HA也應該是DBA必須應該考慮到的問題，后台數據庫使用單點，會不會出現SPOF呢？
答案是不是不會，而是不用擔心。
如果Orchestrator后台數據庫掛了，並不是我們監控的MySQL集群就不提供服務了，只是說不受orchestrator的監控了，這跟MHA的原理類似，一切照舊，就是不能執行failover，直至MHA failback。
稍顯別扭的是他需要后台數據庫存儲，對HA也明確的支持，在這一點上，希望將來有所改變吧
Database Server Installation Requirements
Orchestrator只需要帶有SUPER, PROCESS, REPLICATION SLAVE, RELOAD權限的一個用戶來連接數據庫server集群，有了這些權限，他就能夠檢查節點的復制狀態以及執行復制結構變換，他支持多種不同的方式的復制：基於binlog位點的，GTID的，偽GTID以及binlog server
沒有必要在db server上安裝其他軟件
Automatic Master Failure Recovery
下面是一個master掛掉然后提升一個slave為master的例子，他將會選擇最新的slave來提升為master。
在上面的測試中，我們掛掉rep1（master）,Orchestrator將rep4提升為new master，別的slave從新master開始復制數據
一般默認的設置是，rep1 failback回來的話，將恢復成原來rep1作為master的結構，如果不想用這個默認設置的話，可以在配置中配置ApplyMySQLPromotionAfterMasterFailover:True
Command Line Interface
下面是使用CLI的一些例子
1.打印拓撲結構
> orchestrator -c topology -i rep1:3306 cli
rep1:3306 [OK,5.6.27-75.0-log,ROW,>>]
+ rep2:3306 [OK,5.6.27-75.0-log,ROW,>>,GTID]
+ rep3:3306 [OK,5.6.27-75.0-log,ROW,>>,GTID]
+ rep4:3306 [OK,5.6.27-75.0-log,ROW,>>,GTID]
+ rep5:3306 [OK,5.6.27-75.0-log,ROW,>>,GTID]
2.移動slave
orchestrator -c relocate -i rep2:3306 -d rep4:3306
結果如下
> orchestrator -c topology -i rep1:3306 cli
rep1:3306 [OK,5.6.27-75.0-log,ROW,>>]
+ rep3:3306 [OK,5.6.27-75.0-log,ROW,>>,GTID]
+ rep4:3306 [OK,5.6.27-75.0-log,ROW,>>,GTID]
+ rep2:3306 [OK,5.6.27-75.0-log,ROW,>>,GTID]
+ rep5:3306 [OK,5.6.27-75.0-log,ROW,>>,GTID]
正如所想，rep2級聯到rep4上去了
Long Queries
GUI上還有一個很nice的功能是他能展現整個復制結構中所有內部節點上的慢查詢，而且我們還可以通過GUIkill掉這些慢查詢
Orchestrator Configuration Settings
orchestraor的配置保存在/etc/orchestrator.conf.json文件中，包含有很多的配置選項，下面抽取一些比較重要的解釋一下：
1.SlaveLagQuery：檢查復制延遲
2.AgentAutoDiscover：設置為true的話，orchestrator將會自動發現復制拓撲的變化
3.HTTPAuthPassword and HTTPAuthUser：避免誰都可以登錄web管理頁面來改變復制拓撲
4.RecoveryPeriodBlockSeconds：避免資源抖動
5.RecoverMasterClusterFilters：定義哪些集群可以自動failover/recover
6.PreFailoverProcesses：定義failover前orchestrator做什么操作
7.PostFailoverProcesses：定義failover后orchestrator做什么操作
8.ApplyMySQLPromotionAfterMasterFailover：failover后將提升為master的slave獨立出來
9.DataCenterPattern：如果有多個數據中心，可以采用不同顏色標記
Limitations
orchestrator提供給我們豐富的功能，同時，我們也應該意識到他說存在的限制於不足
關鍵一點是一個簡單的方式來讓我們將一個slave提升為master，這在master需要升級的時候會用到這一功能，還有就是計划好的failover（known）
功能限制
1.slave不能手動提升為master
2.不支持多源復制
3.不支持並行復制
4.不支持與PXC聯合使用
Is Orchestrator Your High Availability Solution?
如果你還在手動的處理一些復制的問題，你都可以將他們集成到你的HA架構中，或者囊括到你的failover處理邏輯中，為了實現這一切，我們只需在orchestrator中配置相關的功能即可
1.應用連接變更
a.vip處理
b.DNS變更
c.proxy server連接變更
。 。 。
2.自動將從庫設置為只讀，以免發生在非主節點上寫出數據導致的數據一致性問題
3.隔離宕掉的master，以免crashed master failback而發生腦裂
4.是否采用半同步以免master failure而導致數據丟失，這個功能也需要手動添加到配置里面
相比MHA或者failover而言，上面這些都是需要orchestrator做的事情
更多信息blog