摘要：數據一致性，不再是異步復制。的配置文件是建立一個服務，監控特定的對象例如元數據等等的鍵值以及當值發生變化時執行某些操作。

https://bobcares.com/blog/mys...

Redundant devices to combat hardware failures

Shared storage with SAN and NAS

Storage replication using DRBD

MySQL replication to avoid single point failures

MySQL clustering

Galera multi-master MySQL replication

Percona XtraDB Cluster

Percona XtraDB Cluster與MySQL Replication區別在于：

分布式系統的CAP理論：

C：一致性，所有節點的數據一致；
A：可用性，一個或多個節點失效，不影響服務請求；
P：分區容忍性，節點間的連接失效，仍然可以處理請求；
任何一個分布式系統，需要滿足這三個中的兩個。

MySQLReplication：可用性和分區容忍性；

Percona XtraDBCluster：一致性和可用性。

因此MySQL Replication并不保證數據的一致性，而Percona XtraDB Cluster提供數據一致性。

Percona XtraDBCluster是MySQL高可用性和可擴展性的解決方案。Percona XtraDBCluster提供的特性有：

同步復制，事務要么在所有節點提交或不提交。

多主復制，可以在任意節點進行寫操作。

在從服務器上并行應用事件，真正意義上的并行復制。

節點自動配置。

數據一致性，不再是異步復制。

Percona XtraDBCluster完全兼容MySQL和Percona Server，表現在：

數據的兼容性

應用程序的兼容性：無需更改應用程序

它的集群特點是：

集群是有節點組成的，推薦配置至少3個節點，但是也可以運行在2個節點上。

每個節點都是普通的mysql/percona服務器，可以將現有的數據庫服務器組成集群，反之，也可以將集群拆分成多帶帶的服務器。

每個節點都包含完整的數據副本。

優點如下：

當執行一個查詢時，在本地節點上執行。因為所有數據都在本地，無需遠程訪問。

無需集中管理。可以在任何時間點失去任何節點，但是集群將照常工作。

良好的讀負載擴展，任意節點都可以查詢。

缺點如下：

加入新節點，開銷大。需要復制完整的數據。

不能有效的解決寫縮放問題，所有的寫操作都將發生在所有節點上。

有多少個節點就有多少重復的數據。

那么這樣一個MySQL集群方案，在我們傳統的物理機環境的安裝部署，是否會很復雜呢？熟悉其組件及工作原理之后，安裝倒是不特別復雜。我們以CentOS系列為范例，簡要看看其安裝配置流程：

Percona作為標準的Catalog項目出現在Rancher Server1.1版本之后，如果你使用的是較低的版本，例如v1.0.1，在數據庫分類里將只會見到MariaDB Galera Cluster項目。當然你可以在低版本中添加自定義的Catalog，例如https://github.com/alanpeng/M...

部署好的Percona XtraDB Cluster集群宿主機結構如圖所示（除了拉起Percona-XtraDB-Cluster集群之外，還在其前端加入了一個Rancher內置的LoadBalancer）：

將此Catalog項目打開，我們可以看見其docker-compose.yml及rancher-compose.yml文件的內容如下：

Stack/Service結構示意圖：

這里的12個容器角色如下：Node節點3個，運行confd服務；ClusterCheck節點3個分別監聽集群節點健康狀態；Server節點3個，是數據庫主服務應用；3個Data作為數據卷共享的提供，是sidekick容器類型。

所有容器列表如下：

數據庫連接驗證測試：

從前端負載均衡宿主機的IP訪問數據庫，執行語句show status like "wsrep%"；返回的結果表明數據庫集群節點數為3，同步復制狀態正常。

以上PXC集群運行于容器之上并被Rancher平臺管理，其中的具體實現細節較多，因為我們需要這樣的數據庫集群滿足彈性伸縮的要求，舉例來說也就是可以動態的將集群節點數由3個增加至更多，那么必然每個節點的配置文件需要動態的進行更新，要做到這一點，我們可以結合confd與Rancher的metadata元數據服務來實現，當然這里涉及到數據庫集群專有的技術，giddyup專有工具的結合也是必不可少的選擇。

1. 首先給出整個項目的代碼文件供參考

分3個模塊：
https://github.com/Flowman/do...
https://github.com/Flowman/do...
https://github.com/Flowman/do...

2. 數據庫集群配置工具giddyup

https://github.com/cloudnauti...
在數據庫集群服務的啟動腳本https://github.com/Flowman/do...里我們使用了giddyup工具，其中比較重要的命令有以下項：

獲取集群節點成員IP列表，請參照本篇前面章節中my.cnf文件中提及的wsrep_cluster_address=gcomm:// …

獲取集群運行狀態并返回節點規模數

探測當前容器節點是否屬于數據庫集群的bootstrap角色（leader）

3. 配置管理工具confd

https://github.com/kelseyhigh... 它對rancher提供了很好的支持，能夠與Rancher的metadata元數據服務緊密結合：

如何與元數據結合？confd有兩個重要文件，一個是模板文件，一個是配置文件，其執行過程就是從backends對象例如Rancher的metadata獲取數據，然后將其更新至真正被服務調用的配置文件中去：

這里的pxc.cnf.tmpl文件是模板文件，而pxc.toml文件則是配置文件。confd的配置文件是建立一個服務，監控特定的backends對象（例如etcd、rancher元數據等等）的鍵值以及當值發生變化時執行某些操作。其文件格式是TOML，易于使用，其規則跟人的直覺也相近。我們可以看到容器執行期間，Rancher預先在rancher-compose.yml中定義的metadata元數據通過confd將一些重要參數傳遞給了數據庫集群服務的配置文件my.cnf：

我們知道Rancher的metadata元數據是有版本差異的，那么如何知道在這個PXC數據庫集群里它調用的元數據從何而來呢？

看一下Dockerfile的內容我們不難發現
https://github.com/Flowman/do...

這里從mysql元數據服務項返回的值正是我們在rancher-compose.yml文件中預先定義好了的：

從Percona XtraDB Cluster這個Rancher的Catalog項目，我們可以較為全面的理解confd配置服務是如何與Rancher的元數據服務進行結合的，這樣就能實現較為復雜的數據庫集群應用完全自動化的實現彈性伸縮功能。

Q：如果在k8s環境部署mysql集群，用什么方案比較好？

A：Rancher的k8s里面的模板沒有cattle環境的模板多，Cattle的模板是沒有辦法直接拿到K8s環境里面來用的，k8s的模板是k8s的yaml文件結合rancher-compose文件。Rancher官網blog有一篇是關于如何轉換Prometheus的cattle模板成為k8s模板的，有興趣的話可以參考一下：http://rancher.com/converting...