MySQL 26.7: What's New, Release History & Support Lifecycle

What Is New in MySQL 26.7

What Is the Change Stream Applier (CSA) in MySQL 26.7?

The Change Stream Applier (CSA) is a new, opt-in implementation of the replica SQL applier designed to replace the Multi-Threaded Applier (MTA) on a per-channel basis. In practice, CSA separates transaction application from commit ordering, so a worker that cannot yet commit can move on to another dependency-ready transaction instead of sitting idle. This matters if you run high-throughput replicas that have historically been bottlenecked by MTA scheduling.

CSA is configured per channel and coexists with MTA channels on the same server. You enable it with APPLIER_VERSION = 2 and can scale workers from 1 to 1024 with APPLIER_WORKER_COUNT:

CHANGE REPLICATION SOURCE TO
  APPLIER_VERSION = 2,
  APPLIER_WORKER_COUNT = 8,
  APPLIER_EVENT_MEMORY_LIMIT = 1073741824
  FOR CHANNEL 'channel_name';

Watch out for the list of unsupported configurations before migrating a channel. CSA does not work with statement-based or mixed-format binary logs, file-position replication, GTID_MODE other than ON, GTID_ONLY=0, delayed replication via SOURCE_DELAY, sql_replica_skip_counter, or most START REPLICA ... UNTIL conditions. Most teams running standard GTID-based, row-format replication will be able to adopt CSA channel by channel, but you must stop the SQL thread first when updating an existing channel.

How Does MySQL 26.7 Support Post-Quantum Cryptography?

MySQL 26.7 adds native support for post-quantum cryptography (PQC) in TLS 1.3 connections when built against OpenSSL 3.5.0 or later. This allows negotiation of hybrid classical/PQC key-exchange groups and PQC-capable handshake signature algorithms across the main, admin, replication, Group Replication, and X Plugin connection channels.

Each channel gets its own enforcement and configuration variables, for example:

• force_pqc and admin_force_pqc to require a PQC-compatible key exchange on client and admin connections
• replication_force_pqc and group_replication_force_pqc for replication and Group Replication recovery traffic
• tls_kex, admin_tls_kex, replication_tls_kex, and group_replication_tls_kex to control which key exchange groups are offered

In practice, if you enable a use_pqc_sign-style variable but the negotiated OpenSSL configuration does not have PQC available, the server falls back to the OpenSSL default instead of failing the connection. New status variables such as Tls_key_exchange_algorithm and Tls_sign_algorithm let you confirm what was actually negotiated, which is useful for auditing whether your fleet is actually using PQC after a rollout.

What Changed with MySQL's Versioning Scheme in 26.7?

MySQL now uses calendar-based versioning (CalVer) for releases after the 9.7 LTS series, and MySQL 26.7.0 is the first release under this scheme. Version numbers now follow a Year.Month.Patch (YY.M.P) format instead of the traditional major.minor.patch numbering used through the 8.x and 9.x series.

This matters most for tooling and automation that parses version strings or makes upgrade path decisions. To help with that, mysql_version.h now exposes MYSQL_PREVIOUS_LTS_VERSION and MYSQL_PREVIOUS_LTS_VERSION_ID, which identify the last LTS release (9.7.0, represented as 90700) so scripts can still establish a clear upgrade and downgrade lineage. This version numbering change also affects Clone plugin behavior: cloning is allowed across patch versions of a given version and from a donor in one LTS to a recipient in the next LTS, but not across mismatched major or minor versions on non-LTS releases.

Is the Thread Pool Plugin Now Available in Community Edition?

Yes, the MySQL Thread Pool plugin, previously exclusive to MySQL Enterprise Edition, ships in MySQL Community Edition as of 26.7.0. This matters if you have been running a self-managed connection-handling layer or a third-party proxy purely to work around thread-per-connection scaling limits on Community installs.

Alongside this change, the default value of thread_pool_max_unused_threads increased from 2 to 32. If you enable the thread pool on a busy server, expect a larger pool of idle threads to be retained by default, which reduces thread creation churn under bursty workloads but also increases idle memory overhead. Most teams should benchmark this default against their own connection concurrency patterns before rolling it out broadly.

What InnoDB and Upgrade Fixes Should You Know About Before Upgrading?

The most operationally relevant InnoDB and upgrade fixes in 26.7 address memory growth and accuracy issues that show up specifically during upgrades and monitoring. Memory management is improved for upgrades from older 8.x releases with thousands of tables, views, routines, and events, which previously caused continuous memory growth and spikes during the upgrade process.

Other fixes worth planning around:

• INFORMATION_SCHEMA.INNODB_CACHED_INDEXES.N_CACHED_PAGES could previously report implausibly high values, including numbers above the buffer pool capacity; this is now corrected
• Adding an AUTO_INCREMENT column to an existing table could skip records under certain conditions, producing inaccurate AUTO_INCREMENT values
• Large AUTO_INCREMENT values above INT64_MAX were truncated in information_schema.tables.auto_increment
• Server upgrade checks could fail when validating events created under a different sql_mode, aborting valid upgrades

In practice, if you are planning a large-scale upgrade from an 8.x release with a heavy schema footprint, this release is worth prioritizing specifically for the memory-management fix.