Vitess v10.0.2 补丁版本发布解读Log4j 漏洞风险、VReplication 二进制列填充修复与 gRPC 可选 TLS 增强【免费下载链接】vitessVitess is a database clustering system for horizontal scaling of MySQL.项目地址: https://gitcode.com/gh_mirrors/vi/vitess本文围绕 Vitess 项目v10.0.2补丁版本的 发布说明 展开系统梳理该版本携带的已知问题特别是 Apache Log4j 高危漏洞影响面与规避建议、Query Serving 与 VReplication 的缺陷修复、构建与文档层面的改动并结合仓库源码与测试用例还原每项变更的底层实现。读完本文你将清楚判断v10.0.2是否适合引入生产环境、如何规避其已知问题以及后续版本v10.0.5在哪些方面做了补救。版本定位与背景v10.0.2是 Vitess 10.0 系列的第二个补丁版本patch release紧随v10.0.1之后发布。从 changelog/10.0/README.md 可以看到10.0 系列共包含10.0.0至10.0.5六个版本其中v10.0.0为包含大量新功能的主版本如 Gen4 查询规划器、VTAdmin 实验性 API、Online DDL 相关能力等而v10.0.1v10.0.5均为面向稳定性与安全性的补丁版本。v10.0.2全版本共包含14 个提交不含 merge 提交贡献者包括 GuptaManan100、askdba、deepthi、harshit-gangal、noxiouz、rohit-nayak-ps、systay 等。从变更构成看本版本的核心工作集中在三件事安全风险告知官方在发布说明中明确提示 Log4j 漏洞影响并建议用户优先升级到v10.0.5已知问题公示VReplication v2 workflow 中-force与-keep_data标志取值混淆的问题#9174在 10.0 系列持续存在针对性缺陷修复SQL 字符串编码、information_schema 查询、索引提示语法以及 VReplication 对binary()列的值填充。Known Issues升级前必须评估的两个问题发布说明的第一部分即为 Known Issues这是v10.0.2使用者最需要关注的段落。Apache Log4j 高危漏洞CVE-2021-44228 及后续 CVE2021 年 12 月 9 日Apache Log4j 日志库中被披露了严重漏洞 CVE-2021-44228即 Log4Shell。官方在2.15.0版本中提供了缓解补丁但随后发现该补丁并不充分又相继出现了 CVE-2021-45046 与 CVE-2021-44832 两个后续漏洞直至2.17.1版本才被完整修复。关键事实v10.0.2中 Java 客户端组件使用的 Log4j 版本低于2.17.1因此同样处于受影响范围。Vitess 官方的建议非常明确——不要长期停留在v10.0.2而应升级到v10.0.5。这一点可以从 10.0.5 发布说明 得到印证v10.0.5的唯一核心变更就是通过 Dependabot 将java/目录下的log4j-api从2.16.0升级到2.17.1对应 PR #9463。需要说明的是Log4j 仅存在于 Vitess 的Java 客户端/驱动组件位于仓库java/目录包括 client、grpc-client、jdbc 等模块中Go 服务端组件vtgate、vttablet、vtctld 等并不依赖该库。但对于使用 Java 客户端连接 Vitess 集群的用户而言该风险是真实存在的。VReplication v2 的-force/-keep_data标志混淆#9174第二个已知问题是 VReplication v2 workflow 中-force标志的值被错误地用于取代-keep_data标志的值。该问题同样存在于 10.0 系列的多个版本中v10.0.0、v10.0.1、v10.0.2的发布说明均列明了此问题。从发布说明可以看到官方并未在本版本中给出完整修复而是指出可在 issue #9174 的描述中找到 workaround。这提示使用者如果在 10.0 系列上执行涉及-keep_data的 VReplication 操作如MoveTables、Reshard的清理阶段必须仔细核对实际生效的标志语义避免因标志值错位导致数据保留策略与预期不符。Bug fixes本版本的缺陷修复清单v10.0.2的修复集中在两个功能域Query Serving查询服务与VReplication。Query Serving本版本包含三项查询服务的修复1. SQL 字符串编码修复#8029修复了 SQL 语句中字符串的编码问题。涉及字符串字面量的正确转义与编码输出属于go/vt/sqlparser语法解析与格式化层的能力范畴——从源码结构看Vitess 的 SQL 解析器在将 AST抽象语法树重新格式化为 SQL 文本时需要精确处理字符串中的特殊字符任何编码偏差都会导致发送到 MySQL 的语句与原始语义不一致。2. information_schema 查询修复同时带有表名与库名谓词#8099修复了 information_schema 查询在同时包含table_name与table_schemaschema name两个谓词时的计划生成问题。information_schema 查询是 VTGate 中一类特殊查询需要经过专门的合并路由merge route与谓词推导处理。仓库中的相关测试给出了这类查询的典型形态例如 go/vt/vtgate/executor_select_test.go 中的用例SELECT COUNT(*) FROM INFORMATION_SCHEMA.TABLES ist WHERE ist.table_schema performance_schema AND ist.table_name foo同时go/vt/vtgate/planbuilder/select.go 的注释表明当 information_schema 查询中未同时找到table_schema与table_name时规划器会尝试通过 CNF 重写Conjunctive Normal Form rewriting来推进查询分解。该修复确保两个谓词同时出现时查询能被正确路由到对应分片并返回准确结果。3. 索引提示列表中支持 PRIMARY#8159修复了索引提示index hint列表中PRIMARY关键字的处理使USE INDEX (PRIMARY)/FORCE INDEX (PRIMARY)这类语法在 10.0 系列中能被正确解析与传递。该修复回填了索引提示语法与 MySQL 行为之间的兼容性差距。VReplication为 binary() 列填充 binlog 值#8137这是本版本中唯一一项 VReplication 修复也是实现细节最清晰的一项VReplication: Pad binlog values for binary() columns to match the value returned by mysql selects #8137问题本质MySQL 的BINARY(n)是定长二进制类型存储时值会被填充到固定长度用\0字节补齐然而 binlog 事件中记录的该列值却是未填充的原始长度。这导致 VReplication通过 binlog 流式复制变更在目标端写出的值与通过SELECT读取到并写入的值不一致从而可能引发数据差异甚至主键冲突尤其是当binary()列作为主键或唯一键时。修复方式vstreamer 在从 binlog 生成行事件时对binary()类型的列进行显式填充使其与 MySQLSELECT返回的值对齐。仓库中保留了这个修复的回归测试TestCellValuePadding位于 go/vt/vttablet/tabletserver/vstreamer/vstreamer_test.go// TestCellValuePadding tests that the events are correctly padded for binary columns. func TestCellValuePadding(t *testing.T) { ts : TestSpec{ t: t, ddls: []string{ create table t1(id int, val binary(4), primary key(val)), create table t2(id int, val char(4), primary key(val)), create table t3(id int, val char(4) collate utf8mb4_bin, primary key(val)), }, } // ... {insert into t1 values (1, aaa\000), nil}, {insert into t1 values (2, bbb\000), nil}, {update t1 set id 11 where val aaa\000, []TestRowEvent{ {spec: TestRowEventSpec{table: t1, changes: []TestRowChange{ {before: []string{1, aaa\x00}, after: []string{11, aaa\x00}}, }}}, }}, // ... }测试同时覆盖了binary(4)、char(4)以及char(4) collate utf8mb4_bin三类列验证填充逻辑在 update 事件的 before/after 两个快照上都生效。值得留意的是v10.0.0的已知问题中曾列出 VReplication errors when a fixed-length binary column is used as the sharding key #8080而#8137正是对这类 fixed-length binary 列场景的进一步收敛——从源码结构看该修复与 vstreamer 行事件构造链路go/vt/vttablet/tabletserver/vstreamer/目录紧密相关。EnhancementgRPC 服务器可选 TLS 支持#8176本版本最值得关注的增强是Add optional TLS feature to gRPC servers#8176对应新增的grpc-enable-optional-tls标志。该功能的核心价值在于让 gRPC 服务器能够在同一个端口上同时接受 TLS 加密连接与明文连接为 TLS 灰度切换先让一部分客户端走加密通道验证稳定后再全量切换提供了可行路径。从实现源码 go/vt/servenv/grpc_server.go 可以看到RegisterGRPCServerFlags()为 gRPC 服务注册了完整的 TLS 相关标志体系标志说明--grpc-cert服务器证书路径与--grpc-key同时指定即启用 TLS--grpc-key服务器私钥路径--grpc-ca服务器 CA 路径启用后强制校验客户端证书双向 TLS--grpc-crl证书吊销列表PEM 格式在 TLS 握手阶段进一步校验客户端证书--grpc-server-ca服务器 CA 路径与服务器证书组合后向客户端返回完整证书链--grpc-enable-optional-tls开启可选 TLS 模式同一端口同时接受 TLS 与明文连接实现逻辑位于createGRPCServer()中go/vt/servenv/grpc_server.go当gRPCCert与gRPCKey同时非空时通过vttls.ServerConfig(...)构造 TLS 配置强制 TLS 1.2 及以上再包装为 gRPC 的credentials.NewTLS若同时开启了grpc-enable-optional-tls则使用grpcoptionaltls.New(creds)进行包装此时服务器对明文连接仅记录警告Optional TLS is active. Plain-text connections will be accepted而不会拒绝。使用建议--grpc-enable-optional-tls适用于过渡期灰度场景在生产环境全量就绪后仍应通过关闭该标志并保留--grpc-cert/--grpc-key来强制全加密通信避免明文通道长期暴露。Build/CI 与 Documentation 变更v10.0.2还包含少量工程与文档层面的变更#8030Build/CI在 Makefile 中新增了 release 脚本将发布流程的一部分自动化提升后续版本包括v10.0.5这类安全补丁的出包效率#8081Build/CI更新发布说明以补充已知问题即本文开篇所述 Log4j 风险与-force/-keep_data问题#8045Documentation承接v10.0.1发布后的文档更新#8031OtherRelease 10.0.1即打包v10.0.1版本本身。结论v10.0.2 的定位与升级建议综合发布说明与仓库证据可以得出以下结论v10.0.2是一个过渡性的安全/稳定性补丁它修复了 Query Serving 的三处缺陷与 VReplication 的binary()列填充问题并首次引入 gRPC 可选 TLS 这一实用增强但并未解决 Log4j 漏洞使用 Java 客户端的用户应直接采用v10.0.5v10.0.5将log4j-api升级至2.17.1见 10.0.5 发布说明是 10.0 系列中规避 Log4j 风险的首选版本-force/-keep_data标志问题在整个 10.0 系列均存在涉及 VReplication v2 workflow 清理操作时务必参考 issue #9174 的 workaround核对标志实际语义。如果你正在 10.0 系列上规划升级路径建议直接越过v10.0.2以v10.0.5作为 10.0 系列的落点版本同时可参照本文的源码线索在升级前后重点回归验证 information_schema 查询、PRIMARY索引提示以及binary()列的 VReplication 同步行为。【免费下载链接】vitessVitess is a database clustering system for horizontal scaling of MySQL.项目地址: https://gitcode.com/gh_mirrors/vi/vitess创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考