Vitess v11.0.2 补丁发布解析Log4j 安全漏洞修复、VReplication 已知问题与生成列 Bug 修复【免费下载链接】vitessVitess is a database clustering system for horizontal scaling of MySQL.项目地址: https://gitcode.com/gh_mirrors/vi/vitess本篇文章基于 Vitess 官方发布说明 changelog/11.0/11.0.2/release_notes.md 整理而成。v11.0.2 是 v11 系列的一个补丁版本其核心使命是回应 2021 年底公开的 Apache Log4j 高危远程代码执行漏洞CVE-2021-44228同时携带若干 VReplication 与 CI 相关的修复。读完本文你将掌握该补丁版本的发布背景、每个变更项背后的源码实现依据、已知问题-force与-keep_data混淆的规避方法以及选择后续版本v11.0.4的明确理由。版本定位一个以安全响应为核心的补丁v11.0.2 属于 Vitess v11 系列的第二个补丁版本。从其 summary.md 与 release_notes.md 的 Announcement 可以明确看到该版本的发布动因该补丁提供了关于 Apache Log4j 安全漏洞CVE-2021-44228的更新#9364并附带少量 Bug 修复。整个版本只包含7 个提交不含合并提交共三位方向的工作类别内容关联 PRBug 修复 / VReplication修复 VReplication 识别 MySQL 生成列generated columns的方式#8796CI/BuildCI 中 ubuntu-latest 默认自带 MySQL 8.0.26覆盖为最新 8.0.x#9374内部清理 / Java将 /java 目录下 log4j-api 从 2.13.3 升级到 2.15.0#9364值得一提的是本版本发布说明明确列举了两个Known Issues已知问题其中 Log4j 漏洞被标记为严重critical并直接建议用户跳过本版本、改用 v11.0.4。这在 Vitess 的历史补丁中是相当罕见的做法说明该安全事件对版本规划产生了直接影响。Log4j 安全漏洞专项为什么建议直接使用 v11.0.4漏洞背景与时间线2021 年 12 月 9 日Apache Log4j 日志库被披露存在一个严重漏洞CVE-2021-44228即广泛传播的 Log4Shell该漏洞允许攻击者通过日志消息中的 JNDI 查找触发远程代码执行。Apache 随后发布 2.15.0 进行缓解但很快被发现初始补丁并不充分又接连出现两个后续 CVECVE-2021-45046针对 2.15.0 补丁不完整而披露的变体CVE-2021-44832另一个后续补充披露的漏洞。这三个漏洞最终在 Log4j2.17.1版本中被完整修复。发布说明明确指出v11.0.2 所使用的 Log4j 版本低于 2.17.1因此仍然暴露在上述漏洞的潜在影响之下。Vitess 的受影响面与修复动作Vitess 的 Java 客户端java/目录使用 Log4j API 作为日志门面。修复动作#9364将 java/client/pom.xml 中的依赖从 2.13.3 提升到 2.15.0dependency groupIdorg.apache.logging.log4j/groupId artifactIdlog4j-api/artifactId /dependency需要特别说明两点事实2.15.0 是当时 Apache 发布的首个缓解版本它只能缓解 CVE-2021-44228 的初始利用方式无法覆盖 CVE-2021-45046 与 CVE-2021-44832Vitess 主体是 Go 实现见 go/vt 下的服务端代码Go 标准库与第三方日志栈并不依赖 Log4jLog4j 仅存在于 Java 客户端java/client、java/jdbc、java/grpc-client 等模块中。因此在评估影响时应聚焦于使用 Java 客户端的应用链路。官方建议升级到 v11.0.4由于 v11.0.2 携带的 Log4j 版本不足以覆盖完整漏洞链官方在发布说明中明确表态本版本v11.0.2使用的 Log4j 版本低于 2.17.1因此我们鼓励你使用v11.0.4以受益于漏洞补丁。对于运维与安全团队而言这实际上是一个跳过补丁信号如果生产环境尚未升级应直接选取 v11.0.4 或更新版本而不是停留在 v11.0.2。已知问题 #9174-force与-keep_data参数混淆问题描述v11.0.2 发布说明披露了一个存在于 v2 VReplication workflow 中的已知问题#9174在执行某些 workflow 操作时代码错误地使用了-force标志的值而不是-keep_data标志的值。官方在 issue #9174 的描述中提供了 workaround。源码佐证两个标志在清理流程中的真实语义要理解该 Bug 的影响需要先厘清这两个标志的语义差异。在 vtctl 命令定义中go/vt/vtctl/vtctl.gokeep_data: 布尔标志默认 false 说明不删除表或分片若为 true则仅清理 vreplication 工件。--keep_data 仅支持 Complete 和 Cancel 操作。也就是说-keep_datatrue意味着用户希望保留源数据只清理 vreplication 相关的元数据工件-force则用于跳过workflow 必须已完成的前置校验。二者语义完全不同。在 VReplication 清理的核心实现 DropSources 中可以看到两者的独立职责func (wr *Wrangler) DropSources(ctx context.Context, targetKeyspace, workflowName string, removalType workflow.TableRemovalType, keepData, keepRoutingRules, force, dryRun bool) (*[]string, error) { ... if !force { if err : sw.validateWorkflowHasCompleted(ctx); err ! nil { // 未完成的 workflow 不允许 DropSources } } if !keepData { // 仅当 keepData 为 false 时才真正删除源表/源分片 switch ts.MigrationType() { case binlogdatapb.MigrationType_TABLES: sw.removeSourceTables(ctx, removalType) // 删除表 ... case binlogdatapb.MigrationType_SHARDS: sw.dropSourceShards(ctx) // 删除分片 } } ... }从代码结构可以清晰看到预期的行为契约forcefalse默认时必须先通过validateWorkflowHasCompleted校验防止对未完成切换的 workflow 做破坏性清理keepDatatrue时跳过removeSourceTables/dropSourceShards即保留源端数据与分片。而 #9174 所描述的缺陷正是某些调用路径把force的值误传给了keepData位置或反之导致用户设-keep_datatrue时源数据仍被删除、或设-force时意外触发数据保留等非预期行为。由于问题存在于 v2 workflow 的参数装配层规避方式是遵循 issue #9174 描述中的 workaround 调整命令参数并在后续补丁版本中确认该问题已修复后再恢复常规用法。给运维人员的实操建议在执行MoveTables/Reshard的 Complete/Cancel 阶段前先确认所用版本是否包含该参数传递缺陷在 v11.0.2 上若必须使用-keep_data请务必先在小规模 workflow 上验证源表是否真的被保留再推广到生产升级到修复该问题的新补丁版本是最稳妥的选择。Bug 修复 #8796VReplication 对 MySQL 生成列的识别问题本质MySQL 生成列generated column分为stored generated与virtual generated两种前者物理存储在表中后者不占用存储、在读取时计算。VReplication 在复制数据时需要正确识别哪些列是生成列从而在 INSERT 时跳过为生成列赋值避免写入冲突或数据不一致。修复#8796改进了 VReplication 识别 MySQL 生成列的方式。在复制计划构建阶段源码会在列信息colInfos中记录IsGenerated标记并在构造colExpr时将其透传go/vt/vttablet/tabletmanager/vreplication/replicator_plan.gofor _, colInfo : range tpb.colInfos { if !strings.EqualFold(colInfo.Name, field.Name) { continue } if colInfo.IsGenerated { generated true } break } cexpr : colExpr{ colName: colName, colType: field.Type, expr: sqlparser.ColName{Name: colName}, isGenerated: generated, }测试印证VReplication 的测试框架直接覆盖了两种生成列形态go/vt/vttablet/tabletmanager/vreplication/framework_test.goextra stored generated extra virtual generated这说明修复后的复制计划既能处理 stored generated 列也能处理 virtual generated 列且测试套件对两者都有明确断言。对于使用生成列的业务表进行在线迁移Online DDL / MoveTables的场景这一修复保证了复制流程不会在生成列上产生错误的写入。CI/Build 调整 #9374适配 ubuntu-latest 的 MySQL 8.0.26发布说明记录的 CI 改动为GitHub Actions 的ubuntu-latest镜像默认预装 MySQL 8.0.26CI 脚本显式覆盖为最新 8.0.x 版本。这一改动属于典型的**测试环境固定pinning**策略CI 基础设施的隐式变更镜像默认 MySQL 版本升级不应影响测试结果的可复现性。通过显式指定测试使用的 MySQL 版本可以避免本地通过、CI 失败这类因环境漂移导致的问题也保证了 v11 分支的端到端测试始终运行在明确声明的 MySQL 版本之上。对于关心 CI 稳定性的贡献者而言这提醒我们在 Vitess 这类重度依赖 MySQL 行为的项目中测试矩阵中的 MySQL 版本应当显式声明而非依赖运行环境的默认值。依赖升级 #9364Java 模块的 Log4j 版本提升除上述安全专项外内部清理工作将 Java 模块的log4j-api从 2.13.3 提升到 2.15.0。该依赖声明于 java/client/pom.xml并在 pom 的 dependencyManagement 中被下游的jdbc模块复用运行时同样依赖log4j-api见 java/client/pom.xml。结合前面 Log4j 安全漏洞的分析可以得出结论#9364 是 Vitess 对 Log4Shell 的首次依赖升级响应它完成了消除初始漏洞利用路径的目标但并未覆盖完整漏洞链因此官方仍建议最终迁移到包含更完整补丁的 v11.0.4。发布规模与致谢本版本共包含7 个提交不含合并提交致谢贡献者askdba、deepthi、systay、tokikanno。从提交规模7 个与变更范围安全依赖升级 一个 VReplication 修复 一个 CI 固定 一个 Java 依赖清理可以看出v11.0.2 是一个目标明确、范围收敛的小补丁其首要价值在于及时回应 Log4Shell 安全事件次要价值在于 VReplication 生成列识别的正确性修复。总结与升级路径建议综合官方发布说明与仓库源码对 v11.0.2 可给出如下结论安全优先级Log4j 漏洞是此版本发布的直接动因但 v11.0.2 携带的 Log4j2.15.0只能缓解初始漏洞无法覆盖 CVE-2021-45046 与 CVE-2021-44832因此建议直接使用 v11.0.4已知缺陷v2 VReplication workflow 存在-force/-keep_data参数混淆问题#9174涉及破坏性清理语义使用前需查阅 issue 中的 workaround功能修复VReplication 对 MySQL stored/virtual generated 列的识别已修正并有对应测试用例验证CI 治理测试环境显式固定 MySQL 8.0.x保证测试可复现性影响范围Log4j 依赖仅存在于 Java 客户端模块Go 服务端vtgate/vttablet 等不受其直接影响但完整评估仍需结合自身 Java 客户端的使用情况。对于正在规划 Vitess 升级的团队建议以安全与稳定性为准绳将 v11.0.4或更新补丁作为目标版本同时结合 changelog 目录下各版本发布说明核对变更项制定分环境的灰度升级方案。【免费下载链接】vitessVitess is a database clustering system for horizontal scaling of MySQL.项目地址: https://gitcode.com/gh_mirrors/vi/vitess创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考