點擊上方“朱小廝的博客”，選擇“設為星標”

后臺回復”加群“加入公眾號專屬技術群

本文轉自：DBAPlus社群。作者：顧龔磊，工商銀行開源數據庫運維牽頭人，帶領團隊管理上千個MySQL節點的日常維護。本文根據顧龔磊老師在〖2019 DAMS中國數據智能管理峰會〗現場演講內容整理而成。

正文

今天我想跟大家分享MySQL本身在工行的實踐經驗，主要跟大家分享四個主題：第一個為什么走向分布式？早上也聽到幾個大佬說分布式的架構，我們現在用的架構就是他們口中相對比較落后的架構，因為銀行業比較追求穩定，所以會使用很穩定很成熟的架構。

一、為什么走向分布式

首先說一下大背景，我們行2017年已經提出核心業務需要靈活的平臺，何為核心業務呢？大家平常接觸到存貸款、信用卡等業務，這些銀行真正核心的交易要求有更靈活的平臺支撐，以及在2018年新增一些業務，比如物聯網、人工智能等一些都必須直接上開放平臺。

這樣的政策調整對我們影響還是非常大，傳統銀行業架構在核心業務層面是DB2+WAS，在平臺層面是Oracle+WAS，這兩個架構本身在我們行內已經運行快十幾年。它運行本身是非常穩定的，但是在整個背景政策調整的下以及業務規模增長趨勢下，我們發現縱向垂直能力已經無法滿足業務的增長，同時伴隨業務規模增長，開發側已對應出現變化，實現敏捷迭代，而從運維層面對于敏捷交付這塊面臨比較大的挑戰。

行內大多數一些核心的交易7×24小時，業務特點是短平快，對傳統的架構提出了巨大的挑戰。在成本控制方面，由于核心業務涉及商業化的軟件上面需要投入較多License，所以我們整體的成本是無法降低的。

數據庫在IT設施基礎當中是比較核心的，因此在這樣的背景下，我們的數據庫面臨轉型勢在必行。

從業務支撐的角度，我們發現單庫已經無法滿足、支撐這樣的業務增長；從我們運維能力的角度，我們發現傳統基礎環境的供應以及運維模式都已經無法應對開發的這種敏捷迭代了；從風控角度通過打散數據，解耦各個業務層的依賴，降低集中式的風險；從成本角度通過核心業務使用更廉價的硬件基礎設施有效降低成本，自主可控，解決對商業產品的過度依賴。

二、為什么選擇MySQL

為什么使用MySQL？實際上我們對開源業界的數據庫都做了一些調研，最終我們還是選擇了MySQL，我列舉了以下幾點。

剛剛說到銀行是追求穩定、安全，MySQL實際上在較多互聯網公司有大量的實踐經驗，而且有較多的廠商作為貢獻者參與到社區當中，整個社區是非?；钴S的，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的中間轉換層。

想知道更多？掃描下面的二維碼關注我

【精彩推薦】

• redis面試連環問，快看看你能走到哪一步？

• 如何設計出騷氣的秒殺系統？

• 滴滴為啥值3600億，看看它的數據中臺就知道了

• 這次終于不再為iptables范迷糊

朕已閱?

總結

以上是生活随笔為你收集整理的干货 | 工行分布式数据库选型与大规模容器化实践的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。