導(dǎo)讀
愛奇藝作為業(yè)內(nèi)知名的在線視頻平臺，憑借其豐富多樣的內(nèi)容和優(yōu)質(zhì)的用戶體驗，業(yè)務(wù)增長迅猛，數(shù)據(jù)量也隨之劇增。為了滿足業(yè)務(wù)需求，愛奇藝自 2017 年開始使用 TiDB，應(yīng)用涵蓋 30 多個業(yè)務(wù)線，服務(wù)器數(shù)量超過 500 臺，集群數(shù)量超過 100 個，同時運(yùn)行的 TiDB 版本數(shù)量達(dá) 20+。本文將深入探討愛奇藝如何通過升級，成功將百套 TiDB 集群從多個舊版本升級至 v7.1.5，攻克多版本運(yùn)維挑戰(zhàn)，獲得更穩(wěn)更快的 TiDB 使用體驗。
TiDB 社區(qū)活動（上海站）回顧 & ppt 下載：【TiDB 上海地區(qū)交流回顧】TiDB 在小紅書、愛奇藝、咪咕、華安基金、數(shù)禾科技的核心場景/簡化技術(shù)棧/降本增效實踐
應(yīng)對業(yè)務(wù)增長與數(shù)據(jù)挑戰(zhàn)
隨著互聯(lián)網(wǎng)用戶對內(nèi)容需求的增長，愛奇藝的業(yè)務(wù)規(guī)模迅速擴(kuò)大，數(shù)據(jù)量和會員數(shù)不斷攀升。傳統(tǒng)的分庫分表方式在數(shù)據(jù)校驗和流量切換方面逐漸顯得力不從心，嚴(yán)重影響了業(yè)務(wù)的高效運(yùn)行。TiDB 以其卓越的分布式架構(gòu)和強(qiáng)大的數(shù)據(jù)處理能力，為愛奇藝提供了一個超大號的 MySQL 解決方案，有效解決了分庫分表帶來的諸多痛點，確保了數(shù)據(jù)的一致性和業(yè)務(wù)的穩(wěn)定性。
利用 TiFlash 列存特性與節(jié)點擴(kuò)展性
TiDB 的 TiFlash 列存特性為愛奇藝帶來了顯著的性能提升。通過利用 TiFlash，愛奇藝能夠高效地進(jìn)行數(shù)據(jù)分析和查詢，加速了業(yè)務(wù)決策過程。此外，TiDB 節(jié)點的易擴(kuò)展性使得愛奇藝能夠靈活地應(yīng)對不斷增長的數(shù)據(jù)量和業(yè)務(wù)需求。不同的 TiDB 節(jié)點可以分別處理 TP（事務(wù)處理）和 AP（分析處理）任務(wù)，實現(xiàn)了讀取一份數(shù)據(jù)即可滿足多種業(yè)務(wù)需求，避免了繁瑣的 ETL 數(shù)據(jù)清洗工作，進(jìn)一步提高了業(yè)務(wù)的響應(yīng)速度和決策效率。
集群規(guī)模、數(shù)據(jù)量及應(yīng)用場景
自 2017 年開始使用 TiDB 以來，愛奇藝的 TiDB 集群規(guī)模不斷擴(kuò)大。截至目前，愛奇藝擁有超過 500 臺服務(wù)器，集群數(shù)量超過 100 個。單集群數(shù)據(jù)量從 300G 到 40T 不等，涵蓋了會員數(shù)據(jù)歸檔、風(fēng)控、BI、素材、營銷數(shù)據(jù)、設(shè)備指紋等 30 多個應(yīng)用業(yè)務(wù)線。這些集群不僅支撐了愛奇藝的核心業(yè)務(wù)，還為數(shù)據(jù)的高效存儲和快速訪問提供了堅實保障。
版本管理與運(yùn)維挑戰(zhàn)
隨著業(yè)務(wù)的不斷發(fā)展，愛奇藝的 TiDB 集群中運(yùn)行著多個不同版本，從 v3.0.19 到 v6.0.x 共有 20 多個版本在線運(yùn)行。多版本并行不僅增加了運(yùn)維的復(fù)雜性，還給自動化運(yùn)維帶來了諸多挑戰(zhàn)。針對版本管理和運(yùn)維面臨挑戰(zhàn)，愛奇藝數(shù)據(jù)庫團(tuán)隊對 TiDB v7 版本進(jìn)行全面評估和方案設(shè)計，決定所有集群升級到 TiDB 社區(qū)推薦版本。
升級的理由
- 簡化運(yùn)維管理：不同版本之間的參數(shù)差異使得運(yùn)維團(tuán)隊需要投入更多的時間和精力確保各個版本的穩(wěn)定運(yùn)行。升級至統(tǒng)一的版本不僅可以減少運(yùn)維的復(fù)雜性，還能提高自動化運(yùn)維的效率。
- 修復(fù)現(xiàn)有問題：應(yīng)用遇到的 bug 在新版本中都得到修復(fù)，TiDB 新版本穩(wěn)定性有顯著提升。
- 應(yīng)用新版本特性：TiDB 新版本的諸多特性，如 TiCDC、數(shù)據(jù)自動清理 TTL、SPM 執(zhí)行計劃管理、快速加索引、BR 日志備份等，通過升級至 TiDB V7 版本，能充分利用這些新特性，進(jìn)一步優(yōu)化數(shù)據(jù)管理以及業(yè)務(wù)開發(fā)效率。
升級方案的制定
升級方案選擇
愛奇藝在升級過程中主要考慮了兩種方案：原地升級和遷移升級。原地升級的優(yōu)勢在于操作簡單，無需額外的硬件資源，但存在不支持回退、升級過程中禁止用戶發(fā)起 DDL 操作等風(fēng)險。遷移升級則具有業(yè)務(wù)影響時間短、不受版本跨度限制、可回退等優(yōu)點，但需要額外的硬件資源，成本較高。根據(jù)集群的實際情況和業(yè)務(wù)需求，愛奇藝靈活運(yùn)用這兩種方案，確保了升級過程的順利進(jìn)行。
升級路線規(guī)劃
愛奇藝采取了分版本逐步升級的策略，從 v3 開始，依次升級到 v4、v5、v6，最后升級到 v7。這一策略參考了滴滴跨版本的升級經(jīng)驗，避免了一次性跨越多個版本帶來的風(fēng)險。同時，愛奇藝優(yōu)先在測試環(huán)境中進(jìn)行升級，并讓業(yè)務(wù)團(tuán)隊進(jìn)行充分驗證，確保升級方案的可行性和穩(wěn)定性。此外，團(tuán)隊還優(yōu)先升級了 v6 和 v5 版本的集群，因為這兩個版本尚未到達(dá)生命周期末期，可以在社區(qū)中尋求廠商支持，及時解決升級過程中遇到的問題。對于流量小、容量小的非核心業(yè)務(wù)集群，愛奇藝也優(yōu)先進(jìn)行了升級，通過觀察升級過程中的問題，進(jìn)一步優(yōu)化了升級 SOP。
升級歷程與問題解決
在升級過程中，愛奇藝遇到了一些問題，并找到了相應(yīng)的解決思路。
- 部分業(yè)務(wù)報錯：升級后，部分業(yè)務(wù)出現(xiàn) org.springframework.jdbc.UncategorizedSQLException 錯誤，提示 client has multi - statement capability disabled。原因是 TiDB 高版本默認(rèn)不允許在同一 COM_QUERY 調(diào)用中執(zhí)行多個查詢，以減少 SQL 注入攻擊的影響。解決方案是將 tidb_multi_statement_mode 變量值設(shè)為 ON，以適配專為早期 TiDB 版本設(shè)計的業(yè)務(wù)。
- drainer 無法啟動：在測試集群 v4.0.16 跨版本升級 v7.1.4 時，drainer 升級時提示端口無法啟動。嘗試回退至 v5.4.3 繼續(xù)升級，卻因 V7 與 V5 版本 TiKV 目錄發(fā)生改變，導(dǎo)致 TiKV 異常退出。正確的解決方法是記錄 drainer 日志中的 savepoint 位點，縮容 drainer 組件，升級完成后，再用指定位點的方式擴(kuò)容 drainer 組件。此外，可能與服務(wù)器上一個異常的 NFS 服務(wù)有關(guān)。
- 業(yè)務(wù)邏輯有 DDL 導(dǎo)致 drainer 啟動失敗：升級過程中，業(yè)務(wù)自行 DDL，造成表的 table_id 不一致，drainer 無法啟動。業(yè)務(wù)對中間表進(jìn)行了 truncate & load data 操作，導(dǎo)致 table id 發(fā)生變化，drainer 在啟動時有此檢查項，從而啟動失敗。最終通過更換 cdc 同步，重做同步鏈路解決問題。為避免類似問題，每次升級前都會執(zhí)行 admin show ddl jobs 命令查看近期是否有 ddl 任務(wù)，提前告知業(yè)務(wù)升級時不能 ddl，如有定時任務(wù) ddl，在業(yè)務(wù)低峰期暫停相關(guān)定時任務(wù)，回收賬戶的 ddl 權(quán)限，升級完成后，再重新賦權(quán)。
- sync-log = false 與海量 region 調(diào)度引起升級后報 tikv : 9001 pd server 超時：升級后出現(xiàn) tikv: 9001 pd server 超時的錯誤，導(dǎo)致查詢語句失敗率升高至 5% - 10%，更新語句失敗率升高至 50% - 70%，插入語句正常。原因是集群早期對一些 TiKV 設(shè)置了 sync-log = false，在強(qiáng)制重啟的情況下可能需要短時間內(nèi)補(bǔ)副本以維護(hù)數(shù)據(jù)一致性，引發(fā) pd 調(diào)度升高；同時，集群數(shù)據(jù)量巨大，默認(rèn)的 trace-region-flow = true 參數(shù)在需要大量補(bǔ)副本的場景下，影響了 pd 與 TiKV 之間的心跳導(dǎo)致 pd 大量超時。解決方案是修改 trace-region-flow 參數(shù)為 false，并重啟 pd server。
升級整體感受
在 TiDB 升級過程中，我們看到了基礎(chǔ)服務(wù)正常（如 NFS、NTP 服務(wù)）、業(yè)務(wù)充分驗證的情況下，滾動升級比較簡單平滑，90+ 集群升級下來，僅 2 套集群升級遇到問題。升級后，有效收斂了業(yè)務(wù)高峰期 P99 duration 高和負(fù)載高的告警數(shù)量。運(yùn)維也變得更加簡易，白屏化的綁定執(zhí)行計劃、更短的添加索引時間，使得在慢 SQL 導(dǎo)致集群性能下降的情況下，能夠更快地恢復(fù)集群性能，減少故障時間。
升級后，TiDB 集群在性能和穩(wěn)定性等方面取得了顯著提升。
- 性能提升與穩(wěn)定性增強(qiáng)：升級后，小的毛刺 SQL 消失，穩(wěn)定性提高。例如，一個 BI 的 AP 類集群，升級后 SQL 耗時從 8s 降至 2s，聚合計算 SQL 性能提升，穩(wěn)定性增加。
- 數(shù)據(jù)管理優(yōu)化：利用 TTL 功能清理冗余數(shù)據(jù)，有效管理數(shù)據(jù)生命周期。同時，dashboard 快速綁定執(zhí)行計劃，簡化了操作流程，提高了運(yùn)維效率。
- 備份與恢復(fù)能力提升：br 支持日志備份，可靈活選擇恢復(fù)時間點，實現(xiàn) Point-in-time recovery，為數(shù)據(jù)安全提供了更有力的保障。
- 同步任務(wù)穩(wěn)定性增強(qiáng)：TiCDC 將大事務(wù)拆分為小消息體，Kafka 不會因消息體過大而導(dǎo)致 OOM，相關(guān)同步任務(wù)更加穩(wěn)定。
- 運(yùn)維效率提升：大表添加索引時間由之前的 13h 降至 20min，大大加快了運(yùn)維速度，減少了故障恢復(fù)時間。
在 TiDB 運(yùn)維和升級的過程中，TiDB 官方社區(qū)給予了大力的支持和幫助，為本次升級工作提供了有力的技術(shù)保障。
愛奇藝的 TiDB 升級實踐證明了 TiDB 在大規(guī)模數(shù)據(jù)處理和業(yè)務(wù)支撐方面的強(qiáng)大能力，也非常期待 TiDB 在數(shù)據(jù)清理速度、SQL 性能優(yōu)化等方面進(jìn)一步提升，得以滿足不斷增長的業(yè)務(wù)需求。未來，愛奇藝將繼續(xù)與 TiDB 攜手，共同探索更多優(yōu)化和創(chuàng)新的可能性，為用戶提供更加優(yōu)質(zhì)、穩(wěn)定的服務(wù)。
熱門跟貼