MySQL-Operator容器化方案概述_第1頁
MySQL-Operator容器化方案概述_第2頁
MySQL-Operator容器化方案概述_第3頁
MySQL-Operator容器化方案概述_第4頁
MySQL-Operator容器化方案概述_第5頁
已閱讀5頁,還剩1頁未讀 繼續免費閱讀

下載本文檔

版權說明:本文檔由用戶提供并上傳,收益歸屬內容提供方,若內容存在侵權,請進行舉報或認領

文檔簡介

MySQLOperator容器化方案概述

【導讀】與內存庫的Redis數據庫比起來,容器化MySQL有著更多的需求,本文介紹了MySQLOpreator容器化方案及設計思路。以前文章分享過RedisOperator容器化方案(點擊標題可閱讀:《RedisSentinelOperator容器化解讀》,《RedisClusterOperator容器化方案》),本次介紹MySQLOperator容器化方案。與內存庫的Redis數據庫比起來,容器化MySQL有著更多的需求,主要有以下三個方面:MySQL對存儲的要求很高MySQLPod的IP需要固定MySQL需要支持同城災備MySQL容器化拓撲結構固定MySQLPodIP可以在K8S上使用Calico網絡插件實現。存儲方面使用高性能分布式存儲或者直接掛載本地盤都可達到要求,這些不在本文做重點介紹。MySQL容器化有同城災備需求。對于MySQL部分,我們使用MySQLMGR單主模式,將MGR節點分散在本地/同城運行,正常情況下主節點運行在本地,災備切換時將主節點切換至同城。對于K8S集群部分,我行K8S集群沒有進行跨本地/同城部署,所以MySQLMGR節點會分布在兩個K8S集群運行。對于MySQL服務暴露部分,在每個K8S集群上為每個MGR集群各建立Read、WriteService,通過K8SService機制對外暴露MySQL服務。整體拓撲結構如下所示:MySQLOperator功能邏輯MySQLOperator的功能包括MGR集群創建、集群維護、CPU內存資源升級、MGR節點擴縮容、節點遷移等。由于MGR集群跨K8S部署,所以在Operator的邏輯上不能只管控本地資源,還需關注在同城運行的那一部分MGR節點的情況。MGR集群創建在MySQLMGR集群CR資源定義中包含以下三個字段:flag字段為primary標識MGR的主應該在本地ipList定義部署在本地K8S集群的MGRPod列表,以及具體的PodIP和所在K8S節點remoteList定義部署在同城K8S集群的MGRPod列表;本地Operator會通過該字段中的IP地址嘗試連接同城MGR節點,以判斷同城MGR節點是否連通以及角色是否正常spec:

flag:

"primary"

ipList:

-

ip:

""

nodeName:

"abc"

remoteList:

-

ip:

""

nodeName:

"abc"在MGR集群創建流程中,兩邊Operator均需確定ipList和remoteList中的PodIP地址均可連通,確定MGR集群所屬的Pod均已啟動后才能執行MGR集群的創建工作。創建的時候,flag為primary側的Operator會在本K8S集群中選出一個MGRPod進行主節點的引導啟動,其余本地Pod和flag為standby側集群的Pod均啟動為從節點。MGR集群維護集群維護功能是為了保證MGR集群按照預期運行,集成了各種異常場景下處理邏輯,主要包括以下幾個部分:保證Service、PVC、Configmap等需要的K8S資源按照預期創建保證MySQLPod數量和運行狀態正常保證MySQLPod的角色標簽和實際的MGR角色一致維持Pod內的MySQLMGR進程啟動判斷MGR主節點是否切換,并進行切主后操作等除了Operator的集群維護功能,另一個保證服務持續可用的是MySQL自身的MGR機制。在整體設計中,我們對Operator和MGR兩種機制管控范圍的做了清晰的邊界劃分:即Operator只保證MGR運行所需的環境正常,如節點數、進程啟動狀態、配置等正常,但涉及到主節點切換等MGR機制內部的事情,Operator只做觀察并把最新狀態反映到CR的Status字段中而不去做干預。在Operator的設計中,只有三種情況會進行主節點干預:一是集群新建的情況;二是在確認所有集群節點都為從節點的情況,選出gtid最大的節點啟動為主;三是收到災備切換的請求,會將主切到flag=primary的一側。MGR集群運維操作Operator支持對MGR集群進行一些常規的運維操作,包括本地/同城節點的上線、下線,Pod內存、CPU資源的擴縮容、Pod使用鏡像的更換以及MySQL的配置文件更新等。Operator最重要的任務是維持集群正常運行,對于這些運維操作在設計時采用了一個穩妥的方案:所有的運維操作必須基于維護流程判斷集群狀態正常(有且僅有一個主節點,其余節點均運行正常且為從節點)的情況下才可進行在狀態轉換流程中設置操作的優先級,先進行優先級高的操作,如新加節點的優先級高于刪除節點的優先級如果涉及到類似于多個節點添加的批量操作,Operator會將批量操作拆分為單個操作的順序執行,每步操作完成后確認集群狀態正常才能繼續下一步操作整體流程如下圖所示:MGR集群災備切換災備切換包含兩部分:第一部分是MGR集群的主節點切換到同城集群;第二部分是客戶端網絡流量打到同城集群。對于第二部分的實現有手動改客戶端訪問地址、更改DNS指向、使用代理轉發等多種方法,本文不做討論。對于第一部分,Operator做了一個便捷化的實現,在檢測到flag字段由standy變為primary的時候會主動發起一次切主操作,試圖將主切換到現在的primary這邊。要

溫馨提示

  • 1. 本站所有資源如無特殊說明,都需要本地電腦安裝OFFICE2007和PDF閱讀器。圖紙軟件為CAD,CAXA,PROE,UG,SolidWorks等.壓縮文件請下載最新的WinRAR軟件解壓。
  • 2. 本站的文檔不包含任何第三方提供的附件圖紙等,如果需要附件,請聯系上傳者。文件的所有權益歸上傳用戶所有。
  • 3. 本站RAR壓縮包中若帶圖紙,網頁內容里面會有圖紙預覽,若沒有圖紙預覽就沒有圖紙。
  • 4. 未經權益所有人同意不得將文件中的內容挪作商業或盈利用途。
  • 5. 人人文庫網僅提供信息存儲空間,僅對用戶上傳內容的表現方式做保護處理,對用戶上傳分享的文檔內容本身不做任何修改或編輯,并不能對任何下載內容負責。
  • 6. 下載文件中如有侵權或不適當內容,請與我們聯系,我們立即糾正。
  • 7. 本站不保證下載資源的準確性、安全性和完整性, 同時也不承擔用戶因使用這些下載資源對自己和他人造成任何形式的傷害或損失。

評論

0/150

提交評論