TiDB 7.5 LTS 發版丨提升規模化場景下關鍵應用的穩定性和成本的靈活性

網際網路時代，資料的迅猛增長給資料庫帶來了可擴充套件性的挑戰，Gen AI 帶來的資料暴增更加劇了這種挑戰。傳統的資料分片已經不能承載新時代資料暴增的需求，更簡單且具有前瞻性的方法則是採用原生分散式資料庫來解決擴充套件性問題。在這種規模化場景的背景下，TiDB 的研發團隊和開源貢獻者們始終致力於解決事務一致性、資料永續性以及大規模擴充套件所帶來的新挑戰，以及保障關鍵應用的穩定性。

作為  TiDB  7 系列的第二個長期支援版本 (LTS) ，TiDB 7.5 著眼於提升規模化場景下關鍵應用的穩定性。 新版本中，TiDB 在可擴充套件性與效能、穩定性與高可用、SQL 以及可觀測性等方面獲得了持續的提升。TiDB 7.5 LTS 包含了已釋出的 7.2.0-DMR、7.3.0-DMR 和 7.4.0-DMR 版本中的新功能、提升改進和錯誤修復，累計最佳化和修復功能 70 餘項。

本文將探討 TiDB 7.5 如何在規模化場景下實現關鍵應用整體穩定性的提升，探討資源管控支援後端任務和管理資源消耗超出預期的查詢（Runaway Queries）等重要特性，這些特性讓使用者可以在靈活排程資源降低總體成本的情況下可以保持關鍵應用的穩定性。

資源管控支援後端任務管理，提升執行關鍵業務的穩定性

TiDB 7.1 引入的資源管控（Resource Control）特性，多個業務可共享同一個 TiDB 叢集，DBA 可為不同的工作負載設定資源配額和優先順序，例如為關鍵業務分配更高的優先順序，確保其能夠優先獲得資源，避免受到其他工作負載的干擾。 此前，資源管控無法對 DDL、analyze、import 等後端任務進行控制，這些任務通常定期或不定期觸發，在執行的時候會消耗資源，從而對關鍵業務的執行產生影響。

自 TiDB 7.4 開始，資源管控支援後端任務管理。當一種任務被標記為後端任務時，TiKV 會動態地限制該任務的資源使用，以儘量避免此類任務在執行時對前臺任務產生影響。TiKV 透過實時地監測所有前臺任務所消耗的 CPU 和 IO 等資源，並根據例項的總體資源上限計算出後端任務可使用的資源閾值，所有後端任務在執行時會受此閾值的限制。當後端任務被識別匹配後，資源管控會自動進行，即當系統資源緊張時，後端任務會自動降為最低優先順序，以確保前臺任務的執行效率。  這個功能的增強允許  DBA  透過設定自動識別後端任務，並降低其資源消耗。 未來，這個功能將進一步擴充套件，提供給使用者更豐富的配置選擇，從而賦予使用者對叢集中後端任務更多的控制權。

下表展示了當“analyze”後端任務以預設優先順序和低優先順序執行時對前臺工作負載的影響對比：

在上表的示例 中，第一行展示了當所有叢集資源均可供前臺工作負載使用時的效能。 第二行展示了在後臺新增 “analyze” 任務時發生的情況。 第三行則展示了利用新特性自動對 “analyze” 任務進行管控時的效果。

將後端任務 (Add index, lmport into 任務) 排程到指定的 TiDB 節點執行

TiDB 7.2 開始，引入了分散式框架 (  https:// docs.pingcap.com/zh/tid b/stable/tidb-distributed-execution-framework  )，該框架的目標是實現對所有後端任務的統一排程與分散式執行，併為接入的後端任務提供統一的資源管理能力。分散式框架支援後端任務（特指 Add index 和 Import into 任務）在 TiDB 叢集的所有 TiDB 節點上執行，以提升此類任務的效能。而  TiDB 7.5 允許 DBA 將 Add index，Import into 這類消耗資源較多的後端任務排程到指定的 TiDB 節點上執行，從而和存量 TiDB 節點上的負載進行隔離，避免對業務產生影響 。當在想要執行後端任務的節點上設定 tidb_service_scope 為 background 時，後端任務分散式框架將排程該節點執行後端任務。但未經這樣設定，則該節點將不會被用於執行後端任務。

這一改進真正的突破在於能夠動態地新增 TiDB 節點來處理突發的這類後端任務。如果需要匯入一個龐大的表，只需向叢集中新增若干個 TiDB 節點來完成，而不會對現有 TiDB 節點造成任何額外壓力，新增索引的方式也是如此。完成任務後，這些節點可以被撤銷。這一功能為在生產叢集上輕鬆處理大型任務（Add index ，Import 大量資料）提供了更加無縫的方式。

暫停和恢復執行 DDL 任務

在 v7.1 版本之前，使用者在某些場景下會遇到 DDL 執行的痛點，具體表現為：

● 叢集版本升級時，若有正在執行的 DDL 未被取消，可能導致升級後的資料異常。

● 對於擁有數十億行資料的大表，為其新增索引可能需要相當長的時間，對線上業務造成不可忽視的影響。

為了解決這些問題，我們在 v7.1.0 中引入了一項新功能：DDL 任務的暫停和恢復。這一功能在 v7.5.0 中正式釋出，為使用者帶來了更加靈活和高效的 DDL 執行體驗。

具體而言，該功能巧妙地解決了上述痛點：

● 在使用 TiUP 對叢集升級的過程中，系統將自動暫停正在執行的 DDL 任務，並在升級完成後自動恢復執行該 DDL 任務。全程無需人為干預，有效避免由於人員疏忽導致未暫停 DDL 而引起叢集升級後資料不一致的問題。

● 針對執行耗時較長的 DDL，比如給大表新增索引，使用者可以在業務高峰期來臨前手動暫停該 DDL，並在業務低谷期恢復該 DDL 任務，從而有效避免對線上業務的影響。

DDL 任務的暫停和恢復機制支援斷點續傳，不僅保障了 DDL 任務的安全性和穩定性，同時最大化地保證了使用者資料一致性和業務的穩定性。

監控和管理資源消耗超出預期的查詢

突發的查詢效能下降，是影響資料庫整體效能最常見的問題，很難完全規避。 即使設定了資源組限額，也只能消除資源組間的相互影響，而個別 SQL 的過渡消耗仍會對降低資源組內的其他操作的效能。 為解決此問題，TiDB 7.2 資源管控引入了對 Runaway Queries 的管理，自動識別並處理消耗超出預期的查詢，在 TiDB 7.3 引入了手動管理 Runaway Queries 監控列表的功能，將 SQL 特徵新增到隔離監控列表，從而實現快速隔離 Runaway Queries。 無論使用者是否使用了資源組，都可以藉助 Runaway Queries 管理來緩和突發的 SQL 效能問題。

DBA  現在可以為每個資源組設定“查詢限制 (Query Limit)”，並配備幾個關鍵引數 。EXE C_ELAPSED 用於設定查詢持續時間的閾值，任何超出這一閾值的查詢都會被識別為 Runaway Query。ACTION 決定當識別到 Runaway Query 時進行的動作，可以把執行優先順序降到最低也可以終止該查詢。WATCH 用於快速匹配已經識別到的 Runaway Query，即在一定時間內再碰到相同或相似的查詢，可以直接按照配置的措施進行處理，避免其在被識別的過程中對資源進行消耗。

如果一些 Runaway Queries 並沒有被自動識別，DBA 也可以透過 SQL 命令 "QUERY WATCH"手動將查詢的特徵加入“監視列表”，類似於設定資料庫級別的 SQL 黑名單，特別適合那些對資料庫響應時間要求很高的客戶，為突發的 SQL 效能問題提供了一種有效的防範措施。這項功能和資源管控結合使用，意味著在業務系統之間以及業務系統內部都能實現更高的穩定性，從而最大限度地減少多業務合併過程中可能出現的潛在風險。

立即體驗 TiDB 7.5

從 TiDB 7.0 開始，TiDB 在資料庫整合的技術方向上持續演進，致力於在多業務融合的場景下同時提升關鍵業務的穩定性和降低總體成本，7.5 LTS 將資源管控、分散式框架、可觀測性理念的組合推升到更為成熟的階段，可以為當前追求業務連續性同時也希望降低總體成本的客戶帶來創新的部署和運維方式 。