在自動化模式中應用運行MySQL
大小:0.8 MB 人氣: 2017-10-12 需要積分:1
標簽:MySQL(25720)
自動化模式(Autopilot Pattern)是一種設計應用與基礎架構的方式,旨在推動應用系統中的各個組件自動化。組成應用的每個容器都有自己的生命周期,我們將這些生命周期的行為封裝到了應用的容器中,而沒有依賴外部架構。下文將講述我們是如何借助這種模式,部署和運行其中一種常被認為難以在Docker容器中運行的復雜、有狀態的應用:MySQL。
運行MySQL
我們從常見的MySQL部署開始:從主節點到副本節點執行異步復制。客戶端查詢副本節點,或對主節點執行寫入操作。這個架構會引發一些關于服務發現和拓撲結構的問題:
副本節點如何知道在哪兒能找到主節點?主節點如何告知副本節點從哪兒開始執行復制?客戶端如何知道在哪兒找到節點,哪些節點接受寫入操作?
在執行部署后,我們還有一系列疑問:
我們怎樣進行備份?如何主節點出現故障,如何對副本節點進行升級來進行替換?在故障轉移期間,其他的副本節點怎樣知道在哪兒能找到新的主節點?客戶端如何知道我們執行了故障轉移?
當然,其中一些問題已經有了現成的答案。配置管理工具經常會負責應用中架構的配置工作,但如果運行時應用拓撲出現變更,配置管理工具是無法回應的。數據庫即服務(DBaaS)負責執行管理工作,不過如今大多的配置已不再控制范圍內,成本也更為高昂。
對應用來說,還有一個選擇就是執行自動化運行。在這種模式下,要對應用模式執行優化,代表著要讓應用知道如何適應整個系統:啟動、關閉、縮放、發現和恢復。最大限度地減少人為干涉,意味著錯誤更少,有更多的時間花在更重要的業務上。
很明顯我們沒打算重寫MySQL,因此需要找出辦法為現有的應用提供這個功能,而我們選擇了Containerbuddy。
架構
我們需要利用這些組件部署MySQL:
MySQL:我們使用了MySQL5.6(Percona Server),使用XtraBackup運行熱快照備份;
Consul:用來協調復制與故障轉移工作;
Manta:Joyent的對象存儲系統,為存儲MySQL快照備份提供安全經久的服務;
Containerbuddy:包含在我們的MySQL容器中,負責編配bootstrap behavior,通過onStart、health、onChange處理器,調用Consul中存儲的key和checks協調復制的工作。
triton-mysql.py:Containerbuddy在執行MySQL編配的繁重任務時會調用到的小型Python應用。
所有代碼與配置都能在GitHub中找到。
架構圖
當開始新的MySQL節點時,Containerbuddy的onStart處理器會調用triton-mysql.py。Containerbuddy會fork Percona Server并等待,同時運行onStart、health、onChange處理器。結果就是類似這樣在MySQL容器中的進程樹:
root@993acf351cd9:/# ps axo uid,pid,ppid,stime,cmdUID PID PPID STIME CMD root 1019:02/bin/containerbuddy mysql 94119:02|_ mysqld --console --gtid-mode=ON.。.root 107119:04|_ python /bin/triton-mysql.py healthroot 109119:04| |_ /usr/bin/innobackupex --no-timestamp.。.root 120119:06|_ python /bin/triton-mysql.py healthroot 121119:06|_ mysql -u repl -p.。.
自組裝
由于我們只用了幾個Docker鏡像,無需使用單獨的調度器來管理發現與引導服務,簡單地使用下面的命令就可以運行堆棧:
docker-composeup -d
出現的第一個節點會登錄Consul發現服務,嘗試并查找主節點。如果第一個節點發現主節點還不存在,則將自身作為主節點,并初始化數據庫。使用Consul會話通過atomic鎖寫入密碼,這樣就會有一個且僅有一個節點成為主節點。
非常好我支持^.^
(0) 0%
不好我反對
(0) 0%