Vitess v13.0.2 版本变更详解查询引擎、复制修复与 Go 安全升级全解析【免费下载链接】vitessVitess is a database clustering system for horizontal scaling of MySQL.项目地址: https://gitcode.com/gh_mirrors/vi/vitessVitess v13.0.2 是 13.0 系列发布的第二个补丁版本Patch Release主要聚焦于查询服务Query Serving的正确性修复、VReplication 稳定性改进、构建与 CI 流程加固以及将 Go 工具链升级至go1.17.12以引入关键安全修复。本文以 changelog/13.0/13.0.2/changelog.md 为骨架逐条解读该版本的全部变更并结合当前仓库源码说明每条修复的底层机制与影响面帮助你在升级或排查 13.0 系列问题时快速定位。一、版本定位与发布背景v13.0.2 属于 Vitess 13.0 主线release-13.0的补丁版本。根据同目录下的 release_notes.md 与 summary.md该版本共包含28 个提交不含合并提交变更按类别分布在 Bug fixes、CI/Build、Regression、Release、Testing 五大板块。该版本的一个核心动机是Go 工具链升级Vitessv13.0.2现在运行在go1.17.12上。Go 补丁版本go1.17.12是该版本发布的主要动因之一因为它包含对 Vitess 所使用包的重要安全修复。go1.17.12发布于 2022-07-12的安全修复覆盖compress/gzip、encoding/gob、encoding/xml、go/parser、io/fs、net/http、path/filepath等标准库包并包含编译器、go 命令、runtime 及runtime/metrics的缺陷修复。对于运行 13.0 系列的集群这是值得重视的升级理由。注意本文分析依据当前仓库快照go.mod中的工具链版本已演进到更高版本文中描述的go1.17.12是 v13.0.2 发布时的工具链版本升级到该版本时请以你实际部署的 13.0.2 分支构建环境为准。二、Query Serving查询引擎核心修复Bug fixes 主战场v13.0.2 的绝大多数 Bug 修复集中在查询服务Query Serving这也是 Vitess 负责 SQL 解析、规划与执行的核心链路。以下逐条解读。2.1 复制等待与 ERSWaitForPosition 行为修正涉及两个密切相关的修复Backport仅在需要时临时启动 SQL 线程来执行 WaitForPosition对应 PR #10123不要在 WaitSourcePos 中变更复制状态并在 ERS 中忽略 SQL 线程已停止的 tablet对应 PR #10148理解这条修复需要先看懂底层调用链。在 rpc_replication.go 中WaitForPosition的实现是// WaitForPosition waits until replication reaches the desired position func (tm *TabletManager) WaitForPosition(ctx context.Context, pos string) error { log.Info(fmt.Sprintf(WaitForPosition: %v, pos)) if err : tm.waitForGrantsToHaveApplied(ctx); err ! nil { return err } mpos, err : replication.DecodePosition(pos) if err ! nil { return err } return tm.MysqlDaemon.WaitSourcePos(ctx, mpos) }其本质是解析复制位点后委托MysqlDaemon.WaitSourcePos等待从库追赶到指定位置。修复前的行为存在两个问题调用WaitSourcePos可能会改动复制状态例如擅自启动/停止 SQL 线程这在等待位点的场景下是不必要的副作用在 Emergency Reparent ShardERS紧急重新选主流程中如果某个 tablet 的 SQL 线程已停止它实际上无法继续追赶位点应当被忽略而不是阻塞或干扰整个选主决策。从当前仓库看ERS 相关逻辑位于 go/vt/vtctl/reparentutil/ 包下如emergency_reparenter_test.go、replication.go其中WaitForPosition与WaitSourcePos的使用贯穿计划内/紧急 reparent 的位点等待逻辑。这条修复的实际价值是让 ERS 在评估各候选新主的数据追平程度时不因 SQL 线程停止的 tablet 而产生误判或等待。2.2 空结果修复无可用分片路由时不再返回空结果修复当找不到任何分片可以路由时返回空结果的问题PR #10187同一修复在 R13、v3 规划器上的 backportPR #10202这个 Bug 发生在v3 规划器v3 planner的查询路由阶段。当一条查询经过分片键vindex解析后无法匹配到任何目标分片时旧行为可能错误地返回空结果集——这在语义上可能掩盖真正的错误例如 vindex 查询异常、路由条件错误等。修复后无分片可路由的场景会走正确的错误处理路径而不是静默返回空结果。从当前仓库源码结构可以推断v3 规划器的路由逻辑位于 planbuilder/v313.0 分支上的对应位置它与后续版本中基于--planner-version切换的 v4/gen4 规划器共同构成 Vitess 的 SQL 规划体系。该修复在 R13 分支上同时以v3为目标做了 backport确保两种规划路径行为一致。2.3 计划缓存Plan Cache的两项修复plancache懒加载 sysvar 规划器函数PR #10248不要缓存因--no_scatter而无效的计划PR #10283Vitess 的 vtgate 会缓存执行计划以降低解析开销。但计划缓存有两条边界需要处理sysvar 相关计划某些系统变量会影响执行计划形态。旧实现可能在初始化时就求值 sysvar 规划函数导致缓存计划与实际会话的 sysvar 设置脱节。修复改为懒加载lazy即在真正需要时才对 sysvar 相关函数求值保证缓存计划在会话变量变化下依然正确。--no_scatter与计划缓存冲突--no_scatter是 vtgate 的一个保护性参数用于禁止会扩散到所有分片的查询scatter 查询。如果某个查询因--no_scatter被判为非法那么不能把这个非法结论缓存下来供其他会话复用——因为其他连接可能并没有启用该限制。修复后这类计划不会被写入缓存。仓库中可看到对应行为的测试佐证delete_test.go 中的TestDeleteEqualNoScatter以及 executor_scatter_stats_test.go 中的TestScatterStatsWithNoScatterQuery后者验证了带no_scatter查询的统计行为。2.4 Concatenate 引擎原语的 BackportBackport R13concatenate 引擎原语PR #10343Concatenate是 vtgate 引擎engine中的一种执行原语Primitive用于将多个来源如不同分片或 UNION 分支的结果拼接后返回。当前仓库中的实现位于 concatenate.go// Concatenate specified the parameter for concatenate primitive type Concatenate struct { Sources []Primitive // These column offsets do not need to be typed checked - they usually contain weight_string() // columns that are not going to be returned to the user NoNeedToTypeCheck map[int]any }从源码看Concatenate的关键设计是结果字段类型协调type coercion多个来源的同一列类型可能不完全一致例如weight_string()有时返回 VARBINARY、有时返回 VARCHAR因此它通过NoNeedToTypeCheck跳过这些列的强类型检查并对其余列做类型聚合与强制转换coerceValuesTo。执行策略上事务内采用顺序执行sequentialExec非事务场景下采用并行执行parallelExec以提升吞吐。13.0.2 将当时较新的 Concatenate 原语 backport 到 release-13.0 分支使旧分支的 UNION/拼接类查询也能受益于该实现的类型处理与并发能力。2.5 Join 谓词下推的谓词保留修复BugFix向 Join 推入新谓词时保留既有谓词PR #10715在计划阶段规划器会尝试将外层谓词下推到 Join 的各个输入上以减少扫描数据量。此前的缺陷是当向 Join 推入新谓词时可能覆盖或丢失原本已经下推/存在的谓词导致计划错误或结果集不准确。修复后Join 在接收新谓词时会保留原有谓词。Join 引擎原语定义在 join.go该文件同时定义了 JoinOpcode 枚举join.go用于区分不同的 Join 执行形态是 vtgate 执行层最核心的原语之一。三、VReplicationVStream API 内存泄漏修复VStream API修复 context 被取消时 vtgate 的内存泄漏PR #10571VStream API 是 Vitess 面向 CDC变更数据捕获场景提供的流式复制接口。当客户端取消订阅context 被 cancel时如果 vtgate 侧的流式 goroutine 没有正确收尾订阅相关的资源通道、缓冲、goroutine 栈会持续残留造成内存泄漏。该修复确保 context 取消时 vtgate 端能完整释放 VStream 相关资源。对于长时间运行多个 VStream 订阅的 CDC 消费者这是影响长期稳定性的关键修复。四、vtexplainKeyspace 加载校验修复在使用 keyspace 前检查其是否全部加载成功PR #10396vtexplain是一个离线 SQL 规划器详见 cmd/vtexplain用于在不启动真实集群的情况下解释查询会如何路由。此前如果某个 keyspace 的 vschema 加载失败vtexplain 可能仍继续使用部分加载的数据产生误导性的解释结果。修复后在继续执行前显式校验所有 keyspace 均加载成功否则直接报错保证解释结果的可靠性。五、CI/Build 与发布流程加固v13.0.2 在构建与 CI 方面有一批工程性改进对维护者与发布流程有直接价值变更说明使用双中括号使 go 版本检查更可靠PR #10126修复了 CI 脚本中[ ... ]单中括号在特定 shell 环境下判断 go 版本不可靠的问题修复 release notes 的 CI 检查辅助脚本PR #10574完善发布说明的自动化校验修复 release-13.0 分支的 upgrade-downgrade 构建PR #10503保证跨版本升级/降级测试链路的可构建性在 upgrade-downgrade 测试中考虑github.refPR #10504使升级/降级测试针对不同分支引用选择正确的基线版本移除 review checklist 工作流PR #10656简化仓库的 GitHub Actions 工作流升级到go1.17.11PR #10461→ 再升级到go1.17.12PR #10707工具链安全升级是发布主因更新 review checklist 注释加入 CI 工作流检查项PR #10471Governance 层面的流程说明改进重新设计 release notes 标签的 CI 处理方式PR #10508规范发布说明的标签管理重新设计 release notes 的生成方式PR #10510自动化生成发布说明与 changelog/tooling 中沉淀的发布工具链对应六、回归修复与测试稳定性6.1 部分 DML 执行逻辑增强[13.0] 部分 DML 执行逻辑增强PR #10284归类为 Regression / Query Serving所谓部分 DMLpartial DML指的是 DMLINSERT/UPDATE/DELETE在多分片场景下只部分成功的情形。当跨分片更新在某一分片失败时需要明确的语义来处理已成功部分。13.0.2 对这一逻辑做了增强避免部分成功时产生不一致或错误的返回。相关引擎原语实现可参考 delete.go 与 insert.go 中关于多分片 DML 的执行编排。6.2 测试稳定性修复Flaky 测试修复TestFoundRowsPR #10222——FoundRows语义SQL_CALC_FOUND_ROWS/FOUND_ROWS()相关单元测试在特定并发下不稳定予以修复单元测试修复 mysql 测试在 MacOS 上运行的问题PR #10613——平台兼容性修复修复 vtctld2 web 测试的 flaky 问题PR #10541归类 web UI——旧版 vtctld2 界面的前端测试稳定性修复这些修复本身不改变运行时行为但确保了 13.0 分支的 CI 信号可靠避免因偶发失败掩盖真实回归。七、升级建议与小结综合 changelog/13.0/13.0.2/changelog.md 与配套的 summary.md、release_notes.mdv13.0.2 的升级要点可归纳为安全优先go1.17.12携带 7 个标准库安全修复涉及net/http、encoding/xml、compress/gzip等 Vitess 直接依赖的包建议尽快升级复制与高可用ERS/WaitForPosition 行为修正使紧急重选主流程对 SQL 线程停止的 tablet 更鲁棒使用 ERS 做日常运维的集群应优先关注查询正确性无分片路由空结果、Join 谓词丢失、sysvar 计划缓存、--no_scatter计划缓存等修复覆盖了 v3 规划器与计划缓存的多条已知边界涉及 UNION/Join/scatter 查询的集群升级后可观察相关行为修正运维与流式复制VStream API 的内存泄漏修复对长期运行 CDC 订阅的场景价值明显vtexplain 的 keyspace 校验提升离线解释的可靠性工程链路release notes 生成与 CI 标签流程的重构PR #10508、#10510与 changelog/tooling 中的发布工具链一脉相承标志着发布流程走向自动化。如需对照 13.0 系列其他补丁版本可查阅 changelog/13.0/README.md 中的版本索引13.0.0 至 13.0.3。对于运行 13.0 分支的生产集群建议在测试环境先行验证本清单中与 Query Serving 相关的修复尤其涉及计划缓存与 Join 谓词的行为变化再滚动升级。【免费下载链接】vitessVitess is a database clustering system for horizontal scaling of MySQL.项目地址: https://gitcode.com/gh_mirrors/vi/vitess创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Vitess v13.0.2 版本变更详解：查询引擎、复制修复与 Go 安全升级全解析
Vitess v13.0.2 版本变更详解查询引擎、复制修复与 Go 安全升级全解析【免费下载链接】vitessVitess is a database clustering system for horizontal scaling of MySQL.项目地址: https://gitcode.com/gh_mirrors/vi/vitessVitess v13.0.2 是 13.0 系列发布的第二个补丁版本Patch Release主要聚焦于查询服务Query Serving的正确性修复、VReplication 稳定性改进、构建与 CI 流程加固以及将 Go 工具链升级至go1.17.12以引入关键安全修复。本文以 changelog/13.0/13.0.2/changelog.md 为骨架逐条解读该版本的全部变更并结合当前仓库源码说明每条修复的底层机制与影响面帮助你在升级或排查 13.0 系列问题时快速定位。一、版本定位与发布背景v13.0.2 属于 Vitess 13.0 主线release-13.0的补丁版本。根据同目录下的 release_notes.md 与 summary.md该版本共包含28 个提交不含合并提交变更按类别分布在 Bug fixes、CI/Build、Regression、Release、Testing 五大板块。该版本的一个核心动机是Go 工具链升级Vitessv13.0.2现在运行在go1.17.12上。Go 补丁版本go1.17.12是该版本发布的主要动因之一因为它包含对 Vitess 所使用包的重要安全修复。go1.17.12发布于 2022-07-12的安全修复覆盖compress/gzip、encoding/gob、encoding/xml、go/parser、io/fs、net/http、path/filepath等标准库包并包含编译器、go 命令、runtime 及runtime/metrics的缺陷修复。对于运行 13.0 系列的集群这是值得重视的升级理由。注意本文分析依据当前仓库快照go.mod中的工具链版本已演进到更高版本文中描述的go1.17.12是 v13.0.2 发布时的工具链版本升级到该版本时请以你实际部署的 13.0.2 分支构建环境为准。二、Query Serving查询引擎核心修复Bug fixes 主战场v13.0.2 的绝大多数 Bug 修复集中在查询服务Query Serving这也是 Vitess 负责 SQL 解析、规划与执行的核心链路。以下逐条解读。2.1 复制等待与 ERSWaitForPosition 行为修正涉及两个密切相关的修复Backport仅在需要时临时启动 SQL 线程来执行 WaitForPosition对应 PR #10123不要在 WaitSourcePos 中变更复制状态并在 ERS 中忽略 SQL 线程已停止的 tablet对应 PR #10148理解这条修复需要先看懂底层调用链。在 rpc_replication.go 中WaitForPosition的实现是// WaitForPosition waits until replication reaches the desired position func (tm *TabletManager) WaitForPosition(ctx context.Context, pos string) error { log.Info(fmt.Sprintf(WaitForPosition: %v, pos)) if err : tm.waitForGrantsToHaveApplied(ctx); err ! nil { return err } mpos, err : replication.DecodePosition(pos) if err ! nil { return err } return tm.MysqlDaemon.WaitSourcePos(ctx, mpos) }其本质是解析复制位点后委托MysqlDaemon.WaitSourcePos等待从库追赶到指定位置。修复前的行为存在两个问题调用WaitSourcePos可能会改动复制状态例如擅自启动/停止 SQL 线程这在等待位点的场景下是不必要的副作用在 Emergency Reparent ShardERS紧急重新选主流程中如果某个 tablet 的 SQL 线程已停止它实际上无法继续追赶位点应当被忽略而不是阻塞或干扰整个选主决策。从当前仓库看ERS 相关逻辑位于 go/vt/vtctl/reparentutil/ 包下如emergency_reparenter_test.go、replication.go其中WaitForPosition与WaitSourcePos的使用贯穿计划内/紧急 reparent 的位点等待逻辑。这条修复的实际价值是让 ERS 在评估各候选新主的数据追平程度时不因 SQL 线程停止的 tablet 而产生误判或等待。2.2 空结果修复无可用分片路由时不再返回空结果修复当找不到任何分片可以路由时返回空结果的问题PR #10187同一修复在 R13、v3 规划器上的 backportPR #10202这个 Bug 发生在v3 规划器v3 planner的查询路由阶段。当一条查询经过分片键vindex解析后无法匹配到任何目标分片时旧行为可能错误地返回空结果集——这在语义上可能掩盖真正的错误例如 vindex 查询异常、路由条件错误等。修复后无分片可路由的场景会走正确的错误处理路径而不是静默返回空结果。从当前仓库源码结构可以推断v3 规划器的路由逻辑位于 planbuilder/v313.0 分支上的对应位置它与后续版本中基于--planner-version切换的 v4/gen4 规划器共同构成 Vitess 的 SQL 规划体系。该修复在 R13 分支上同时以v3为目标做了 backport确保两种规划路径行为一致。2.3 计划缓存Plan Cache的两项修复plancache懒加载 sysvar 规划器函数PR #10248不要缓存因--no_scatter而无效的计划PR #10283Vitess 的 vtgate 会缓存执行计划以降低解析开销。但计划缓存有两条边界需要处理sysvar 相关计划某些系统变量会影响执行计划形态。旧实现可能在初始化时就求值 sysvar 规划函数导致缓存计划与实际会话的 sysvar 设置脱节。修复改为懒加载lazy即在真正需要时才对 sysvar 相关函数求值保证缓存计划在会话变量变化下依然正确。--no_scatter与计划缓存冲突--no_scatter是 vtgate 的一个保护性参数用于禁止会扩散到所有分片的查询scatter 查询。如果某个查询因--no_scatter被判为非法那么不能把这个非法结论缓存下来供其他会话复用——因为其他连接可能并没有启用该限制。修复后这类计划不会被写入缓存。仓库中可看到对应行为的测试佐证delete_test.go 中的TestDeleteEqualNoScatter以及 executor_scatter_stats_test.go 中的TestScatterStatsWithNoScatterQuery后者验证了带no_scatter查询的统计行为。2.4 Concatenate 引擎原语的 BackportBackport R13concatenate 引擎原语PR #10343Concatenate是 vtgate 引擎engine中的一种执行原语Primitive用于将多个来源如不同分片或 UNION 分支的结果拼接后返回。当前仓库中的实现位于 concatenate.go// Concatenate specified the parameter for concatenate primitive type Concatenate struct { Sources []Primitive // These column offsets do not need to be typed checked - they usually contain weight_string() // columns that are not going to be returned to the user NoNeedToTypeCheck map[int]any }从源码看Concatenate的关键设计是结果字段类型协调type coercion多个来源的同一列类型可能不完全一致例如weight_string()有时返回 VARBINARY、有时返回 VARCHAR因此它通过NoNeedToTypeCheck跳过这些列的强类型检查并对其余列做类型聚合与强制转换coerceValuesTo。执行策略上事务内采用顺序执行sequentialExec非事务场景下采用并行执行parallelExec以提升吞吐。13.0.2 将当时较新的 Concatenate 原语 backport 到 release-13.0 分支使旧分支的 UNION/拼接类查询也能受益于该实现的类型处理与并发能力。2.5 Join 谓词下推的谓词保留修复BugFix向 Join 推入新谓词时保留既有谓词PR #10715在计划阶段规划器会尝试将外层谓词下推到 Join 的各个输入上以减少扫描数据量。此前的缺陷是当向 Join 推入新谓词时可能覆盖或丢失原本已经下推/存在的谓词导致计划错误或结果集不准确。修复后Join 在接收新谓词时会保留原有谓词。Join 引擎原语定义在 join.go该文件同时定义了 JoinOpcode 枚举join.go用于区分不同的 Join 执行形态是 vtgate 执行层最核心的原语之一。三、VReplicationVStream API 内存泄漏修复VStream API修复 context 被取消时 vtgate 的内存泄漏PR #10571VStream API 是 Vitess 面向 CDC变更数据捕获场景提供的流式复制接口。当客户端取消订阅context 被 cancel时如果 vtgate 侧的流式 goroutine 没有正确收尾订阅相关的资源通道、缓冲、goroutine 栈会持续残留造成内存泄漏。该修复确保 context 取消时 vtgate 端能完整释放 VStream 相关资源。对于长时间运行多个 VStream 订阅的 CDC 消费者这是影响长期稳定性的关键修复。四、vtexplainKeyspace 加载校验修复在使用 keyspace 前检查其是否全部加载成功PR #10396vtexplain是一个离线 SQL 规划器详见 cmd/vtexplain用于在不启动真实集群的情况下解释查询会如何路由。此前如果某个 keyspace 的 vschema 加载失败vtexplain 可能仍继续使用部分加载的数据产生误导性的解释结果。修复后在继续执行前显式校验所有 keyspace 均加载成功否则直接报错保证解释结果的可靠性。五、CI/Build 与发布流程加固v13.0.2 在构建与 CI 方面有一批工程性改进对维护者与发布流程有直接价值变更说明使用双中括号使 go 版本检查更可靠PR #10126修复了 CI 脚本中[ ... ]单中括号在特定 shell 环境下判断 go 版本不可靠的问题修复 release notes 的 CI 检查辅助脚本PR #10574完善发布说明的自动化校验修复 release-13.0 分支的 upgrade-downgrade 构建PR #10503保证跨版本升级/降级测试链路的可构建性在 upgrade-downgrade 测试中考虑github.refPR #10504使升级/降级测试针对不同分支引用选择正确的基线版本移除 review checklist 工作流PR #10656简化仓库的 GitHub Actions 工作流升级到go1.17.11PR #10461→ 再升级到go1.17.12PR #10707工具链安全升级是发布主因更新 review checklist 注释加入 CI 工作流检查项PR #10471Governance 层面的流程说明改进重新设计 release notes 标签的 CI 处理方式PR #10508规范发布说明的标签管理重新设计 release notes 的生成方式PR #10510自动化生成发布说明与 changelog/tooling 中沉淀的发布工具链对应六、回归修复与测试稳定性6.1 部分 DML 执行逻辑增强[13.0] 部分 DML 执行逻辑增强PR #10284归类为 Regression / Query Serving所谓部分 DMLpartial DML指的是 DMLINSERT/UPDATE/DELETE在多分片场景下只部分成功的情形。当跨分片更新在某一分片失败时需要明确的语义来处理已成功部分。13.0.2 对这一逻辑做了增强避免部分成功时产生不一致或错误的返回。相关引擎原语实现可参考 delete.go 与 insert.go 中关于多分片 DML 的执行编排。6.2 测试稳定性修复Flaky 测试修复TestFoundRowsPR #10222——FoundRows语义SQL_CALC_FOUND_ROWS/FOUND_ROWS()相关单元测试在特定并发下不稳定予以修复单元测试修复 mysql 测试在 MacOS 上运行的问题PR #10613——平台兼容性修复修复 vtctld2 web 测试的 flaky 问题PR #10541归类 web UI——旧版 vtctld2 界面的前端测试稳定性修复这些修复本身不改变运行时行为但确保了 13.0 分支的 CI 信号可靠避免因偶发失败掩盖真实回归。七、升级建议与小结综合 changelog/13.0/13.0.2/changelog.md 与配套的 summary.md、release_notes.mdv13.0.2 的升级要点可归纳为安全优先go1.17.12携带 7 个标准库安全修复涉及net/http、encoding/xml、compress/gzip等 Vitess 直接依赖的包建议尽快升级复制与高可用ERS/WaitForPosition 行为修正使紧急重选主流程对 SQL 线程停止的 tablet 更鲁棒使用 ERS 做日常运维的集群应优先关注查询正确性无分片路由空结果、Join 谓词丢失、sysvar 计划缓存、--no_scatter计划缓存等修复覆盖了 v3 规划器与计划缓存的多条已知边界涉及 UNION/Join/scatter 查询的集群升级后可观察相关行为修正运维与流式复制VStream API 的内存泄漏修复对长期运行 CDC 订阅的场景价值明显vtexplain 的 keyspace 校验提升离线解释的可靠性工程链路release notes 生成与 CI 标签流程的重构PR #10508、#10510与 changelog/tooling 中的发布工具链一脉相承标志着发布流程走向自动化。如需对照 13.0 系列其他补丁版本可查阅 changelog/13.0/README.md 中的版本索引13.0.0 至 13.0.3。对于运行 13.0 分支的生产集群建议在测试环境先行验证本清单中与 Query Serving 相关的修复尤其涉及计划缓存与 Join 谓词的行为变化再滚动升级。【免费下载链接】vitessVitess is a database clustering system for horizontal scaling of MySQL.项目地址: https://gitcode.com/gh_mirrors/vi/vitess创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考