私有云中的 Kubernetes MySQL 集群
我對由 1 個主節點和 2 個輔助節點組成的 MySQL 集群感興趣。
通常在公共雲中，我們
- 使用外部儲存
- 使用 RDS 等服務，以便在該服務之後處理複製和故障轉移
- 您可以在不同的節點上重新創建失敗的 pod，因為儲存和數據庫未在您的任何 k8s 節點上執行
適用於私有云但不適用於 Kubernetes 的解決方案：
- 通過使用本地儲存
- 通過使用 mysqlfailover 實用程序，它可以指定一個新的主節點
- 通過更改“mysql-0”（主）的 DNS 記錄並指示應用程序刷新 DNS，以便它可以在故障轉移事件中看到新的主
探索 Kubernetes 解決方案：
- 哪一個使用本地儲存或 NFS？（如果是 NFS，你將如何在不同伺服器之間建立集群？）
- 通過使用https://github.com/oracle/mysql-operator、Percona、類似的解決方案甚至是相同的 mysqlfailover - 您更喜歡哪一個以及它如何處理故障轉移情況？最好是開源選項。
如果我嘗試合併目前工作的 mysqlfailover 解決方案並遷移到 Kubernetes，我可能需要設置 Node Affinity，以便 pod 正確連接其本地儲存。
這個mysqlfailover機制也應該改進（起點在這裡https://medium.com/@zzdjk6/step-by-step-setup-gtid-based-mysql-replica-and-automatic-failover-with-mysqlfailover-using -docker-489489d2922）因為它可以例如指定一個新的主mysql-1，而原來的（mysql-0）已關閉。根據我的理解，這可能不是最佳選擇，因為在通常的架構中，我們總是希望 mysql-0 作為 StatefulSet 中的主節點，而 mysqlfailover 則完全相反。
那麼，如果不解決現有問題，您會選擇哪個選項？你會採取哪些步驟？你會使用哪些 MySQL 和 Kubernetes 組件？
非常感謝
我最終得到的解決方案是 Kubernetes 上的 Percona XtraDB Cluster。它有一個 Kubernetes 操作員來自動管理故障轉移場景。
你的應用程序不應該知道任何關於集群的事情，因為它在
kubernetes-service-hostname:3306. 所以應用程序呼叫這個地址，在它後面有 3 個 SQLProxy/HAProxy 容器（每個伺服器）。然後查詢被路由到三個 MySQL 容器之一。當伺服器關閉時，失敗的 SQLProxy/HAProxy 和 MySQL 容器將從 Kubernetes 中刪除，因此
kubernetes-service-hostname包含兩個而不是三個成員。當伺服器重新上線時，將創建容器以再次擁有完整的集群。
還有 Percona 操作員容器，它可以自動幫助管理 pod 並執行其他操作，以便集群完全執行。
在儲存方面，它可以只是
hostPath本地目錄，從儲存角度來看，它顯示出簡單的跡象。您還可以使用PersistentVolumeClaim它背後的任何類型的儲存類或外部儲存，例如 NFS。它實際上是多主機設置。
更多細節：
https://www.percona.com/doc/kubernetes-operator-for-pxc/kubernetes.html