定性、查詢服務(wù)競態(tài)修復(fù)與半同步一致性治理)
Vitess v15.0.5 變更深度解析Online DDL 穩(wěn)定性、查詢服務(wù)競態(tài)修復(fù)與半同步一致性治理【免費下載鏈接】vitessVitess is a database clustering system for horizontal scaling of MySQL.項目地址: https://gitcode.com/gh_mirrors/vi/vitess本篇技術(shù)指南圍繞 Vitess v15.0.5release-15.0 分支補丁版本的官方變更記錄展開逐項解析本次版本在 Online DDL、Query Serving、TabletManager 半同步復(fù)制、集群備份管理以及 CI/構(gòu)建工程化上的修復(fù)動機、實現(xiàn)原理與升級影響并結(jié)合當前倉庫源碼驗證每一條修復(fù)背后的真實調(diào)用鏈幫助讀者在升級 v15 分支前準確評估風(fēng)險收益、理解各修復(fù)在代碼層面的落點。版本定位v15 生命周期內(nèi)的第五個補丁版本v15.0.5是 Vitess 15.0 穩(wěn)定分支release-15.0的第五個補丁版本。從變更記錄changelog/15.0/15.0.5/changelog.md看本次發(fā)布以穩(wěn)定性修復(fù)為絕對主線共覆蓋五大類別Bug fixes包含 Build/CI、Cluster management、Online DDL、Query Serving、TabletManager 五個子類CI/Build文檔生成工具鏈docgen與 vtorc 容器化改進Documentation自動生成文檔的路徑匿名化Internal Cleanup升級測試 Go 版本Releasev15.0.5 代碼凍結(jié)TestingCI 環(huán)境下的 reparent 測試清理與 FOSSA 測試移除。其中 Online DDL 相關(guān)修復(fù)占據(jù)了近一半的變更量是本版本當之無愧的核心主題緊隨其后的是查詢服務(wù)Query Serving的多個競態(tài)條件修復(fù)。下文按類別逐一展開。Online DDL本版本的重頭戲v15.0.5 共包含 5 項 Online DDL 相關(guān)修復(fù)覆蓋并發(fā)安全、策略語義、狀態(tài)機一致性、產(chǎn)物清理四個維度。RevertMigration.Comment 讀寫并發(fā)問題變更記錄指出本版本解決了RevertMigration.Comment的讀寫并發(fā)問題PR #13735。Revert 操作在 Vitess 中用于回滾一條已執(zhí)行的 Online DDL 遷移當REVERT語句提交后vttablet 會解析被回滾遷移的元數(shù)據(jù)生成一條新的遷移記錄并建立reverted_uuid關(guān)聯(lián)。從 executor.go 的SubmitMigration實現(xiàn)可以看到L5470 附近提交 REVERT 遷移時會通過onlineDDL.GetRevertUUID()解析出被回滾遷移的 UUID并將其作為reverted_uuid寫入_vt.schema_migrations表。Comment字段的并發(fā)讀寫如果不加保護在多協(xié)程同時讀取/回填遷移注釋時可能產(chǎn)生數(shù)據(jù)競態(tài)導(dǎo)致注釋內(nèi)容錯亂甚至 panic。該修復(fù)即針對這一數(shù)據(jù)結(jié)構(gòu)的并發(fā)訪問路徑加鎖或改用原子語義確保 Revert 場景下遷移注釋的一致可讀。immediate operations 語義正式化與 --postpone-completionPR #13832 是本次 Online DDL 修復(fù)中語義影響最大的一項正式化 immediate operations即時操作概念并讓 DDL strategy 標志--postpone-completion對這類操作生效。所謂 immediate operations指那些不依賴數(shù)據(jù)拷貝copy階段、可以立刻完成的 DDL 操作例如CREATE TABLE、DROP TABLE以及 MySQL 8.0 支持INSTANT算法的部分列操作。在 executor.go 中可以找到該語義在代碼中的完整落點L2179從遷移記錄中讀取is_immediate_operation布爾字段L2188-2190注釋明確說明即時操作天生具備 ready to complete 狀態(tài)inherently ready to complete因為其操作本身就是即時的L2197判斷!isImmediateOperation || !postponeCompletion決定遷移是否可以立即進入完成流程L2262-2301reviewImmediateOperations注釋定義了何謂即時操作、何謂非即時操作例如針對真實ALTER TABLE的 REVERT 就不屬于即時操作L3331、L3364-3366在in-order completion按序完成模式下即時操作必須位于其遷移上下文中第一個待處理位置因為它在運行后一至兩秒內(nèi)即可完成。對用戶而言這意味著此前--postpone-completion標志對某些本應(yīng)立即完成的遷移失效的問題得到解決。策略標志現(xiàn)在能夠統(tǒng)一控制何時讓遷移真正完成cut-over而無論其底層是即時操作還是需要數(shù)據(jù)拷貝的重型操作。需要特別指出的是--postpone-completion并非所有策略都支持從 executor.go L2341-2342 可以看到當 DDL 策略為mysql即直接透傳 MySQL 原生 DDL時會直接返回INVALID_ARGUMENT錯誤提示--postpone-completion not supported in mysql strategy。修復(fù)取消遷移的 completed_timestamp 為空PR #13935 修復(fù)了被取消cancelled的遷移completed_timestamp為 NULL 的問題。該字段在 Online DDL 狀態(tài)機中承擔遷移何時結(jié)束的語義而清理邏輯artifact cleanup依賴它計算產(chǎn)物保留時長。對應(yīng)的修復(fù)在 schema.go 中新增了sqlFixCompletedTimestamp語句L428-435UPDATE _vt.schema_migrations SET completed_timestampNOW(6) WHERE migration_status IN (cancelled, failed) AND cleanup_timestamp IS NULL AND completed_timestamp IS NULL即對于處于cancelled或failed狀態(tài)、尚未清理且完成時間缺失的遷移回填當前時間戳。這一補賬操作保證了清理調(diào)度器見下文在計算completed_timestamp NOW() - INTERVAL retain_artifacts_seconds時不會因為 NULL 時間戳而跳過或誤判歷史遷移從而避免取消/失敗遷移的產(chǎn)物永遠得不到回收。取消遷移產(chǎn)物清理與 --retain-artifacts 策略標志PR #14035 是另一項重量級修復(fù)清理被取消遷移的殘留產(chǎn)物并支持--retain-artifactsdurationDDL 策略標志。在 v15.0.5 之前遷移一旦被取消其創(chuàng)建的表如_vt_xxx_gho影子表、_vt_xxx_ghc變更日志表、_vt_xxx_del延遲刪除表等 artifacts可能因清理條件不滿足而長期滯留。修復(fù)后清理邏輯統(tǒng)一由sqlSelectUncollectedArtifacts驅(qū)動schema.go L414-427SELECT migration_uuid, artifacts, log_path FROM _vt.schema_migrations WHERE migration_status IN (complete, cancelled, failed) AND cleanup_timestamp IS NULL AND completed_timestamp IF(retain_artifacts_seconds0, NOW() - INTERVAL %a SECOND, NOW() - INTERVAL retain_artifacts_seconds SECOND ) ORDER BY id可見清理條件同時覆蓋complete、cancelled、failed三種終態(tài)且每個遷移的保留時長可獨立控制retain_artifacts_seconds0時回退到全局默認保留時長%a占位符否則按遷移自身的保留時長計算。--retain-artifacts策略標志的生效邏輯位于 executor.go L5471-5475retainArtifactsSeconds : int64(retainOnlineDDLTables.Seconds()) if retainArtifacts, _ : onlineDDL.StrategySetting().RetainArtifactsDuration(); retainArtifacts ! 0 { // Explicit retention indicated by --retain-artifact DDL strategy flag for this migration. Override! retainArtifactsSeconds int64(retainArtifacts.Seconds()) }即遷移級策略標志優(yōu)先于 vttablet 全局的retainOnlineDDLTables配置最終隨sqlInsertMigration一并寫入_vt.schema_migrations.retain_artifacts_seconds字段L5498。典型用法ALTER TABLE my_table DROP COLUMN c1, ALGORITHMghost, --retain-artifacts168h;這允許運維針對個別大表顯式延長或縮短影子表保留期例如調(diào)試期間想多留幾天影子表做比對而無需改動全局參數(shù)。修復(fù)改列名與列類型為 JSON 的 bugPR #14115 修復(fù)了將列名與列類型同時改為 JSON時的錯誤。這類 DDL 形如ALTER TABLE t CHANGE COLUMN old_col new_col JSON在 Online DDL 的 ghost/切表流程中涉及列映射column list推導(dǎo)與 vreplication 字段映射邊界場景處理不當會導(dǎo)致遷移失敗或數(shù)據(jù)錯位。該修復(fù)屬于 Online DDL 邊界條件正確性的收尾工作。Query Serving四處競態(tài)與代價模型修正schema tracker 遍歷表/視圖時的競態(tài)PR #13794 修復(fù)了 vttablet 端 schema tracker 在**遍歷表tables與視圖views**時存在的競態(tài)條件。schema tracker 維護內(nèi)存中的 schema 緩存供 vtgate 下發(fā)查詢計劃時引用。當后臺 refresh 線程在更新 schema 的同時查詢線程正在迭代表/視圖列表若無鎖保護會觸發(fā) data race進而可能導(dǎo)致計劃構(gòu)建讀到半更新狀態(tài)的 schema。該修復(fù)在迭代路徑上補齊了同步保護屬于典型的并發(fā)訪問正確性問題。模糊測試fuzzing發(fā)現(xiàn)的一批 bug 修復(fù)PR #13807 匯總了 vitess 團隊在持續(xù)模糊測試中發(fā)現(xiàn)的若干問題。Vitess 倉庫中維護了專門的 fuzzer可參見 go/mysql/mysql_fuzzer.goSQL 解析器、協(xié)議解析路徑是重點目標。這類修復(fù)通常涉及畸形 SQL 導(dǎo)致解析器 panic極端輸入導(dǎo)致內(nèi)存分配失控錯誤處理路徑中再次拋出異常掩蓋原始錯誤。建議升級用戶在發(fā)布說明之外重點關(guān)注 SQL 兼容性邊界因為模糊測試修復(fù)往往悄悄改變了某些邊緣語法的處理行為。join 引擎 OLAP 流式執(zhí)行的數(shù)據(jù)競態(tài)PR #14014 修復(fù)了join 引擎原語在 OLAP 流式streaming模式執(zhí)行時的數(shù)據(jù)競態(tài)。對應(yīng)代碼位于 go/vt/vtgate/engine/join.goTryStreamExecuteL123 起在流式執(zhí)行時引入了sync.MutexL125-127確保并發(fā)讀取 join 兩翼結(jié)果集時共享狀態(tài)的一致性。該修復(fù)對大規(guī)模聚合/Join 分析查詢OLAP 工作負載的穩(wěn)定性有直接價值——此前在高并發(fā)流式場景下可能出現(xiàn)計劃執(zhí)行器狀態(tài)被并發(fā)修改導(dǎo)致的非確定性結(jié)果或 panic。代價模型將 subshard opcode 納入 costPR #14025 修復(fù)了 vtgate 代價cost計算未包含 subshard opcode 的問題。在 v3 規(guī)劃器中路由 opcode如EqualUnique、IN、Subshard等決定查詢發(fā)往分片的方式。若代價計算遺漏Subshard這一 opcode規(guī)劃器可能高估或低估某些查詢的代價進而選擇次優(yōu)的執(zhí)行計劃例如錯誤地合并/拆分查詢、選擇錯誤的 route 方式。修復(fù)后代價估算更貼近真實執(zhí)行開銷有利于在跨分片場景下選出更合理的計劃。TabletManager半同步動作枚舉的全量覆蓋PR #13957 修復(fù)了convertBoolToSemiSyncAction方法未能覆蓋全部半同步動作的問題。該方法位于 go/vt/vttablet/tabletmanager/rpc_actions.go L194-214func (tm *TabletManager) convertBoolToSemiSyncAction(ctx context.Context, semiSync bool) (SemiSyncAction, error) { semiSyncExtensionLoaded, err : tm.MysqlDaemon.SemiSyncExtensionLoaded(ctx) if err ! nil { return SemiSyncActionNone, err } switch semiSyncExtensionLoaded { case mysql.SemiSyncTypeSource, mysql.SemiSyncTypeMaster: if semiSync { return SemiSyncActionSet, nil } else { return SemiSyncActionUnset, nil } default: if semiSync { return SemiSyncActionNone, vterrors.VT09013() } else { return SemiSyncActionNone, nil } } }半同步動作枚舉定義在同文件 L47-53SemiSyncActionNone、SemiSyncActionSet、SemiSyncActionUnset。修復(fù)前該方法在某些 MySQL/分支的半同步插件狀態(tài)SemiSyncType變體下無法正確映射出Set/Unset動作導(dǎo)致在主從切換PlannedReparentShard / EmergencyReparentShard或備份恢復(fù)流程中半同步配置無法按預(yù)期啟停。修復(fù)后當半同步插件以 source/master 類型加載時布爾值正確映射為SemiSyncActionSet或SemiSyncActionUnset其他情況下插件未加載或類型未知若請求開啟半同步則返回VT09013錯誤若請求關(guān)閉則安全返回None。該方法的調(diào)用點包括 rpc_actions.go 的ChangeType流程L129以及 rpc_backup.goL172備份結(jié)束恢復(fù)原類型時和 rpc_replication.goL313。對于依賴半同步保證數(shù)據(jù)不丟失的集群這一修復(fù)直接關(guān)系到切換與恢復(fù)流程中的復(fù)制安全。Cluster ManagementBackupShard 使用自身標志PR #13818 修復(fù)了BackupShard從**自身標志flags**而非外部默認值獲取選項的問題。BackupShard是 vtctld 暴露的 RPC請求結(jié)構(gòu)定義見 go/vt/proto/vtctldata/vtctldata.pb.go 的BackupShardRequest請求字段包括allow_primary、concurrency、upgrade_safe、incremental_from_pos、mysql_shutdown_timeout、init_sql等。修復(fù)前BackupShard在構(gòu)造備份請求時可能讀取了錯誤來源的參數(shù)例如 vtctld 進程級標志或默認值導(dǎo)致通過 RPC 觸發(fā)的備份與命令行觸發(fā)的備份行為不一致——例如并發(fā)度、是否允許主庫備份等選項未按調(diào)用方意圖生效。修復(fù)后每次BackupShard調(diào)用都嚴格以其請求參數(shù)為準保證vtctldclient BackupShard與內(nèi)部調(diào)用語義一致。CI/Build、工程化與發(fā)布流程改進v15.0.5 的工程化改進同樣值得關(guān)注靜態(tài)檢查覆蓋 changelog 目錄PR #14004Static Code Checks Etc現(xiàn)在會在./changelog目錄過期如未生成新版本變更記錄時讓 CI 失敗從流程上強制每個發(fā)布分支維護變更記錄這也是本文檔所在目錄能保持結(jié)構(gòu)一致的原因啟用 e2e 競態(tài)檢測失敗PR #14009tools/e2e_test_race.sh現(xiàn)在允許競態(tài)檢測失敗直接中斷 CI并修復(fù)了一批已知競態(tài)與本次多處 data race 修復(fù)形成呼應(yīng)升級測試 Go 版本到 go1.20.8PR #13938release-15.0 分支的升級測試環(huán)境更新至 Go 1.20.8vtorc 專用容器PR #14145docker 目錄新增專門的 vtorc 容器鏡像vtorcVitess 拓撲恢復(fù)控制器不再需要依賴通用鏡像手工組裝docgen 嵌入 commit IDPR #14072與homedir 匿名化PR #14104自動生成的文檔 frontmatter 中嵌入 commit ID并對文檔中的用戶主目錄路徑做匿名化處理提升文檔可追溯性與隱私性CI 穩(wěn)定性PR #14118、#14120在 reparent 測試 teardown 中刪除 VTDATAROOT 殘留文件以消除測試相互污染并在找到安全方案前移除 FOSSA 測試。升級建議與風(fēng)險提示Online DDL 語義變化需重點回歸--postpone-completion對即時操作CREATE/DROP 等生效范圍的擴大可能改變現(xiàn)有自動化流程對遷移何時完成的預(yù)期若你的流程依賴遷移完成時間點觸發(fā)后續(xù)動作升級后建議先在測試環(huán)境驗證 DROP/CREATE 類遷移的行為半同步修復(fù)直接影響切換安全convertBoolToSemiSyncAction的全量覆蓋意味著主從切換、備份恢復(fù)流程中半同步啟停行為更規(guī)范但若集群使用了非標準半同步插件加載方式需關(guān)注VT09013錯誤是否會因semiSynctrue請求而暴露產(chǎn)物清理策略可下放到遷移級借助--retain-artifactsduration可針對大表或?qū)徲嬓枨蟛町惢O(shè)置影子表保留時長同時取消/失敗遷移的產(chǎn)物將不再無限滯留查詢服務(wù)穩(wěn)定性提升join OLAP 流式執(zhí)行與 schema tracker 的競態(tài)修復(fù)對高并發(fā)分析查詢和 schema 頻繁變更的集群收益明顯。參考文件索引版本變更記錄changelog/15.0/15.0.5/changelog.mdOnline DDL 執(zhí)行器與策略語義go/vt/vttablet/onlineddl/executor.goOnline DDL 內(nèi)部表 SQL 與清理邏輯go/vt/vttablet/onlineddl/schema.go半同步動作映射修復(fù)go/vt/vttablet/tabletmanager/rpc_actions.go半同步在備份/復(fù)制流程中的調(diào)用go/vt/vttablet/tabletmanager/rpc_backup.go、go/vt/vttablet/tabletmanager/rpc_replication.gojoin 引擎流式執(zhí)行競態(tài)修復(fù)go/vt/vtgate/engine/join.goBackupShard RPC 請求定義go/vt/proto/vtctldata/vtctldata.pb.go【免費下載鏈接】vitessVitess is a database clustering system for horizontal scaling of MySQL.項目地址: https://gitcode.com/gh_mirrors/vi/vitess創(chuàng)作聲明：本文部分內(nèi)容由AI輔助生成（AIGC），僅供參考 Vitess v15.0.5 變更深度解析：Online DDL 穩(wěn)定性、查詢服務(wù)競態(tài)修復(fù)與半同步一致性治理
Vitess v15.0.5 變更深度解析Online DDL 穩(wěn)定性、查詢服務(wù)競態(tài)修復(fù)與半同步一致性治理【免費下載鏈接】vitessVitess is a database clustering system for horizontal scaling of MySQL.項目地址: https://gitcode.com/gh_mirrors/vi/vitess本篇技術(shù)指南圍繞 Vitess v15.0.5release-15.0 分支補丁版本的官方變更記錄展開逐項解析本次版本在 Online DDL、Query Serving、TabletManager 半同步復(fù)制、集群備份管理以及 CI/構(gòu)建工程化上的修復(fù)動機、實現(xiàn)原理與升級影響并結(jié)合當前倉庫源碼驗證每一條修復(fù)背后的真實調(diào)用鏈幫助讀者在升級 v15 分支前準確評估風(fēng)險收益、理解各修復(fù)在代碼層面的落點。版本定位v15 生命周期內(nèi)的第五個補丁版本v15.0.5是 Vitess 15.0 穩(wěn)定分支release-15.0的第五個補丁版本。從變更記錄changelog/15.0/15.0.5/changelog.md看本次發(fā)布以穩(wěn)定性修復(fù)為絕對主線共覆蓋五大類別Bug fixes包含 Build/CI、Cluster management、Online DDL、Query Serving、TabletManager 五個子類CI/Build文檔生成工具鏈docgen與 vtorc 容器化改進Documentation自動生成文檔的路徑匿名化Internal Cleanup升級測試 Go 版本Releasev15.0.5 代碼凍結(jié)TestingCI 環(huán)境下的 reparent 測試清理與 FOSSA 測試移除。其中 Online DDL 相關(guān)修復(fù)占據(jù)了近一半的變更量是本版本當之無愧的核心主題緊隨其后的是查詢服務(wù)Query Serving的多個競態(tài)條件修復(fù)。下文按類別逐一展開。Online DDL本版本的重頭戲v15.0.5 共包含 5 項 Online DDL 相關(guān)修復(fù)覆蓋并發(fā)安全、策略語義、狀態(tài)機一致性、產(chǎn)物清理四個維度。RevertMigration.Comment 讀寫并發(fā)問題變更記錄指出本版本解決了RevertMigration.Comment的讀寫并發(fā)問題PR #13735。Revert 操作在 Vitess 中用于回滾一條已執(zhí)行的 Online DDL 遷移當REVERT語句提交后vttablet 會解析被回滾遷移的元數(shù)據(jù)生成一條新的遷移記錄并建立reverted_uuid關(guān)聯(lián)。從 executor.go 的SubmitMigration實現(xiàn)可以看到L5470 附近提交 REVERT 遷移時會通過onlineDDL.GetRevertUUID()解析出被回滾遷移的 UUID并將其作為reverted_uuid寫入_vt.schema_migrations表。Comment字段的并發(fā)讀寫如果不加保護在多協(xié)程同時讀取/回填遷移注釋時可能產(chǎn)生數(shù)據(jù)競態(tài)導(dǎo)致注釋內(nèi)容錯亂甚至 panic。該修復(fù)即針對這一數(shù)據(jù)結(jié)構(gòu)的并發(fā)訪問路徑加鎖或改用原子語義確保 Revert 場景下遷移注釋的一致可讀。immediate operations 語義正式化與 --postpone-completionPR #13832 是本次 Online DDL 修復(fù)中語義影響最大的一項正式化 immediate operations即時操作概念并讓 DDL strategy 標志--postpone-completion對這類操作生效。所謂 immediate operations指那些不依賴數(shù)據(jù)拷貝copy階段、可以立刻完成的 DDL 操作例如CREATE TABLE、DROP TABLE以及 MySQL 8.0 支持INSTANT算法的部分列操作。在 executor.go 中可以找到該語義在代碼中的完整落點L2179從遷移記錄中讀取is_immediate_operation布爾字段L2188-2190注釋明確說明即時操作天生具備 ready to complete 狀態(tài)inherently ready to complete因為其操作本身就是即時的L2197判斷!isImmediateOperation || !postponeCompletion決定遷移是否可以立即進入完成流程L2262-2301reviewImmediateOperations注釋定義了何謂即時操作、何謂非即時操作例如針對真實ALTER TABLE的 REVERT 就不屬于即時操作L3331、L3364-3366在in-order completion按序完成模式下即時操作必須位于其遷移上下文中第一個待處理位置因為它在運行后一至兩秒內(nèi)即可完成。對用戶而言這意味著此前--postpone-completion標志對某些本應(yīng)立即完成的遷移失效的問題得到解決。策略標志現(xiàn)在能夠統(tǒng)一控制何時讓遷移真正完成cut-over而無論其底層是即時操作還是需要數(shù)據(jù)拷貝的重型操作。需要特別指出的是--postpone-completion并非所有策略都支持從 executor.go L2341-2342 可以看到當 DDL 策略為mysql即直接透傳 MySQL 原生 DDL時會直接返回INVALID_ARGUMENT錯誤提示--postpone-completion not supported in mysql strategy。修復(fù)取消遷移的 completed_timestamp 為空PR #13935 修復(fù)了被取消cancelled的遷移completed_timestamp為 NULL 的問題。該字段在 Online DDL 狀態(tài)機中承擔遷移何時結(jié)束的語義而清理邏輯artifact cleanup依賴它計算產(chǎn)物保留時長。對應(yīng)的修復(fù)在 schema.go 中新增了sqlFixCompletedTimestamp語句L428-435UPDATE _vt.schema_migrations SET completed_timestampNOW(6) WHERE migration_status IN (cancelled, failed) AND cleanup_timestamp IS NULL AND completed_timestamp IS NULL即對于處于cancelled或failed狀態(tài)、尚未清理且完成時間缺失的遷移回填當前時間戳。這一補賬操作保證了清理調(diào)度器見下文在計算completed_timestamp NOW() - INTERVAL retain_artifacts_seconds時不會因為 NULL 時間戳而跳過或誤判歷史遷移從而避免取消/失敗遷移的產(chǎn)物永遠得不到回收。取消遷移產(chǎn)物清理與 --retain-artifacts 策略標志PR #14035 是另一項重量級修復(fù)清理被取消遷移的殘留產(chǎn)物并支持--retain-artifactsdurationDDL 策略標志。在 v15.0.5 之前遷移一旦被取消其創(chuàng)建的表如_vt_xxx_gho影子表、_vt_xxx_ghc變更日志表、_vt_xxx_del延遲刪除表等 artifacts可能因清理條件不滿足而長期滯留。修復(fù)后清理邏輯統(tǒng)一由sqlSelectUncollectedArtifacts驅(qū)動schema.go L414-427SELECT migration_uuid, artifacts, log_path FROM _vt.schema_migrations WHERE migration_status IN (complete, cancelled, failed) AND cleanup_timestamp IS NULL AND completed_timestamp IF(retain_artifacts_seconds0, NOW() - INTERVAL %a SECOND, NOW() - INTERVAL retain_artifacts_seconds SECOND ) ORDER BY id可見清理條件同時覆蓋complete、cancelled、failed三種終態(tài)且每個遷移的保留時長可獨立控制retain_artifacts_seconds0時回退到全局默認保留時長%a占位符否則按遷移自身的保留時長計算。--retain-artifacts策略標志的生效邏輯位于 executor.go L5471-5475retainArtifactsSeconds : int64(retainOnlineDDLTables.Seconds()) if retainArtifacts, _ : onlineDDL.StrategySetting().RetainArtifactsDuration(); retainArtifacts ! 0 { // Explicit retention indicated by --retain-artifact DDL strategy flag for this migration. Override! retainArtifactsSeconds int64(retainArtifacts.Seconds()) }即遷移級策略標志優(yōu)先于 vttablet 全局的retainOnlineDDLTables配置最終隨sqlInsertMigration一并寫入_vt.schema_migrations.retain_artifacts_seconds字段L5498。典型用法ALTER TABLE my_table DROP COLUMN c1, ALGORITHMghost, --retain-artifacts168h;這允許運維針對個別大表顯式延長或縮短影子表保留期例如調(diào)試期間想多留幾天影子表做比對而無需改動全局參數(shù)。修復(fù)改列名與列類型為 JSON 的 bugPR #14115 修復(fù)了將列名與列類型同時改為 JSON時的錯誤。這類 DDL 形如ALTER TABLE t CHANGE COLUMN old_col new_col JSON在 Online DDL 的 ghost/切表流程中涉及列映射column list推導(dǎo)與 vreplication 字段映射邊界場景處理不當會導(dǎo)致遷移失敗或數(shù)據(jù)錯位。該修復(fù)屬于 Online DDL 邊界條件正確性的收尾工作。Query Serving四處競態(tài)與代價模型修正schema tracker 遍歷表/視圖時的競態(tài)PR #13794 修復(fù)了 vttablet 端 schema tracker 在**遍歷表tables與視圖views**時存在的競態(tài)條件。schema tracker 維護內(nèi)存中的 schema 緩存供 vtgate 下發(fā)查詢計劃時引用。當后臺 refresh 線程在更新 schema 的同時查詢線程正在迭代表/視圖列表若無鎖保護會觸發(fā) data race進而可能導(dǎo)致計劃構(gòu)建讀到半更新狀態(tài)的 schema。該修復(fù)在迭代路徑上補齊了同步保護屬于典型的并發(fā)訪問正確性問題。模糊測試fuzzing發(fā)現(xiàn)的一批 bug 修復(fù)PR #13807 匯總了 vitess 團隊在持續(xù)模糊測試中發(fā)現(xiàn)的若干問題。Vitess 倉庫中維護了專門的 fuzzer可參見 go/mysql/mysql_fuzzer.goSQL 解析器、協(xié)議解析路徑是重點目標。這類修復(fù)通常涉及畸形 SQL 導(dǎo)致解析器 panic極端輸入導(dǎo)致內(nèi)存分配失控錯誤處理路徑中再次拋出異常掩蓋原始錯誤。建議升級用戶在發(fā)布說明之外重點關(guān)注 SQL 兼容性邊界因為模糊測試修復(fù)往往悄悄改變了某些邊緣語法的處理行為。join 引擎 OLAP 流式執(zhí)行的數(shù)據(jù)競態(tài)PR #14014 修復(fù)了join 引擎原語在 OLAP 流式streaming模式執(zhí)行時的數(shù)據(jù)競態(tài)。對應(yīng)代碼位于 go/vt/vtgate/engine/join.goTryStreamExecuteL123 起在流式執(zhí)行時引入了sync.MutexL125-127確保并發(fā)讀取 join 兩翼結(jié)果集時共享狀態(tài)的一致性。該修復(fù)對大規(guī)模聚合/Join 分析查詢OLAP 工作負載的穩(wěn)定性有直接價值——此前在高并發(fā)流式場景下可能出現(xiàn)計劃執(zhí)行器狀態(tài)被并發(fā)修改導(dǎo)致的非確定性結(jié)果或 panic。代價模型將 subshard opcode 納入 costPR #14025 修復(fù)了 vtgate 代價cost計算未包含 subshard opcode 的問題。在 v3 規(guī)劃器中路由 opcode如EqualUnique、IN、Subshard等決定查詢發(fā)往分片的方式。若代價計算遺漏Subshard這一 opcode規(guī)劃器可能高估或低估某些查詢的代價進而選擇次優(yōu)的執(zhí)行計劃例如錯誤地合并/拆分查詢、選擇錯誤的 route 方式。修復(fù)后代價估算更貼近真實執(zhí)行開銷有利于在跨分片場景下選出更合理的計劃。TabletManager半同步動作枚舉的全量覆蓋PR #13957 修復(fù)了convertBoolToSemiSyncAction方法未能覆蓋全部半同步動作的問題。該方法位于 go/vt/vttablet/tabletmanager/rpc_actions.go L194-214func (tm *TabletManager) convertBoolToSemiSyncAction(ctx context.Context, semiSync bool) (SemiSyncAction, error) { semiSyncExtensionLoaded, err : tm.MysqlDaemon.SemiSyncExtensionLoaded(ctx) if err ! nil { return SemiSyncActionNone, err } switch semiSyncExtensionLoaded { case mysql.SemiSyncTypeSource, mysql.SemiSyncTypeMaster: if semiSync { return SemiSyncActionSet, nil } else { return SemiSyncActionUnset, nil } default: if semiSync { return SemiSyncActionNone, vterrors.VT09013() } else { return SemiSyncActionNone, nil } } }半同步動作枚舉定義在同文件 L47-53SemiSyncActionNone、SemiSyncActionSet、SemiSyncActionUnset。修復(fù)前該方法在某些 MySQL/分支的半同步插件狀態(tài)SemiSyncType變體下無法正確映射出Set/Unset動作導(dǎo)致在主從切換PlannedReparentShard / EmergencyReparentShard或備份恢復(fù)流程中半同步配置無法按預(yù)期啟停。修復(fù)后當半同步插件以 source/master 類型加載時布爾值正確映射為SemiSyncActionSet或SemiSyncActionUnset其他情況下插件未加載或類型未知若請求開啟半同步則返回VT09013錯誤若請求關(guān)閉則安全返回None。該方法的調(diào)用點包括 rpc_actions.go 的ChangeType流程L129以及 rpc_backup.goL172備份結(jié)束恢復(fù)原類型時和 rpc_replication.goL313。對于依賴半同步保證數(shù)據(jù)不丟失的集群這一修復(fù)直接關(guān)系到切換與恢復(fù)流程中的復(fù)制安全。Cluster ManagementBackupShard 使用自身標志PR #13818 修復(fù)了BackupShard從**自身標志flags**而非外部默認值獲取選項的問題。BackupShard是 vtctld 暴露的 RPC請求結(jié)構(gòu)定義見 go/vt/proto/vtctldata/vtctldata.pb.go 的BackupShardRequest請求字段包括allow_primary、concurrency、upgrade_safe、incremental_from_pos、mysql_shutdown_timeout、init_sql等。修復(fù)前BackupShard在構(gòu)造備份請求時可能讀取了錯誤來源的參數(shù)例如 vtctld 進程級標志或默認值導(dǎo)致通過 RPC 觸發(fā)的備份與命令行觸發(fā)的備份行為不一致——例如并發(fā)度、是否允許主庫備份等選項未按調(diào)用方意圖生效。修復(fù)后每次BackupShard調(diào)用都嚴格以其請求參數(shù)為準保證vtctldclient BackupShard與內(nèi)部調(diào)用語義一致。CI/Build、工程化與發(fā)布流程改進v15.0.5 的工程化改進同樣值得關(guān)注靜態(tài)檢查覆蓋 changelog 目錄PR #14004Static Code Checks Etc現(xiàn)在會在./changelog目錄過期如未生成新版本變更記錄時讓 CI 失敗從流程上強制每個發(fā)布分支維護變更記錄這也是本文檔所在目錄能保持結(jié)構(gòu)一致的原因啟用 e2e 競態(tài)檢測失敗PR #14009tools/e2e_test_race.sh現(xiàn)在允許競態(tài)檢測失敗直接中斷 CI并修復(fù)了一批已知競態(tài)與本次多處 data race 修復(fù)形成呼應(yīng)升級測試 Go 版本到 go1.20.8PR #13938release-15.0 分支的升級測試環(huán)境更新至 Go 1.20.8vtorc 專用容器PR #14145docker 目錄新增專門的 vtorc 容器鏡像vtorcVitess 拓撲恢復(fù)控制器不再需要依賴通用鏡像手工組裝docgen 嵌入 commit IDPR #14072與homedir 匿名化PR #14104自動生成的文檔 frontmatter 中嵌入 commit ID并對文檔中的用戶主目錄路徑做匿名化處理提升文檔可追溯性與隱私性CI 穩(wěn)定性PR #14118、#14120在 reparent 測試 teardown 中刪除 VTDATAROOT 殘留文件以消除測試相互污染并在找到安全方案前移除 FOSSA 測試。升級建議與風(fēng)險提示Online DDL 語義變化需重點回歸--postpone-completion對即時操作CREATE/DROP 等生效范圍的擴大可能改變現(xiàn)有自動化流程對遷移何時完成的預(yù)期若你的流程依賴遷移完成時間點觸發(fā)后續(xù)動作升級后建議先在測試環(huán)境驗證 DROP/CREATE 類遷移的行為半同步修復(fù)直接影響切換安全convertBoolToSemiSyncAction的全量覆蓋意味著主從切換、備份恢復(fù)流程中半同步啟停行為更規(guī)范但若集群使用了非標準半同步插件加載方式需關(guān)注VT09013錯誤是否會因semiSynctrue請求而暴露產(chǎn)物清理策略可下放到遷移級借助--retain-artifactsduration可針對大表或?qū)徲嬓枨蟛町惢O(shè)置影子表保留時長同時取消/失敗遷移的產(chǎn)物將不再無限滯留查詢服務(wù)穩(wěn)定性提升join OLAP 流式執(zhí)行與 schema tracker 的競態(tài)修復(fù)對高并發(fā)分析查詢和 schema 頻繁變更的集群收益明顯。參考文件索引版本變更記錄changelog/15.0/15.0.5/changelog.mdOnline DDL 執(zhí)行器與策略語義go/vt/vttablet/onlineddl/executor.goOnline DDL 內(nèi)部表 SQL 與清理邏輯go/vt/vttablet/onlineddl/schema.go半同步動作映射修復(fù)go/vt/vttablet/tabletmanager/rpc_actions.go半同步在備份/復(fù)制流程中的調(diào)用go/vt/vttablet/tabletmanager/rpc_backup.go、go/vt/vttablet/tabletmanager/rpc_replication.gojoin 引擎流式執(zhí)行競態(tài)修復(fù)go/vt/vtgate/engine/join.goBackupShard RPC 請求定義go/vt/proto/vtctldata/vtctldata.pb.go【免費下載鏈接】vitessVitess is a database clustering system for horizontal scaling of MySQL.項目地址: https://gitcode.com/gh_mirrors/vi/vitess創(chuàng)作聲明：本文部分內(nèi)容由AI輔助生成（AIGC），僅供參考