微盟数据库的涅槃之旅
作者：微盟DBA 余成真
1. 背景介紹
在經歷了慘痛的黑天鵝事件以及激烈的數據恢復過程后，作為微盟DBA的我們進行了深刻的反省和自查，作為公司的核心資產，數據庫也得到了前所未有的重視。如何保證數據安全以及用戶服務的高可用性是我們必須要解決的首要問題。在經過對騰訊數據庫深入分析以及業務調研的的基礎上，我們選擇了騰訊云數據庫。通過借助騰訊云 CDB（TencentDB For MySQL）的數據庫高可用、備份、恢復、審計、安全等體系，來提升微盟數據庫的性能、穩定性與數據安全，滿足業務發展的需求，所以我們逐步放棄自建數據庫服務，遷移到騰訊云數據庫?
在云上迎接重生的微盟，成為微盟DBA團隊核心工作目標。
本文準備就微盟MySQL數據庫遷移CDB，從CDB性能上展開較為深入的分析與討論，通過系統化的測試方案，將黑石限核與CDB各優化狀態的數據進行比對，分析上云CDB后會有什么樣的使用風險？各并發場景下的性能差異，產生差異的原因，解決過程及解決方案進行了詳細的分析。
2. 產品選擇
配置：上海四區16C64G（騰訊云數據庫CDB）
為更貼近生產環境數據庫使用場景，DB團隊以微盟線上數據為樣本，構建基準測試表及數據進行基準壓測；收集線上27套實例的業務SQL進行業務壓測。
測試方案：
對照組：黑石不限CPU(56核)32G——QPS值、黑石限16核32G——QPS值
CDB環境：原生CDB | CPU優化 | 網絡參數優化 | MySQL參數優化
基準壓測：在16|32|64|100|200|400并發情況下各環境QPS性能數據。
業務壓測：在16|32|64|100|200|400并發情況下各環境QPS性能數據。
結論：基于線上QPS性能數據，按照(16C64G)CDB產品介紹及壓測數據報表，得出優化后CDB能滿足公司數據庫需求。
3. 方案驗證
3.1 壓測方法
主要用MySQL官方的壓測工具mysqlslap進行壓測。例如:
mysqlslap --iterations=100 --create-schema='test' --query="query.sql" --number-of-queries=20000 --delimiter=";" --concurrency=100表示100并發下運行20000次query.sql, 迭代100次后,輸出相關信息如下
Average number of seconds to run all queries: 0.198 seconds Minimum number of seconds to run all queries: 0.198 seconds Maximum number of seconds to run all queries: 0.199 seconds Number of clients running queries: 100 Average number of queries per client: 200其中平均時間為迭代100次算出的平均時間。QPS = 20000次/平均時間
3.1.1 壓測時間線
4月8日發現性能問題1---->4月9日微盟騰訊成立專項組分析并驗證問題---->4月10日21時確認問題原因，進行第一版優化---->4月13日抽檢29套CDB實例并應用第一排優化配置---->4月14日基準+業務壓測---->4月14日23時全面分析生成壓測報告發現性能問題2---->4月23日第二版優化---->4月24日第三版優化---->4月25日30個實例DTS遷移任務---->4月26日發現性能問題3---->4月26日第四版優化，CDB上云---->建立長期基準壓測任務
3.1.2 主要優化思路
相對于黑石自建的 MySQL 實例，云上的環境較為復雜，這些復雜之處主要包括網絡延遲?、虛擬機環境、操作系統版本環境、資源隔離策略、騰訊數據庫 CDB （TencentDB for MySQL）內核的穩定性與可靠性、CDB 備份與恢復等，整個上云過程在騰訊云團隊的全力配合下，也做到了有驚無險，結果超出預期，排查問題的方法與工具主要包括以下幾點：
模擬短連接的mysqlslap &?長鏈接的sysbench，以及業務定制化的lua腳本，借助sysbench模擬長鏈接下業務持續壓力下數據庫性能?&?穩定性表現；
環境對比：主要包括黑石自建環境的對比以及 CDB 實例所在機器的操作系統參數對比，主要包括 NUMA、網絡參數設置等
MySQL 參數對比：用于還原自建性能并發現問題
perf 工具：用于分析特殊 SQL 語句在 MySQL 內部的資源消耗情況
pt-pmp 工具：用于排查大并發環境下的性能瓶頸，提升實例性能
騰訊云?CDB?團隊內核層的源碼分析與修改（騰訊內核大神青林, 阿遠）
數據庫性能秒級監控工具（orzdba）：用于在穩定性壓測過程中觀察是否存在抖動
3.2 壓測中遇到的問題
我們在騰訊CDB和微盟自建的環境下，用相同的方法進行壓測對比。在壓測過程中主要遇到了如下問題：
3.2.1 NUMA 綁核問題
問題描述
我們在 CDB 環境下進行業務壓測的時候，遇到了一個詭異的問題，所有壓測語句中有一個 select count(*) ... 的語句執行有性能方面的異常，具體表現是我們黑石自建數據庫的性能要比 CDB 環境下的數據庫性能高4倍以上，其他語句大都正常，部分的業務 SQL 語句在 CDB 的表現要優于我們在黑石自建的數據庫性能；我們在使用 mysqlslap 或者 sysbench 模擬壓測時都可以把問題進行重現，基于問題的表現，一時有點懵逼的感覺……
排查過程
首先騰訊云CDB團隊從MySQL上查找原因，我們配合他們對MySQL版本是否一致、不同版本的語句執行計劃是否一致、MySQL相關參數如 optimizer_switch 等是否一致、并根據他們的要求提供了perf 產生的data信息用于定位不同階段的CPU消耗，用以定位問題的原因，但當這些因素被一一排除后，他們得出的結論是排除CDB內核的原因，并將突破口放到了網絡環境和主機硬件的差異；
其次，壓測環境客戶端是跑在騰訊的CVM上的，為此他們將壓測程序部署在CDB所在主機上，進行本地壓測，結果同樣出現性能下降的問題，因此排除了網絡環境因素的猜疑；
接下來我們對比主機的CPU等硬件配置也沒有差異。另外CDB主機開啟了NUMA，為了排除NUMA的影響我們建議他們關閉 NUMA 進行測試，但效果依然不好。
CDB 的CPU是通過cgroup進行資源隔離的，在放開了cgroup的限制后壓測性能仍然不好。這個時候，我們發現我們自建的 MySQL實例的 ?CPU資源隔離是通過綁核的方式進行的，和CDB的CPU的隔離策略并不一致。騰訊云CDB的資源隔離是通過cgroup控制CPU時間分片進行實現的，這樣有可能導致工作的CPU會分配到不同的Node上，造成跨Node 的CPU訪問內存的現象，進而導致性能降低。
將CDB的CPU隔離策略修改和自建一致后，CDB 實例性能比微盟自建要好。同時我們也將自建壓測主機放開CPU隔離限制即整機資源不做隔離，發現比綁核限制的性能要差，這也證明了綁核的影響。
問題原因
性能差異主要是由于騰訊云CDB cgroup隔離策略和微盟cgroup隔離策略不一致造成的，業務進程可用核數變多，實際的并發度增大提升了鎖開銷。鎖競爭的增大消耗了更多的cpu時間，相同quota配置下，用于處理實際業務邏輯的cpu時間變短進而降低了QPS。其次，業務綁核不是很合理導致遠端內存訪問較多，由于外部總線(QPI總線)比內部總線性能差，跨numa內存訪問降低了QPS。
解決方案
調整cpu quota設置，修改測試CDB機器CPU隔離策略，按核進行綁定，并將核綁定到同一個Node上。對于消耗大量內存的內存數據庫可以嘗試使用interleave內存分配策略。
方案效果
CDB性能10倍提升，滿足微盟需求，性能調優后的 CDB 實例要優于微盟自建實例?
3.2.2 網絡參數問題
問題描述
使用 mysqlslap 壓測某個語句，當并發數提升到200或400時，CDB性能下降，不符合業務預期排查過程
這里只和高并發有關，CDB團隊首先想到的是MySQL是否開啟了thread pool功能，對于CDB和自建均未開啟thread pool功能，而在CDB上打開了thread pool功能后問題仍然存在。而且在本地和遠程壓測都存在同樣問題，這也排除了網絡的因素。
有一個細節是CDB團隊觀察到壓測過程中數據庫的連接數并不穩定，忽上忽下，就開始懷疑是mysqlslap壓測工具的問題。于是CDB團隊開始查看mysqlslap源碼, 確認mysqlslap用的是否是短連接。然而mysqlslap用的是長連接，并不是短連接。但有一種情況，當mysqlslap執行完一輪（number_of_querys）語句后會新建連接。當壓測參數iterations設置較大，number_of_querys較小，并且調大并發數時，每個連接執行的語句相對就少了。也就是說，當并發數增大時，壓測過程中的新建連接增加了。為了驗證這個問題， CDB團隊調大壓測參數number_of_querys后，壓測性能就上去了。
到這里，問題可以歸結為大量建立連接影響了性能。于是CDB團隊開始查找TCP相關系統參數的區別，通過修改主機參數tcp_rmem/tcp_wmem/tcp_max_syn_backlog/somaxconn，解決了高并發下的性能下降問題。
問題原因
mysqlslap的實現方式是每次迭代都后重新建立連接，即所有客戶端執行完number_of_queries數量的SQL后會重新建連連接，當并發增加時，每個客戶端執行的sql相對較少，mysqlslap這種長連接測試方式退化類似于短連接的測試方式，而CDB主機對短連接處理的不是特別好。解決方案
方案效果
通過優化騰訊云CDB主機參數tcp_rmem/tcp_wmem/tcp_max_syn_backlog/somaxconn，解決了通過短連高并發下的性能下降問題。
3.2.3 低并發性能問題
問題描述
騰訊云CDB低并下發性能問題不如自建環境， 但在高并發下性能沒有差異。
排查過程
首先CDB團隊在本地進行了測試發現并沒有出現低并發下性能下降的問題，因此基本確定是網絡問題引起的。同時CDB團隊也用最簡單的sql語句"select 1;"進行了測試也驗證了是網絡的問題。于是開始對比CDB和自建的網絡環境差異，發現CDB的網絡架構需要三跳才能到后端DB節點(RS)，CVM->VPCGW->TGW->RS，相比自建環境要復雜。于是CDB團隊手動去掉TGW這一層后，再進行測試發現性能可以上去。從而確定了是CDB網絡架構多了一層導致的。
問題原因
CDB的網絡架構需要三跳才能到后端DB節點，CVM->VPCGW->TGW->CDB，因此網絡鏈路上耗時會增加，尤其從CVM和CDB各層節點網絡親和性不好的情況下，低并發的性能差距比較明顯。而高并發下，單個query的RT對吞吐量影響不大，CDB的性能就滿足需要，于是順便和 CDB 團隊了解了一下這個名叫TGW的東東，我們從三個方面解析一下TGW：
1.?為什么要使用TGW??
通俗的講，TGW就是DBProxy。和其他云數據庫服務一樣，CDB也通過加入一層代理來對外屏蔽物理機器，既能帶來訪問上的安全，又能提供一個統一的訪問入口，避免物理DB IP和Port的變化給應用帶來的影響。?只不過，TGW是一個操作系統內核態的proxy，在穩定性和性能上相比會更好些，當然這里開發TGW在技術上也是一個挑戰。
2. 使用 TGW 存在什么問題？
目前，用戶在騰訊云一般是通過CVM+CDB的方式來使用CDB實例。用戶一般會先構建一個VPC網絡，把購買的CVM放置在某個VPC網絡。CDB實例是在特定的underlay網絡。打通這兩個網絡依賴一個VPCGW，這樣一個query的訪問路徑就是CVM->VPCGW->TGW->CDB。對于用戶使用而言，多一層網關，會直接導致單次tcp交互時延增加。
3. 如何解決 TGW 的問題？
網絡時延的增加在小并發下會引起吞吐量的問題，為了提升用戶體驗，騰訊CDB團隊目前在做一系列的優化，其中的一項工作就是支持移除對TGW的依賴，用戶的一條query訪問路徑從CVM->VPCGW->TGW->CDB縮短為CVM->VPCGW->CDB。減少訪問鏈路中網關的個數，進而減少訪問CDB實例的時延問題。
解決方案
騰訊云計劃年內去掉TGW，到時我們再測試一下
方案效果
目前性能滿足需求
3.2.4 范圍查詢場景下性能下降
問題描述
騰訊云CDB在范圍查詢場景下性能下降。
排查過程
這個問題比較詭異，排查過程也比較艱辛。
首先CDB團隊也是從MySQL版本、參數、查詢計劃等基本因素上查看差異，并沒有任何收獲。騰訊云CDB內核在MySQL原生基礎上做了大量的改進和優化，為了排除CDB內核的影響。出現問題的實例是MySQL 5.6的實例，CDB團隊用和我們微盟一致的官方MySQL版本在CDB所在主機上進行測試，發現官方MySQL版本并沒有問題。
到這里可以基本確定是CDB 5.6內核引入的問題。然而CDB 5.6在MySQL原生基礎上有數百個修改提交， 排查起來并不簡單。首先CDB團對從可能有影響的幾個查詢優化的修改提交上排查，然而并沒有收獲。于是CDB團隊開始二分查找的方式進行定位是哪個提交的影響。經過數次的二分編譯版本壓測驗證，最終定位到CDB5.6一個提交，這個提交是引入官方MySQL5.7對只讀事務的優化，詳見WL#6047W。這個提交約有2000行代碼。關鍵是這個優化表面上看對這的問題場景并沒有影響，反而此優化后性能應該提升才對。而且CDB團隊也測試過此優化對sysbench只讀場景性能確實有提升。經過仔細review這2000行代碼后也沒有發現異常。
于是，CDB團隊由開始了一個宏大的代碼定位過程，通過在沒有問題的代碼上做加法來縮小影響的代碼行數，從最初的2000行，到1000行，到800行，到360行，最后到180行。這180行沒法再拆分，然后只有一行一行分析這180行代碼，表面上看整體邏輯和這180行也沒有關系。但是，這180行中有一行邏輯會修改只讀事務id為0，之前只讀事務和讀寫事務一樣都是自己的id。但這個修改會影響其他部分代碼關于innodb_rows_read的計算效率，官方后續修復了這個問題，具體可以參考官方修復代碼。但CDB5.6沒有及時發現跟進修復這個問題。
在CDB5.6內核上修復此bug后，經過壓測驗證性能比自建更好。
問題原因
官方MySQL原先innodb_rows_read統計計數有個優化是通過trx_id的遞增性來打散優化計數。騰訊云CDB-5.6內核版本優化了只讀事務，修改只讀事務id為 0 后沒有跟進官方后續的 BugFix，導致只讀事務統計計數性能變低。
解決方案
這里補充一下，此問題僅在CDB5.6老版本中存在，CDB其他版本沒有此問題。同時CDB5.6可以通過升級新版本解決。
方案效果
新版本優化后，騰訊云CDB5.6性能明顯比自建更好。
3.2.5 整體性能100并發下QPS略低問題
問題描述
騰訊云CDB在100并發下大部份CDB QPS普遍略低于自建問題。排查過程
在優化兩版后，CDB性能已提升幾倍，但相較于自建仍有大部份低于自建QPS值，此時CPU綁定、系統層面、CDB內核層面已找不到問題點，MySQL參數成為首要關注目標，比對自建與黑石variables的配置差異，發現不少不同點：innodb_io_capacity_max、innodb_write_io_threads、innodb_open_files、open_files_limit、table_open_cache、table_open_cache_instances等。
問題原因
數據庫相關參數應該由業務根據數據庫運行情況來進行相應的修改，不同業務場景下數據庫性能有著不同的表現，參數不能一概而論，如刷臟，表緩存個數、異步讀寫線程個數、redo log 文件大小等在不同場景下都需要不同的配置，所以需要對 CDB 的默認參數進行相應的修改，以提升數據庫性能，不能著了CDB的道~ （聽說他們有個工具叫 CDBTune，還發過 Sigmod，就是為了幫助業務調優數據庫性能的東西，期待一下下~）
解決方案
按以上最優化參數配置應用到實例。
方案效果
目前總體性能提升明顯，且趨于穩定，部份實例超過自建QPS值。
4. 上云過程
4.1 配置CDB
按QPS：根據業務歷史性能數據，將不同業務數據庫實例配置不同規格CDB
按業務核心度：篩選近30套核心實例，按16C64G標配CDB
4.2 制定遷移計劃
按業務類型與各研發負責人逐實例進行遷移時間確認：
是否需壓測、CDB配置特殊要求、遷移時間、遷移負責人
4.3 實施遷移
建立DTS遷移任務（提前2日）。
遷移實例在線列表、業務相關負責人、測試方案。
數據一致性檢查（三方確認：DTS任務全量校驗、TOP30大表的行數校驗、業務核心表數據校驗）。
切換CDB（自建DB實例只讀、域名切換CDB、DTS停止同步、kill自建源DB數據庫連接進程、檢查自建DB與騰訊云CDB數據庫連接情況、有DNS緩存服務重啟）。
測試、完成。
5. 最終效果
5.1 性能數據
受限于多種外界因素干擾，本報告以100并發為觀察點，結合各優化階段性QPS值，大部份波動小于25%以內 基準壓測報告業務壓測報告（100并發）CDB比黑石差（5%）：CDB比黑石強（95%）
5.2 提升效果
相較原生CDB，基準壓測數據方面 QPS提高4-10倍；業務壓測部份場景SQL提升2倍以上，總體性能數據提升非常明顯。
6. 寫在上云后（上云的注意事項）
一定要對現有業務的QPS進行評估，選購合適規格的CDB。
最好進行壓測：CDB與在用數據庫壓測后進行性能對比，明確QPS差異是否在預期之內。
CDB版本與參數做到與在用數據庫一致。
使用在線文檔讓所有相關研發信息共享，及時溝通、及時匯報遷移進度。
遷移前確認CDB賬號及權限，DBA自己做一次數據一致性校驗。
遷移工作盡量工具化，降低操作時間，減少服務受損時間。
遷移DTS完成后，一定要對實例表進行analyze table，防止系統統計表數據丟失引起的系統下降。
測試必不可少，遷移后觀察各日志報錯信息，做到問題早發現。
總結
以上是生活随笔為你收集整理的微盟数据库的涅槃之旅的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 2 周流量激增百倍的腾讯课堂后台扩容和性
- 下一篇： 腾讯会议核心数据库TDSQL，如何做到快