【昌哥IT课堂】MySQL Community Server 26.7-新功能：线程池插件终于可用了，撤销日志,组复制功能增强

2026-09-02

【昌哥IT课堂】MySQL Community Server 26.7-新功能：线程池插件终于可用了，撤销日志,组复制功能增强

MySQL 26.7 是继 MySQL 9.7 LTS 版本之后的首个 MySQL 创新版本，并采用新的 yy.mmCalVer 版本控制模型，按季度发布创新版本。此早期访问版本提供了MySQL 社区服务器软件包中部分功能的预览，使用户有机会在正式发布前评估即将发生的变更。

本文涵盖四个方面：

lMySQL 26.7 抢先体验版包含哪些内容

l社区服务器主要功能的详细技术信息

l建议测试并提供反馈意见的领域

l此早期访问版本解决了MySQL社区GitHub上的问题。

发布范围

MySQL 26.7 抢先体验版包含以下社区服务器领域的更新：

lInnoDB 存储引擎和恢复基础架构

l复制和组复制

l服务器安全

l升级和兼容性检查

l运行时连接处理

与所有抢先体验版一样，此版本仅用于评估和反馈，不应用于生产环境。

更强大的撤销日志截断

MySQL 26.7 提高了 InnoDB 撤销日志截断的健壮性。

撤销日志存储事务回滚和一致性读取所需的信息。随着时间的推移，撤销表空间会不断增长，必须进行截断以回收空间。InnoDB 的撤销截断机制已经具备崩溃安全性；MySQL 26.7 的改进旨在使截断过程更加健壮，并更好地兼容重做日志。

此前，该设计依赖于本地文件的存在来指示撤销截断操作正在进行中。MySQL 26.7 移除了这一依赖，转而使用撤销标头中的一个标志来跟踪截断状态。

这一点至关重要，因为撤销日志管理会影响长时间运行的事务系统的空间使用、恢复行为和运行可预测性。我们的目标并非改变用户可见的MVCC行为或事务语义，而是使底层截断过程在各种恢复场景下更加稳健。

InnoDB 恢复和元数据基础设施

MySQL 26.7 包含多项 InnoDB 基础架构改进，包括重做日志接口、表空间接口、MVCC 和 ReadView 接口、独立重做日志重放、将持久表元数据与检查点解耦，以及在撤销恢复期间更快地恢复IX表锁。

这些改动主要集中在内部。它们优化了InnoDB核心恢复、元数据、重做日志、表空间和事务可见性代码路径的结构和效率。目标是在不改变用户可见SQL语义的前提下，使这些区域更易于维护、测试和扩展。

从用户角度来看，MVCC 的行为应该与之前相同。事务可见性、一致性读取或并发行为方面不应有任何语义上的变化。此外，这些基础架构变更也不应导致性能下降。

这一点至关重要，因为恢复、元数据持久性和多变量上下文一致性（MVCC）是 InnoDB 正确性的基础。即使变更并未直接以新语法或配置的形式暴露出来，更简洁高效的内部接口也能降低风险并支持未来的改进。

用于复制的变更流应用器

继 Labs 之前发布的 Change Stream Applier 之后，MySQL 26.7 Early Access 也包含了此复制应用器，供用户在 26.7 服务器版本发布过程中进行评估。Change Stream Applier 是一种新的复制应用器实现，旨在改进并行应用行为，并为未来的复制工作提供更模块化的基础。

应用器负责处理从源接收的更改，并将其应用到副本上。其效率直接影响复制延迟、积压恢复以及副本在写入活动激增或维护窗口后追赶进度的速度。

变更流应用器为并行复制引入了一种不同的执行模型。它将应用进度和提交进度分开，允许后续的独立事务在之前的事务等待依赖项时继续执行，并在更接近执行时间时读取中继日志事件。该设计还引入了每个通道的控制项，例如APPLIER_VERSION, APPLIER_WORKER_COUNT, and APPLIER_EVENT_MEMORY_LIMIT。

每个复制通道都使用 . 选择变更流应用器 APPLIER_VERSION = 2。现有的多线程应用器仍然可用 APPLIER_VERSION = 1。

配置示例：

STOP REPLICA FOR CHANNEL 'channel_1';

CHANGE REPLICATION SOURCE TO

APPLIER_VERSION = 2,

APPLIER_WORKER_COUNT = 64,

APPLIER_EVENT_MEMORY_LIMIT = 1073741824,

REQUIRE_ROW_FORMAT = 1,

GTID_ONLY = 1

FOR CHANNEL 'channel_1';

START REPLICA FOR CHANNEL 'channel_1';

在此早期访问版本中，变更流应用器旨在用于基于行的 GTID 复制。它并非可完全替代所有现有复制模式。用户应首先在已使用基于行的复制和仅 GTID 模式的非关键通道上进行评估。

在本版本中，某些复制模式和配置模式仍不在变更流应用器 (Change Stream Applier) 的范围内，包括语句或混合二进制日志格式、文件名/偏移量复制通道、延迟应用器模式, GTID_ONLY=0和 REQUIRE_ROW_FORMAT=0， replica_pending_jobs_size_max其中CSA已由按通道取代 APPLIER_EVENT_MEMORY_LIMIT。

对于依赖复制进行读取扩展、高可用性、灾难恢复、迁移或变更数据捕获的用户而言，这一点至关重要。在写入密集型工作负载下，应用性能通常是保持副本最新状态的限制因素，而更快的积压恢复可以降低突发或中断后的运维风险。

有关更多实现细节，请参阅 WL#10500，“MTA：优化的通用变更流应用器”： https://dev.mysql.com/worklog/task/?id =10500

组复制默认通信堆栈

MySQL 26.7 将默认的组复制通信堆栈更改为 MYSQL。

组复制使用通信堆栈来协调组成员之间的消息。该 MYSQL通信堆栈使用 MySQL 服务器的连接安全机制，而不是组复制特有的 XCom 连接安全实现。这使得组复制的设置与服务器的其他部分更加一致，并增强了默认配置的安全性。此外，MySQL 通信堆栈还使用组复制分布式恢复用户进行身份验证，并且需要该用户拥有相应的权限。

group_replication_communication_stack 除非在服务器配置文件或命令行中明确配置，否则新的默认设置将自动应用于运行包含此更改的版本的服务器。

对于新的组复制部署而言，这一点至关重要，因为默认路径更简单，也更符合 MySQL 服务器的身份验证和连接安全性要求。对于现有部署而言，这一点也很重要，因为更改通信堆栈会带来升级和运维方面的影响。

重要升级提示： 更改组复制通信堆栈并非对正在运行的组进行在线更改。所有组成员的通信堆栈必须保持一致。管理员要将现有组从 XCOM 到 MYSQL，必须停止所有成员上的组复制，更新所需的配置，授予分布式恢复用户 GROUP_REPLICATION_STREAM 和CONNECTION_ADMIN权限，然后按照文档中记录的步骤重新启动或引导组。

有关完整流程和连接安全要求，请参阅组复制连接安全文档：

https://dev.mysql.com/doc/refman/en/group-replication-connection-security.html

MySQL InnoDB 集群已经使用了 group_replication_communication_stack=MYSQL，因此它不会以同样的方式受到此默认更改的影响。

弃用 XCom 堆栈选项中的组复制功能

MySQL 26.7 为组复制 XCom 相关选项添加了弃用警告。

在 MySQL 8.4 和 9.7 中，若将 group_replication_communication_stack 设置为 XCOM，服务器会发出一条警告，建议使用 MYSQL。在 MySQL 26.7 中，将 group_replication_communication_stack 或 group_replication_ip_allowlist 设置为任何值都会触发一条警告，提示该参数已无替代项（即已被废弃且无对应替代参数）。

弃用并不意味着立即移除。它意味着用户应该开始更新配置、部署自动化和操作文档，以避免依赖那些计划移除的设置。

这对于目前运行组复制集群的用户至关重要。明确的警告能够提前显示已弃用的配置，避免其演变为兼容性问题，从而提高升级准备度。

OpenSSL 3.5 支持后量子密码学

如果使用 OpenSSL 3.5 或更高版本构建，MySQL Server 26.7 将支持后量子加密。

后量子密码学旨在抵御未来来自具有密码学意义的量子计算机的攻击。在MySQL服务器中，这项工作允许用户在底层 OpenSSL 版本支持的环境中开始评估后量子密钥交换算法。

MySQL 服务器同时支持混合型和纯后量子密钥交换算法，优先选择混合型算法以更好地兼容旧版客户端。当不需要严格遵循后量子标准时，MySQL 服务器可以回退到经典密钥交换算法。

支持的群体按优先顺序排列如下：

lX25519MLKEM768 — PQC hybrid: X25519 + ML-KEM-768

lsecp384r1MLKEM1024 — PQC hybrid: P-384 + ML-KEM-1024

lsecp256r1MLKEM768 — PQC hybrid: P-256 + ML-KEM-768

lMLKEM512 — PQC pure ML-KEM-512

lMLKEM768 — PQC pure ML-KEM-768

lX25519 — classical ECDH fallback

lsecp384r1 — classical ECDHE fallback

lsecp256r1 — classical ECDHE fallback

lsecp521r1 — classical ECDHE fallback

对于拥有长期保存数据、受监管的安全要求或前瞻性加密策略的组织而言，这一点至关重要。早期评估有助于团队在后量子算法成为标准要求之前，了解平台需求、互操作性和运营影响。

升级和兼容性检查进度报告

MySQL 26.7 包含兼容性检查和升级检查的进度报告功能。

对于大型架构或复杂部署，升级检查可能非常耗时。如果没有进度信息，管理员可能无法了解检查是否仍在正常运行、当前处于哪个阶段，或者过程是否已停滞。

进度报告使升级准备工作更易于观察。它帮助用户了解 MySQL 正在检查的内容，跟踪长时间运行的操作，并更有效地排查升级准备工作流程中的问题。

这对于数据库管理员规划版本升级至关重要。更高的可见性可以降低升级前验证期间的不确定性，并帮助团队将升级检查集成到运维手册中。

MySQL 社区服务器中的线程池插件

MySQL 26.7 在 MySQL Community Server 中提供了线程池插件。

线程池插件提供了一种替代默认的“每个连接一个线程”执行模型的方案。该插件不会允许过高的连接数造成过多的调度开销，而是为大量客户端连接管理语句执行线程。

这有助于解决几个常见的高并发问题：线程栈过大、上下文切换增加、操作系统调度程序压力增大，以及当太多事务并行执行时 InnoDB 内部资源争用加剧。

对于具有大量并发连接的工作负载而言，这一点至关重要。线程池调度有助于将服务器并行度控制在主机可处理的范围内，从而提高稳定性并降低高并发下的延迟波动。

在社区服务器中提供线程池插件，可以让更多用户无需购买商业版即可评估此功能。线程池插件是 MySQL 的现有功能，因此熟悉企业级线程池的用户会发现其配置和调优方法同样适用。26.7 抢先体验版的主要变化是 MySQL 社区服务器中新增了此插件；安装和调优详情请参考 26.7 抢先体验版文档和发行说明（待发布）。

抢先体验版需要测试哪些内容

最有价值的抢先体验版反馈将来自在实际工作负载和配置下测试这些功能。MySQL 抢先体验版可在此处下载。

对于 InnoDB 的恢复和撤销测试，请使用典型的事务工作负载验证撤销日志截断行为和恢复行为。确认 MVCC 行为、事务可见性和应用程序语义保持不变。

对于复制环境，请在基于行的 GTID 通道上测试变更流应用器。测量副本延迟、积压清除时间、CPU 使用率、内存使用率以及更改 APPLIER_WORKER_COUNT 和 APPLIER_EVENT_MEMORY_LIMIT 时的行为

对于组复制部署，请测试新部署和升级方案。特别注意显式 group_replication_communication_stack=XCOM 设置、分布式恢复用户权限和弃用警告。

对于后量子密码学，测试使用基于不同 OpenSSL 版本构建的客户端的TLS互操作性。验证混合PQC组以及在无需严格遵循 PQC 标准时的回退行为。

对于升级规划，请对大型架构运行兼容性和升级检查，并确认进度报告能够提供有用的操作可见性。

对于高并发部署，请使用实际的连接数、延迟目标和事务组合，将线程池插件的行为与默认的每连接一个线程模型进行比较。

早期访问测试的反馈有助于验证行为、改进文档，并在正式发布前发现兼容性问题。

MySQL 社区 GitHub 问题已解决
下表列出了 26.7 抢先体验版内容与 MySQL 社区 GitHub 问题之间的追溯关系。但这并不意味着每个问题都已完全解决或关闭。

GitHub 问题	社区问题标题	MySQL 26.7 EA 区域
#64	MTA：优化的通用变更流应用器	用于复制的变更流应用器
#61	InnoDB：加快撤销恢复期间 IX 表锁的恢复速度	InnoDB撤销恢复性能
#58	InnoDB：使撤销日志截断操作不崩溃	更强大的撤销日志截断
#56	InnoDB：MVCC 和 ReadView 接口	InnoDB 交易可见性基础设施
#55	InnoDB：独立 REDO 日志重放	InnoDB 恢复基础设施
#54	InnoDB：表空间接口	InnoDB 表空间基础架构
#53	InnoDB：将持久表元数据与检查点机制解耦	InnoDB 元数据和检查点基础架构