大家好，我是工行數據中心負責MySQL數據庫的顧龔磊。我們工行使用MySQL的時間很短，從2017年纔算真正使用，在我們數據庫專業組之前分爲兩個組，Oracle組和非Oracle組，MySQL在我們行內以前是一個很邊緣化的數據庫，但是隨着業務的演進，包括MySQL架構轉型，MySQL慢慢走上了舞臺中央。
今天我想跟大家分享MySQL本身在工行的實踐經驗，主要跟大家分享四個主題：第一個爲什麼走向分佈式？早上也聽到幾個大佬說分佈式的架構，我們現在用的架構就是他們口中相對比較落後的架構，因爲銀行業比較追求穩定，所以會使用很穩定很成熟的架構。
一、爲什麼走向分佈式
首先說一下大背景，我們行2017年已經提出核心業務需要靈活的平臺，何爲核心業務呢？大家平常接觸到存貸款、信用卡等業務，這些銀行真正核心的交易要求有更靈活的平臺支撐，以及在2018年新增一些業務，比如物聯網、人工智能等一些都必須直接上開放平臺。
這樣的政策調整對我們影響還是非常大，傳統銀行業架構在覈心業務層面是DB2+WAS，在平臺層面是Oracle+WAS，這兩個架構本身在我們行內已經運行快十幾年。它運行本身是非常穩定的，但是在整個背景政策調整的下以及業務規模增長趨勢下，我們發現縱向垂直能力已經無法滿足業務的增長，同時伴隨業務規模增長，開發側已對應出現變化，實現敏捷迭代，而從運維層面對於敏捷交付這塊面臨比較大的挑戰。
行內大多數一些核心的交易7×24小時，業務特點是短平快，對傳統的架構提出了巨大的挑戰。在成本控制方面，由於核心業務涉及商業化的軟件上面需要投入較多License，所以我們整體的成本是無法降低的。
數據庫在IT設施基礎當中是比較核心的，因此在這樣的背景下，我們的數據庫面臨轉型勢在必行。
從業務支撐的角度，我們發現單庫已經無法滿足、支撐這樣的業務增長；從我們運維能力的角度，我們發現傳統基礎環境的供應以及運維模式都已經無法應對開發的這種敏捷迭代了；從風控角度通過打散數據，解耦各個業務層的依賴，降低集中式的風險；從成本角度通過核心業務使用更廉價的硬件基礎設施有效降低成本，自主可控，解決對商業產品的過度依賴。
二、爲什麼選擇MySQL
爲什麼使用MySQL？實際上我們對開源業界的數據庫都做了一些調研，最終我們還是選擇了MySQL，我列舉了以下幾點。
剛剛說到銀行是追求穩定、安全，MySQL實際上在較多互聯網公司有大量的實踐經驗，而且有較多的廠商作爲貢獻者參與到社區當中，整個社區是非常活躍的，Gartner上常年穩居前三；MySQL的版本質量也是相對穩定的。其開源的特性是沒有Licence，也相對自主可控。其輕量化的部署特性以及靈活擴展的能力也比較符合行內業務特點的需求，相較於同爲關係型數據庫DB2和Oralce相對容易上手，業界也有很多的成熟配套方案。綜上結合我們行的一個自主研發爲導向，以及更貼近行內業務特點、版本質量穩定，經過業界多年檢驗的數據庫，所以MySQL就成爲我們的首選。
三、MySQL發展之路
我們行在這兩年對MySQL發展推廣比較堅定，大家可以看一下這張圖。剛剛也提到在2017年的時候，我們MySQL主要用於辦公類非核心類平臺應用，總體規模不超過200個實例，但是隨着2018核心業務的下移，平臺整個MySQL使用量呈現井噴式增長。隨着分佈式架構下MySQL節點數的激增，我們發現機房密度不夠，所以我們在2018年10月開始改造，大家看到2019年5月，我們實際上已有大概600個MySQL在容器部署。
怎樣去管理大規模的MySQL擺在我們面前，因此我們引入了MySQL管理平臺，通過這個平臺可以實現安裝部署、高可用、監控、備份、性能容量的管理，還有引入數據訪問層。
數據庫訪問層實際爲數據庫中間件，我們使用了開源的DBLE，引入DBLE可以簡化開發的工作，提升開發的效率，其本身支持各種水平、垂直數據分片，以及支持跨節點的查詢，我們是通過單園區主備部署保證高可用的，並在雙園區進行雙活部署，解決DBLE本身單點的問題。
DBLE更多解決了開發層面的問題，而我們MySQL管理平臺則面向運維。通過定製研發了MySQL客戶端組件實現了環境自動化部署；性能數據地自動採集；監控實時上送；通過聯動DBLE實現應用無感知地高可用自動化切換以及在非DBLE架構下，能夠自動感知數據庫異常進行自動切換，實現RPO=0,RTO＜60s的業務連續性；並使用MySQL源生同步複製技術保證數據冗餘。
四、MySQL發展過程中的問題及優化
在MySQL的推廣過程中，我們也確實看到了很多問題，我這邊列舉了幾個我們認爲比較經典的問題。
第一，行內傳統架構數據庫存儲一般都使用盤機，我們一些MySQL業務特點是重IO，重IO這些庫，如果都連到一個盤機，很多時候在雙十一電商春節這種活動，這個盤機是扛不住的，會出現IO爭用。
第二，同城RPO，這個異步方式同城RPO肯定是保不住。
第三，服務器資源利用率低，結合目前應用業務一個特點，我們CPU幾乎是躺地板的，基本全年利用率5%，主要吃內存，吃IO，所以這就極大浪費服務器資源。
第四，備份存儲節點的浪費，因爲我們一主兩從架構下會對每個節點去做存儲的劃分，但實際上真正備份只有一個節點，就是同城從庫，這就導致了另外幾個節點存儲完全浪費，而且佔用盤機的資源。
針對這些問題，我們逐一做了一些優化，對於IO爭用問題引入本地SSD，有效提升盤機的性能問題；對於服務器資源利用率低的問題，通過MySQL雲化部署去提升我們服務器資源利用率；對於備份資源浪費通過對接ceph節約成本；對於高可用通過一主三從改造提升同城RPO。
我先說一下高可用架構優化，這就是一主兩從，應用服務器是通過域名方式連接數據庫的，域名是綁定VIP的，通過VIP漂移實現本地切換，大家注意之前的架構是ACK降級，也就是說，這個架構下如果一降級就一定會存在丟數的可能。
因此，我們這邊做了相應的改造，就是新增了一臺同城從庫是半同步，然後把原來的異步從庫改成半同步角色，同時調整了ACK。這樣做得好處是什麼呢？通過不降級能夠保證數據的強一致，爲什麼ack=2？是因爲我們設計成所有從庫，你有多少臺從庫減1，就是它的ack。這樣做得好處是相當於每次數據同步，同城一定有一個庫是拿到的，從這個方式保證了同城RPO。
既然增加了一臺從庫，所以成本一定會增加。所以我們在去年10月份的時候開啓了這個項目MySQL雲化部署，通過MySQL雲化部署，我們真真切切感受到倍率現在4-5的樣子，也就是說通過這樣的部署方式節省了應該有400-500臺物理機。
那我們是怎麼去做的呢？因爲我們行內PaaS平臺已經使用比較穩定了，我們所有應用服務基本都是在雲上的，我們通過Kubernetes + Docker的方式，去對容器進行部署、管理、編排。
那麼我們所對應的基礎鏡像由MySQL的社區版5.7.21，加上os Linux組成基礎鏡像。其中是通過用dockfile的方式來製作MySQL的鏡像，所以我們整體的一個環境供應是標準化的。
整體容器採用富容器方式部署，一個pod一個容器的方式；採用該方式的原因是對遷移入雲的存量應用，以及推廣新增環境入雲的改造幾乎沒有，對生產存量的MySQL侵入性較小。但我們後續也在研究一個pod多個容器的方式，儘可能解耦各組件，輕量化鏡像以及更貼近k8s源生對pod的設計理念。
由於數據庫這個東西必須要解決兩個技術難點，一個是IP固定，爲什麼這麼說？因爲在傳統運維的過程當中，我們DBA一般以IP視角去做運維管理的，但是在行內PaaS平臺上所有應用服務器IP是不固定的，這個問題對我們產生了比較大的阻礙，因此我們通過自研的SR-IOV-cni插件去實現了網絡IP的分配以及固定，容器網絡的建立。
具體怎麼實現呢？這是一臺宿主機上面用兩個物理網卡，然後對接兩個物理網卡做虛擬化，虛擬化出VF，然後對VF虛擬網卡做聚合，也就形成了cbond，cbond目的是爲了虛擬網卡的高可用，同時把cbond以及IP給到容器內部的namespace，這樣容器就有了IP，而且在當容器故障或者重建的時候，由於他的networkclaim是不會丟的，所以IP可以固定以及保留的。
我們用SR-IOV的一個好處，是因爲其性能是最接近物理機，而且時延低，一臺萬兆的可以虛擬出63個VF，也就是說一臺物理機上面可以部署63個容器，當然生產上面不太會部署這麼多數據庫在一臺物理機上，這樣集中風險也比較大。
第二點數據持久化，因爲數據庫要入雲嘛，數據必須得持久化，這是最基本的條件。那我們是怎麼做的呢？我們是通過k8s的volume Hostpath的方式，把Node的文件目映射給pod，從而實現了數據的持久化。
通過自研csi實現了存儲本地盤以及外置盤的存儲自動劃分，以及使數據持久化。具體的實現方式通過csi的controller，在Node節點上掛載卷調用csi agent在Node節點上去劃分文件系統，期間與盤機層面以及IaaS的信息互相交互是通過自己研發的StarMGR腳本實現的。
對於備份優化，這一塊我們引入了S3fs，通過配置S3fs可以對接分佈式存儲，通過映射關係可以將後端bucket直接掛載本地文件目錄，可以直接使用。容器做了兩層映射，對MySQL的備份沒有侵入性。基本上是通過共享目錄的方式給到主從，爲什麼要這麼做？是因爲在一臺主庫進行切換的時候，可能切到備份的庫上。一般我們的腳本不會再主庫進行備份，因此可能需要額外調整劃分存儲資源，這樣就避免了浪費。另外通過集中式的備份能夠大大提升備份管理的效率；以及通過低廉的存儲介質能夠有效降低備份成本；糾結碼技術提升備份技術的高可靠。
在我們的優化過程當中，實際上也看到很多坑。第一，網絡流量，這個在推廣分佈式架構中預想不到的事情，我們在一次版本投產期間，因爲一般情況下每套庫爲了有一臺從庫作爲回退庫或者保障庫，我們會斷開主從。但是由於分佈式架構下MySQL節點數量多，等到版本投完，我們恢復主從，發現同城園區的一個網絡區域應用交易幾乎全部延遲，後面查到原因是什麼呢，我們恢復同城的時候把一個網絡區域的火牆給打趴了，一次性恢復主從，會造成流量的泄洪效應，直接壓垮火牆，導致整個網絡區域其他應用受波及。採用的解決方案是控制同城主從之間恢復的併發度，會有一個隊列實時監控網絡流量。
第二，大事務，大事務實際上會影響主庫的交易連續性以及主從延時，因此我們現在自行開發了一些大事務的監控，並逐漸走向自動Kill，但自動Kill這個事可能對有些應用程序還是影響比較大的，所以我們也在斟酌，同時我們會制定相應的開發指引，楊老師也說到指引本身沒有問題，但是落地很難，所以我們也在考慮引進一些審覈。
第三，大表，大表也是在我們版本投產的時候出現的，之前我們關注可能確實比較少，曾經有一個應用兩億的表，它做了DDL，簡直就是跑死人。所以我們的應對策略是會定期去收集一些大表去促進開發制定數據清理，包括DDL測試的遷移一樣，MySQL的審覈。
這邊是後面的一個具體工作思路：
第一，自動化，由於目前還停留在數據庫自動切換階段，後續目標增加數據庫與網絡、應用層面的聯動，實現業務級別的故障自愈。
第二，服務化，現在我們的架構IaaS和PaaS還是有一定的隔閡，那是通過IaaS供應宿主機，我們把這些宿主機加上PaaS平臺當中作爲資源去管理，後續是打通IaaS和PaaS通過服務的方式去提供數據庫服務供應。
第三，彈性。這是上容器一個很迫切的需求，因爲在有一些業務量突增，我們是非常需要彈性資源的擴縮，我們目前階段還是處於需要停機去做擴縮，當然可以減少停機影響去做主從切換來規避，我們目標也是希望能夠容器層面實現動態在線擴縮。
第四，多租戶。因爲我們行也有SaaS，那SaaS和PaaS之間我們也沒有一定的對接關係，但這是我們後面一個工作方向，進一步研究隔離性更好的虛擬化方案。大家知道docker是共享宿主機內核的，它的隔離是不徹底的，所以這塊也是我們後續的一個工作方向。
以上就是我跟大家交流的一個近兩年我們在MySQL上面的實踐經驗，謝謝大家。
Q & A
Q1：你們的MySQL有1000多個，每個實例大概有多大？佔的空間？數據的存儲？
A：四五百G。
追問：有沒有用MGR？
A：沒有，我們現在有一個團隊在研究MGR這一塊，但是生產還不敢冒用新的技術，不過對於新技術帶來的效益還是我們關心的。
Q2：MySQL和cpeh之間怎麼做到銜接？
A：實際上我們備份文件扔到ceph上，之前提到資源浪費的情況，以及遠程存儲的方式，一個是共享的好處，但是這同樣帶來了一個問題，流量的問題。這個我們也在前端去設計做了流量控制。
追問：S3fs是作爲什麼？
A：做數據轉化，用於做前端數據備份至ceph的中間轉換層。
作者介紹：
顧龔磊，工商銀行開源數據庫運維牽頭人，帶領團隊管理上千個MySQL節點的日常維護。MySQL OCP，參與了開源數據庫選型的研究評測和技術論證，主導了監控體系、高可用設計等運維體系建設完善，在金融行業率先開啓了基於分佈式開源數據庫架構承擔核心交易的實踐，較早啓動了數據庫容器化研究和規模應用，在系統架構、問題診斷、性能優化等領域具有豐富經驗。
本文由 dbaplus 社羣授權轉載。
原文鏈接：