攜程 MySQL 遷移 OceanBase 最佳實踐_臺楓.pdf

《攜程 MySQL 遷移 OceanBase 最佳實踐_臺楓.pdf》由會員分享，可在線閱讀，更多相關《攜程 MySQL 遷移 OceanBase 最佳實踐_臺楓.pdf（30頁珍藏版）》請在三個皮匠報告上搜索。

1、攜程MySQL遷移OceanBase最佳實踐業務場景攜程數據庫的變遷過程SQLServerMySQLNewSQL現狀 少量留存的SQLServer 大部分核心業務部署在MySQL上 部分MySQL實例遷移到了NewSQL數據庫業務場景MySQL存在的問題和瓶頸1、業務數據模型呈現多元化，OLTP 和 OLAP 出現融合的趨勢2、業務數據量增長迅速，容量成本顯著提升3、傳統分庫分表方案對開發不友好，核心庫改造成本高4、MHA模式因網絡原因切換容易腦裂業務場景OceanBase的優勢/劣勢優勢 分布式協議可以防止腦裂 集群可擴展性強，性能上限高，擴容簡單 底層存儲壓縮率高，大大降低存儲成本劣勢 分

2、布式架構導致一般場景下性能略弱于單機數據庫 分布式架構對運維排障要求更高業務需求MySQL如何平滑地遷移到OceanBase？如何提前預知業務對OceanBase的兼容性？如何判斷OceanBase可以支持業務的流量？如何保證遷移前后能夠提供相近的運維支持？如何讓業務在切換期間盡可能透明？如何支持業務的其他配套設施？（包括發布、閃回、canal等）業務切換后是否有足夠的收益？遷移方案評估流程 評估項標準應用中間件版本檢查非標應用、非標賬號檢查分區方案評估推薦業務SQL兼容性和性能評估01020304遷移方案評估流程 構建評估環境My SQLPer formance_schema剔除掉無用SQL

3、或者非遷移對象相關的SQL生成兼容性校驗SQLSQL池Druid解析SQL根據SQL的digest生成SQL執行次數占比根據執行量生成性能測試的SQL池遷移方案評估流程 評估改進案例在近期的一次日志庫遷移評估中，我們通過優化掉業務在MySQL側使用的range分區，在壓測前端壓力不變的情況下大幅提高業務遷移到OceanBase后的吞吐。保留range分區 10000QPS去掉range分區 50000QPS遷移方案評估流程 慢SQL優化案例遷移方案遷移流程 遷移前配置校驗 MySQL賬號兼容OceanBase帶租戶賬號創建 數據遷移和一致性校驗 DDL表結構發布修改暫停 反向同步鏈路搭建遷移方

4、案遷移流程 數據遷移結構圖任務開始表結構校驗流程終止進入回退流程數據同步延遲校驗禁用My SQL側應用賬號或者Revoke權限Kill掉殘留鏈接數據同步延遲校驗刪除My SQL到OB的同步鏈路驗證OB端應用賬號鏈接情況DAL連接串切換停止My SQL到OB的同步鏈路，開啟反向鏈路否否否否遷移遇到的問題和解決方案兼容不適配應用的兼容1、.Net應用訪問OceanBase失敗2、Druid應用不兼容部分OB語法解析遷移遇到的問題和解決方案讀寫分離方案優化設計APPobproxyobproxyobproxyobproxy集群流量weak_read_user_list=testerproxy_idc_

5、name=idc2observer1t1(p1)leadert1(p2)followerobserver2t1(p1)followert1(p2)followerobserver3t1(p1)followert1(p2)leadertester 讀寫寫tester 讀zone1 idc1zone2 idc2zone3 idc3遷移現狀哪些類型的DB我們已經遷移到OceanBase？1、歸檔庫從MySQL搬遷到OceanBase4、少量訂單/產品/核心業務庫2、部分線上核心日志庫3、部分非核心業務遷移收益OceanBase遷移后的部分收益酒店日志系列shard集群遷移至OB后從12臺機器壓縮到3

6、臺機器，成本降低約75%；01歸檔庫從MySQL遷移到OceanBase后，壓縮比超過1:4，空間成本大幅降低；02火車票部分核心業務通過租戶級別隔離，將多個MySQL集群以租戶為單位合并成一個OceanBase集群，大幅提高資源利用率。03遷移案例多Shard合并到一個OB集群 以酒店日志shard合并為例酒店日志shard系列設計初衷：日志數量多容量大，業務上需要較長的保留時間，因此需要更多的機器；訂單操作日志，有部分OLTP類需求，無法完全挪到OLAP類數據庫上；日志庫壓力、日志寫入量和請求量會隨著訂單量的波動而波動。010203遷移案例多Shard合并到一個OB集群 以酒店日志shar

7、d合并為例容量評估壓縮比1：4SQL評估單Zone綜合QPS 50000+表結構調整去除range分區OMS遷移遷移時長 一周Canal反向增量同步延遲 2s遷移案例歸檔庫遷移OceanBaseMySQL作為歸檔庫存在的問題：1.innodb引擎壓縮比低，成本偏高；2.myrocks穩定性不夠，經常需要人工介入處理；3.無法擴展，同一個db的歸檔數據可能因為容量原因散落在多組集群上。遷移案例歸檔庫遷移OceanBase歸檔庫遷移方案 新增的歸檔直接配置目的端到OB上；存量的歸檔數據一次性全量遷移到OB上；持續歸檔且業務需求查詢的數據通過全量+增量的方式遷移到OB。遷移案例歸檔庫架構集群：cls

8、01Zone:ZONE1Proxy-機房110.10.10.1F物理機Zone:ZONE2Proxy-機房210.20.10.2F物理機Zone:ZONE310.30.10.3L虛擬運維建設監控模塊與智能分析 構建監控大盤運維建設監控模塊與智能分析 SQL審計MySQL OceanBaseTiDB網卡Trace FilesMySQL協議解析Client運維建設監控模塊與智能分析 SQL審計應用在使用MySQL command-line tool連接OceanBase報錯利用審計日志定位到客戶端連接OB過程中有查詢元數據操作，在進行到show tables時候報錯斷連，進一步排查到有一個表名結尾

9、帶分號的特殊表（t_sample;）觸發異常報錯。運維建設監控模塊與智能分析 構建性能數倉收集開始數值收集文本收集數值時序差值化插入Kafka存入ClickHouse收集結束運維建設監控模塊與智能分析 自動化分析流程檢測開始CPU.ThreadsRunning,QPS,網卡流量，磁盤否吐量。實時檢測檢測是否異常分析結束自動生成分析報告獲取異常前后收集的文本數據確定故障指標及異常時間段獲取異常前后收集的數值數據在上萬個數值指標中取出故障發生前后有波動的指標故障指標和波動指標進行相似性匹配丟棄指標結合數據進行分析定位問題故障得到和故障指標時序曲線相似的數值指標剔除低消耗或被影響指標無異常有異常不相

10、似相似運維建設監控模塊與智能分析 自動化分析流程實例1.報告故障指標顯示 4:30 OB集群中出現服務器 CPU上升4.報告的分析結果板塊定位到CPU上升和tablex表的訪問上升有關，而這張表的訪問上升又和這1條SQL語句訪問耗時增長有關，最終定位由于該SQL導致CPU上升。2.報告中的表訪問趨勢板塊，發現CPU上升趨勢與表訪問趨勢一致3.報告中SQL板塊的相關SQL趨勢與表訪問趨勢相近運維建設配套工具建設1.與原MySQL的表結構發布系統兼容2.利用obcdc支持Canal訂閱兼容3.基于ob_admin制作數據閃回工具4.基于sql_audit的準全量trace采集5.分布式數據庫日志分析。運維建設災備方案如何實現？集群：cls01異步集群：cls01mirror異步同步Zone:ZONE1Proxy-機房110.10.10.1F物理機Zone:ZONE2Proxy-機房210.20.10.2F物理機Zone:ZONE310.30.10.3L虛擬Zone:ZONE1Proxy-機房310.40.10.1F物理機總結和未來展望在OceanBase 4 版本下我們還能做些什么？探索新的單機分布式一體化架構01更多的生態和兼容性增強02基于新功能的運維能力提升03Thank you!