MySQL Community Server 26.7 Early Access Release

MySQL 26.7 is the initial MySQL Innovation release following the MySQL 9.7 LTS release and uses the new yy.mmCalVer versioning model for quarterly Innovation releases. This Early Access release provides a preview of selected functionality planned for the MySQL Community Server package and gives users an opportunity to evaluate upcoming changes before general availability. Download MySQL Early Access

This post covers four areas:

• What is included in the MySQL 26.7 Early Access release
• Technical details for the main Community Server features
• Suggested areas to test and provide feedback on
• MySQL Community GitHub issues addressed by this Early Access release

Release scope

The MySQL 26.7 Early Access release includes updates in the following Community Server areas:

• InnoDB storage engine and recovery infrastructure
• Replication and Group Replication
• Server security
• Upgrade and compatibility checking
• Runtime connection handling

As with any Early Access release, this build is intended for evaluation and feedback. It should not be used for production workloads.

More robust undo log truncation

MySQL 26.7 improves the robustness of InnoDB undo log truncation.

Undo logs store information needed for transaction rollback and consistent reads. Over time, undo tablespaces can grow and must be truncated to reclaim space. InnoDB undo truncation was already crash safe; the change in MySQL 26.7 is to make the truncation process more robust and more redo-log-friendly.

Previously, the design depended on the existence of a local file to indicate that undo truncation was in progress. MySQL 26.7 removes that dependency and instead uses a flag in the undo header to track truncation state.

This matters because undo log management affects space usage, recovery behavior, and operational predictability for long-running transactional systems. The goal is not to change user-visible MVCC behavior or transaction semantics, but to make the underlying truncation process more robust across recovery scenarios.

InnoDB recovery and metadata infrastructure

MySQL 26.7 includes several InnoDB infrastructure improvements, including redo log interfaces, tablespace interfaces, MVCC and ReadView interfaces, standalone redo log replay, decoupling persistent table metadata from checkpointing, and faster restoration of IX table locks during undo recovery.

These changes are primarily internal. They improve the structure and efficiency of core InnoDB recovery, metadata, redo-log, tablespace, and transaction-visibility code paths. The goal is to make these areas easier to maintain, test, and extend without changing user-visible SQL semantics.

From a user perspective, MVCC should behave as before. There should be no semantic change in transaction visibility, consistent reads, or concurrency behavior. There should also be no performance regression from these infrastructure changes.

This matters because recovery, metadata durability, and MVCC are foundational to InnoDB correctness. Even when changes are not directly exposed as new syntax or configuration, cleaner and more efficient internal interfaces reduce risk and support future improvements.

Change Stream Applier for replication

Following the earlier Labs release for the Change Stream Applier, MySQL 26.7 Early Access includes this replication applier for evaluation as part of the 26.7 server release stream. The Change Stream Applier is a new replication applier implementation designed to improve parallel apply behavior and provide a more modular foundation for future replication work.

The applier is responsible for processing changes received from a source and applying them on a replica. Its efficiency directly affects replication lag, backlog recovery, and how quickly replicas catch up after bursts of write activity or maintenance windows.

The Change Stream Applier introduces a different execution model for parallel replication. It separates apply progression and commit progression, allows later independent transactions to continue while earlier transactions wait on dependencies, and reads relay-log events closer to execution time. The design also introduces per-channel controls such as APPLIER_VERSION, APPLIER_WORKER_COUNT, and APPLIER_EVENT_MEMORY_LIMIT.

The Change Stream Applier is selected per replication channel with APPLIER_VERSION = 2. The existing multi-threaded applier remains available as APPLIER_VERSION = 1.

Example configuration:

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';

In this Early Access release, the Change Stream Applier is intended for row-based GTID replication. It is not a universal replacement for every existing replication mode. Users should evaluate it first on non-critical channels that already use row-based replication and GTID-only mode.

Some replication modes and configuration patterns remain outside the scope of the Change Stream Applier in this release, including statement or mixed binary logging formats, filename/offset replication channels, delayed applier mode, GTID_ONLY=0, REQUIRE_ROW_FORMAT=0, and replica_pending_jobs_size_max, which is replaced for CSA by the per-channel APPLIER_EVENT_MEMORY_LIMIT.

This matters for users who depend on replication for read scaling, high availability, disaster recovery, migrations, or change data capture. Apply performance is often the limiting factor in keeping replicas current under write-heavy workloads, and faster backlog recovery can reduce operational risk after bursts or interruptions.

For additional implementation details, see WL#10500, “MTA: Optimized and generic change stream applier”: https://dev.mysql.com/worklog/task/?id=10500

Group Replication default communication stack

MySQL 26.7 changes the default Group Replication communication stack to MYSQL.

Group Replication uses a communication stack to coordinate messages between group members. The MYSQLcommunication stack uses MySQL Server connection security rather than Group Replication’s XCom-specific connection security implementation. This aligns Group Replication settings more closely with the rest of the server and makes the default configuration more hardened. The MySQL communication stack also uses the Group Replication distributed recovery user for authentication and requires the correct privileges for that user.

The new default applies automatically to servers running the version that includes this change, unless group_replication_communication_stack is explicitly configured in the server configuration file or on the command line.

This matters for new Group Replication deployments because the default path is simpler and more aligned with MySQL Server authentication and connection security. It also matters for existing deployments because changing the communication stack has upgrade and operational implications.

Important upgrade note: changing the Group Replication communication stack is not an online change for a running group. The communication stack must be consistent across all group members. Administrators migrating an existing group from XCOM to MYSQL must stop Group Replication on all members, update the required configuration, grant GROUP_REPLICATION_STREAM and CONNECTION_ADMIN to the distributed recovery user, and then restart or bootstrap the group according to the documented procedure.

For the complete procedure and connection-security requirements, see the Group Replication connection security documentation: https://dev.mysql.com/doc/refman/en/group-replication-connection-security.html

MySQL InnoDB Cluster already uses group_replication_communication_stack=MYSQL, so it is not impacted by this default change in the same way.

Deprecation of Group Replication XCom stack options

MySQL 26.7 adds deprecation warnings for Group Replication XCom-related options.

In MySQL 8.4 and 9.7, setting group_replication_communication_stack to XCOM emits a warning recommending MYSQL. In MySQL 26.7, setting either group_replication_communication_stack or group_replication_ip_allowlist emits a warning with no replacement.

Deprecation does not mean immediate removal. It means users should begin updating configuration, deployment automation, and operational documentation to avoid depending on settings that are planned to go away.

This matters for users operating Group Replication clusters today. Explicit warnings improve upgrade readiness by making deprecated configuration visible before it becomes a compatibility issue.

Post-quantum cryptography support with OpenSSL 3.5

MySQL Server 26.7 includes support for post-quantum cryptography when built with OpenSSL 3.5 or later.

Post-quantum cryptography is designed to protect against future attacks from cryptographically relevant quantum computers. In MySQL Server, this work allows users to begin evaluating post-quantum key exchange algorithms in environments where the underlying OpenSSL version provides them.

MySQL Server supports both hybrid and pure post-quantum key exchange algorithms, with preference given to hybrid algorithms for better interoperability with older clients. When strict post-quantum conformance is not required, MySQL Server can fall back to classical key exchange algorithms.

Supported groups are, in order of preference:

• X25519MLKEM768 — PQC hybrid: X25519 + ML-KEM-768
• secp384r1MLKEM1024 — PQC hybrid: P-384 + ML-KEM-1024
• secp256r1MLKEM768 — PQC hybrid: P-256 + ML-KEM-768
• MLKEM512 — PQC pure ML-KEM-512
• MLKEM768 — PQC pure ML-KEM-768
• X25519 — classical ECDH fallback
• secp384r1 — classical ECDHE fallback
• secp256r1 — classical ECDHE fallback
• secp521r1 — classical ECDHE fallback

This matters for organizations with long-lived data, regulated security requirements, or forward-looking cryptographic policies. Early evaluation helps teams understand platform requirements, interoperability, and operational impact before post-quantum algorithms become standard requirements.

Upgrade and compatibility check progress reporting

MySQL 26.7 includes progress reporting for compatibility checks and upgrade checks.

Upgrade checks can be time-consuming on large schemas or complex deployments. Without progress information, administrators may not know whether a check is still running normally, which phase is active, or whether the process is stalled.

Progress reporting makes upgrade preparation more observable. It helps users understand what MySQL is checking, track long-running operations, and troubleshoot upgrade-readiness workflows more effectively.

This matters for DBAs planning version upgrades. Better visibility reduces uncertainty during pre-upgrade validation and helps teams integrate upgrade checks into operational runbooks.

Thread Pool Plugin in MySQL Community Server

MySQL 26.7 makes the Thread Pool Plugin available in MySQL Community Server.

The Thread Pool Plugin provides an alternative to the default one-thread-per-connection execution model. Instead of allowing very high connection counts to create excessive scheduling overhead, the plugin manages statement execution threads for large numbers of client connections.

This helps address several common high-concurrency problems: excessive thread stacks, increased context switching, operating system scheduler pressure, and higher resource contention inside InnoDB when too many transactions execute in parallel.

This matters for workloads with many concurrent connections. Thread pool scheduling can help keep server parallelism within a range the host can handle, which can improve stability and reduce latency variance under high concurrency.

Making the Thread Pool Plugin available in Community Server allows more users to evaluate this behavior without requiring a commercial edition. The Thread Pool Plugin is existing MySQL functionality, so users familiar with the Enterprise Thread Pool behavior will recognize the configuration and tuning model. The 26.7 Early Access change is the availability of this plugin in MySQL Community Server; installation and tuning details should be verified against the 26.7 Early Access documentation and release notes when published.

What to test in the Early Access release

The most useful Early Access feedback will come from testing these features against realistic workloads and configurations. MySQL Early Access Release can be downloaded from here.

For InnoDB recovery and undo testing, validate undo log truncation behavior and recovery behavior using representative transactional workloads. Confirm that MVCC behavior, transaction visibility, and application semantics remain unchanged.

For replication environments, test the Change Stream Applier on row-based GTID channels. Measure replica lag, backlog drain time, CPU usage, memory use, and behavior when changing APPLIER_WORKER_COUNT and APPLIER_EVENT_MEMORY_LIMIT.

For Group Replication deployments, test both new deployments and upgrade scenarios. Pay special attention to explicit group_replication_communication_stack=XCOM settings, distributed recovery user privileges, and deprecation warnings.

For post-quantum cryptography, test TLS interoperability with clients built against different OpenSSL versions. Validate both hybrid PQC groups and fallback behavior where strict PQC conformance is not required.

For upgrade planning, run compatibility and upgrade checks against large schemas and confirm that progress reporting provides useful operational visibility.

For high-concurrency deployments, compare Thread Pool Plugin behavior against the default one-thread-per-connection model using realistic connection counts, latency targets, and transaction mixes.

Feedback from Early Access testing helps validate behavior, improve documentation, and identify compatibility issues before general availability.

MySQL Community GitHub issues addressed

The table below is a traceability reference between the 26.7 Early Access content and related MySQL Community GitHub issues. It is not a statement that each issue is fully resolved or closed.

Some issues represent broad engineering areas, while others map directly to a specific feature described above. Early Access feedback on these items helps validate behavior, improve documentation, and identify compatibility or performance issues before general availability.

As always, thank you for using MySQL!

Download MySQL Early Access