MySQL 26.7 and 9.7 LTS: 7 Powerful Features for Performance, Scalability and High Availability

MySQL 26.7 is the first release Oracle has shipped under calendar versioning, and it landed on 28 July 2026 together with MySQL 9.7.2 LTS and MySQL 8.4.11 LTS. Most of the coverage so far has stopped at the version-number change. That is the least interesting thing about it. What matters for anyone running MySQL in production is that MySQL 26.7 moves the Thread Pool plugin into Community Edition, introduces a second replication applier with up to 1,024 worker threads per channel, flips the default Group Replication communication stack, and adds post-quantum key exchange to TLS.

Combined with what 9.7 LTS already carried across from Enterprise (the hypergraph optimizer, OpenTelemetry, the Group Replication components), the Community versus Enterprise line has moved further in two releases than in the previous ten years.

This post walks through the features that actually change performance, scalability and high availability outcomes, with the configuration and the measurement queries you need to verify each one on your own hardware. It also lists what is still Enterprise-only, because that list is now short enough to reason about honestly. Everything here is version-pinned against the release notes; where Oracle has published performance figures, they are labelled as Oracle's, not ours.

MySQL 26.7, 9.7 LTS and 8.4 LTS: which one goes to production

Three supported lines shipped in the July 2026 drop, and they are not interchangeable. MySQL 9.7 was the last release to use sequential version numbers; everything after it is YY.M.P, so 26.7.0 is simply the July 2026 Innovation release. Innovation releases are supported only until the next one appears. They have no Extended Support window. MySQL 26.7 is therefore the right choice for a fleet that upgrades quarterly and wants the Change Stream Applier or the Community thread pool today, and the wrong choice for anything that needs to sit still for three years.

The ladder below is the one Oracle supports. In-place upgrades between LTS lines are adjacent-only, so an 8.0 estate cannot jump to 9.7; it goes through 8.4 first. MySQL 8.0 entered Sustaining Support on 21 April 2026, which means no new patches and no new security fixes for on-premises installations (the HeatWave extension to April 2027 does not apply outside OCI).

One practical consequence of calendar versioning that Ronald Bradford flagged in his early-access write-up: any tooling that sorts version strings lexically now believes 26.7 is older than 9.7. Check your inventory scripts, your package pinning and your monitoring dashboards before the first MySQL 26.7 host reports in. Oracle added MYSQL_PREVIOUS_LTS_VERSION and MYSQL_PREVIOUS_LTS_VERSION_ID to mysql_version.h for exactly this reason.

Thread Pool in MySQL 26.7 Community: connection scalability without the Enterprise licence

For fifteen years the Thread Pool plugin was the single most-cited reason to buy MySQL Enterprise Edition. MySQL 26.7.0 ships it in Community. Percona Server has had its own thread pool implementation since 5.5, so the capability is not new to the ecosystem, but this is the first time Oracle's implementation, with its priority queues, stall detection and the TP_CONNECTION_ADMIN escape hatch, is available without a subscription. On MySQL 9.7 LTS it is still Enterprise-only; the Community transfer is a 26.7 change.

The mechanism is worth understanding before you turn it on, because it changes the shape of your latency curve rather than just shifting it. The default one-thread-per-connection model creates a kernel thread for every session. At two or three thousand active connections the cost is not memory, it is the OS scheduler and the InnoDB mutexes that all those runnable threads contend on. The thread pool replaces that with thread_pool_size thread groups (default 16), each owning a listener thread, a high-priority queue, a low-priority queue and a small set of worker threads. Connections are assigned to groups round-robin.

The pool tries to keep exactly one thread executing per group and only spawns another when a statement exceeds thread_pool_stall_limit (default 60 ms).

Loading it on MySQL 26.7 is a startup option, not a dynamic change, so it needs a restart and a maintenance window:

# /etc/my.cnf  (MySQL 26.7.0 Community; restart required)
[mysqld]
plugin-load-add               = thread_pool.so
thread_handling               = pool-of-threads
thread_pool_size              = 16        # start at physical cores, not vCPUs
thread_pool_stall_limit       = 60        # ms; raise for OLAP-style statements
thread_pool_max_unused_threads = 32       # 26.7 / 9.7.2 default (was 2)
thread_pool_prio_kickup_timer = 1000      # ms before a low-priority stmt is promoted
thread_pool_max_transactions_limit = 0    # 0 = no cap; set only with TP_CONNECTION_ADMIN granted

Two of those defaults changed in this release cycle. thread_pool_max_unused_threads moved from 2 to 32 in both 26.7.0 and 9.7.2, which reduces thread churn on bursty workloads at the cost of a few idle stacks. Verify the plugin loaded and confirm all four components are active (the plugin registers itself plus three Performance Schema tables):

SELECT plugin_name,
       plugin_status,
       plugin_type
  FROM information_schema.plugins
 WHERE plugin_name LIKE 'thread_pool%'
    OR plugin_name LIKE 'TP_%';

Then measure instead of guessing. The statistics table is the one to watch; the ratio of queued to executed statements per group tells you whether thread_pool_size is too low, and a rising stall count with acceptable throughput tells you the stall limit is too aggressive for your statement mix:

SELECT tp_group_id,
       connections_started,
       queries_executed,
       queries_queued,
       stalled_queries_executed,
       threads_started,
       prio_kickups
  FROM performance_schema.tp_thread_group_stats
 ORDER BY tp_group_id;

The honest framing for anyone planning to enable this on MySQL 26.7: the thread pool improves p99 under connection storms and protects InnoDB from thundering-herd contention. It does not raise peak throughput on a workload that was already CPU-bound at moderate concurrency, and on some short-transaction OLTP profiles it costs a few percent of throughput at low connection counts. Run a sysbench sweep from 64 to 4,096 connections with and without it, on your schema, before committing. We covered the plugin's Community arrival in more detail in MySQL Thread Pool comes to Community in 26.7.

Change Stream Applier: the MySQL 26.7 replication applier built for backlog

This is the largest piece of new replication engineering since the multi-threaded applier gained writeset dependency tracking in 8.0. The Change Stream Applier (CSA) is an opt-in, per-channel alternative to the classic MTA, selected with APPLIER_VERSION = 2. It supports between 1 and 1,024 worker threads per channel, compared to the MTA's coordinator-bound model, and, more importantly, it separates apply progression from commit progression.

Why that separation matters: in the MTA, a worker that finishes applying a transaction parks until every earlier transaction has committed when replica_preserve_commit_order is ON. Under a write-heavy backlog with long-tail transactions, workers spend more time parked than applying. In the CSA design, later independent transactions keep moving through the scheduler while earlier ones wait on their dependencies; commit order is still preserved, but the avoidable parking is gone. Relay-log reads are parallel and events are released after use, which is what makes the new per-channel memory budget possible.

Enabling it on a MySQL 26.7 replica is a channel-level change and requires the channel to be stopped:

-- MySQL 26.7.0 replica; run per channel, outside peak, with a rollback plan.
STOP REPLICA FOR CHANNEL 'ch_primary';

CHANGE REPLICATION SOURCE TO
    APPLIER_VERSION             = 2,
    APPLIER_WORKER_COUNT        = 64,
    APPLIER_EVENT_MEMORY_LIMIT  = 1073741824,   -- 1 GiB per-channel event cache
    REQUIRE_ROW_FORMAT          = 1,
    GTID_ONLY                   = 1
FOR CHANNEL 'ch_primary';

START REPLICA FOR CHANNEL 'ch_primary';

-- Verify the channel is running with the new applier.
SELECT channel_name,
       applier_version,
       applier_worker_count,
       applier_event_memory_limit
  FROM performance_schema.replication_applier_configuration;

Rollback is symmetric: stop the channel, set APPLIER_VERSION = 1, start it. The existing performance_schema.replication_applier_status_by_worker and replication_applier_status_by_coordinator views keep working, so your lag dashboards do not need to change. APPLIER_EVENT_MEMORY_LIMIT replaces the global replica_pending_jobs_size_max for CSA channels and is silently raised to replica_max_allowed_packet if you set it lower.

The prerequisites are strict and they are where most first attempts fail. The source must run with gtid_mode = ON, the channel must be GTID_ONLY = 1 and REQUIRE_ROW_FORMAT = 1, and statement or mixed binlog formats are rejected outright. File-and-position replication, SOURCE_DELAY, sql_replica_skip_counter, IGNORE_SERVER_IDS and most START REPLICA ... UNTIL forms are unsupported. If you run a delayed replica for operator-error recovery, that channel stays on the MTA.

Oracle's engineering post reports sysbench oltp_write_only results with 64 workers where the CSA reached roughly 10.5k TPS against 7.2k for the MTA on the default durability profile with ten updates per transaction, and a wider gap with relaxed durability. Those are Oracle-reported numbers on Oracle's hardware.

The pattern they show is plausible given the design (the gain grows with transaction size and with backlog depth), but the only number that matters for you is your own replica's Seconds_Behind_Source recovery time after an induced backlog, measured with APPLIER_VERSION = 1 and 2 on the same channel. A clean way to induce one is to STOP REPLICA SQL_THREAD for a fixed interval under production-shaped load, restart it, and record time-to-zero-lag from replication_applier_status_by_worker. Run it at least three times per configuration and report the median.

Group Replication in MySQL 26.7: the MYSQL communication stack becomes the default

MySQL 26.7 changes the default of group_replication_communication_stack from XCOM to MYSQL, deprecates the variable itself along with group_replication_ip_allowlist, and emits deprecation warnings on the XCom-specific options. The MYSQL stack has existed since 8.0.27; what changed is that it is now the path Oracle is committing to, and new clusters bootstrapped on 26.7 will use it unless told otherwise.

Under the MYSQL stack, group communication rides the server's own listener. group_replication_local_address must be one of the IP:port pairs the server is already bound to, the allowlist is ignored, and access control becomes ordinary MySQL authentication: the replication user needs GROUP_REPLICATION_STREAM and CONNECTION_ADMIN on top of REPLICATION SLAVE and BACKUP_ADMIN. TLS for group traffic is taken from the distributed-recovery settings, and require_secure_transport must agree with group_replication_ssl_mode on every member. Network namespaces work, which they never did under XCom.

The operational point is that this is a topology change, not a parameter change. A cluster cannot run mixed stacks; members on the wrong one simply fail to join, without a helpful error. Moving an existing XCom cluster to the MYSQL stack requires stopping Group Replication on every member and re-bootstrapping, so it is a planned outage or a ClusterSet failover, not something to attempt with SET PERSIST on a live primary. The procedure below is the one we would put in a runbook, with its gates:

-- Phase 0: pre-flight on EVERY member (MySQL 26.7.0). Record the output.
SELECT @@group_replication_communication_stack,
       @@group_replication_local_address,
       @@bind_address,
       @@require_secure_transport,
       @@group_replication_ssl_mode;

SELECT member_host, member_port, member_state, member_role, member_version
  FROM performance_schema.replication_group_members;

-- Phase 1: grant the MYSQL-stack privileges (all members, binlog off).
SET SQL_LOG_BIN = 0;
GRANT GROUP_REPLICATION_STREAM ON *.* TO '${GR_USER}'@'%';
GRANT CONNECTION_ADMIN         ON *.* TO '${GR_USER}'@'%';
SET SQL_LOG_BIN = 1;

-- Phase 2: stop the group, secondaries first, primary last.
STOP GROUP_REPLICATION;

-- Phase 3: switch stack and re-point the local address to a bound port.
SET PERSIST group_replication_communication_stack = 'MYSQL';
SET PERSIST group_replication_local_address       = '10.0.1.11:3306';
SET PERSIST group_replication_group_seeds         =
    '10.0.1.11:3306,10.0.1.12:3306,10.0.1.13:3306';

-- Phase 4: bootstrap ONCE, on the former primary only. CONFIRMATION GATE:
-- a second bootstrap creates a split brain. Verify no member is ONLINE first.
SET GLOBAL group_replication_bootstrap_group = ON;
START GROUP_REPLICATION;
SET GLOBAL group_replication_bootstrap_group = OFF;

-- Phase 5: join the remaining members, then validate.
START GROUP_REPLICATION;
SELECT member_host, member_state, member_role
  FROM performance_schema.replication_group_members;

Firewall rules, load-balancer health checks and MySQL Router bootstrap configuration all encode the port model, so a stack migration on MySQL 26.7 touches more than the database hosts. If you are bootstrapping a new cluster, let the new default stand and skip the migration entirely. If you run an existing XCom cluster and are not moving to 26.7 this quarter, there is no urgency: the deprecation is a warning in 26.7, and 9.7 LTS keeps the XCom default. Plan the switch into the next LTS upgrade rather than as a standalone change.

Two smaller HA items in the same release: the Clone plugin now understands calendar versions and permits cloning from an LTS to the next LTS (but not backwards, and not across non-sequential LTS lines), and the 9.7 LTS transfer already put the Group Replication flow-control statistics, resource manager and primary-election components into Community. For a deeper treatment of write throughput on InnoDB Cluster, see our InnoDB Cluster write-performance analysis.

Optimizer and InnoDB features MySQL 26.7 inherits from 9.7 LTS

Everything in 9.7.0 is in MySQL 26.7, and a few of those features change day-to-day performance work more than anything new to 26.7.

Hypergraph optimizer, now free, still off by default

The hypergraph join optimizer moved from Enterprise to Community in 9.7.0. It is disabled by default and enabled with the optimizer_switch flag, either globally or per statement:

-- Per-statement trial: no global blast radius.
SELECT /*+ SET_VAR(optimizer_switch = 'hypergraph_optimizer=on') */
       o.customer_id,
       SUM(oi.quantity * oi.unit_price) AS revenue
  FROM orders      AS o
  JOIN order_items AS oi ON oi.order_id = o.order_id
  JOIN products    AS p  ON p.product_id = oi.product_id
 WHERE o.created_at >= '2026-08-01'
 GROUP BY o.customer_id
 ORDER BY revenue DESC
 LIMIT 50;

-- Compare plans. Hypergraph only emits EXPLAIN FORMAT=TREE.
EXPLAIN FORMAT=TREE
SELECT /*+ SET_VAR(optimizer_switch = 'hypergraph_optimizer=on') */ ...;

The adoption blocker is the EXPLAIN restriction: hypergraph does not produce TRADITIONAL or JSON output, only TREE. Any plan-diffing tooling built around JSON EXPLAIN stops working the moment you enable it. Note also that MySQL 9.5 already changed the default explain_format to TREE and explain_json_format_version to 2, so scripts that parsed the old tabular output broke one release earlier. Both are dynamic and can be reverted with SET GLOBAL explain_format = 'TRADITIONAL'. Measure before and after with the digest statistics rather than with anecdotes:

SELECT digest,
       LEFT(digest_text, 80)                          AS stmt,
       count_star                                     AS execs,
       ROUND(sum_timer_wait / count_star / 1e9, 3)    AS avg_ms,
       ROUND(quantile_99 / 1e9, 3)                    AS p99_ms,
       sum_rows_examined / count_star                 AS rows_examined_avg
  FROM performance_schema.events_statements_summary_by_digest
 WHERE schema_name = 'app'
 ORDER BY sum_timer_wait DESC
 LIMIT 20;

Foreign keys moved to the SQL layer (9.6)

MySQL 9.6 moved foreign-key enforcement and cascade handling out of InnoDB and into the SQL layer, and MySQL 26.7 inherits that. The stated reason is completeness of the binary log: cascaded deletes and updates now appear as row events. That is good news for CDC pipelines (Debezium and friends finally see cascades) and a surprise for capacity planning, because binlog volume and replication row traffic go up on schemas with deep cascade chains. innodb_native_foreign_keys reverts to the old behaviour. Track the delta with SHOW BINARY LOGS growth per hour before and after the upgrade.

Defaults that changed underneath you

Several InnoDB and replication defaults shifted between 9.3 and 9.5, and every one of them is live on a fresh MySQL 26.7 install. The ones that alter observable behaviour:

Container-aware sizing

Since 9.3 the server reads cgroup limits rather than host totals when auto-sizing innodb_buffer_pool_size, innodb_buffer_pool_instances, innodb_page_cleaners, innodb_purge_threads, the read and parallel-read thread counts and temptable_max_ram. MySQL 26.7 adds the 9.7 refinement for cpuset-cpus. If you run MySQL on Kubernetes, this is the release where a pod with a 16 GiB limit stops trying to allocate a buffer pool sized for the 256 GiB node underneath it. Confirm what the server actually chose after startup with SELECT @@innodb_buffer_pool_size, @@innodb_buffer_pool_instances, @@server_memory; and compare against the pod spec.

The 9.6 undo-truncation work, which in 26.7 persists progress in the tablespace header instead of separate log files, is the other InnoDB item worth noting: long undo truncations now survive a crash cleanly.

Post-quantum TLS in MySQL 26.7

When built against OpenSSL 3.5 or later, MySQL 26.7 negotiates post-quantum key-exchange groups on TLS 1.3 connections. Fourteen new variables control it across five channels: client, admin, asynchronous replication, Group Replication and X Plugin. Each channel has a *_tls_kex list, a *_force_pqc boolean and a *_use_pqc_sign boolean, all defaulting to OFF, so nothing changes until you opt in. The negotiated result is visible per session in Tls_key_exchange_algorithm and Tls_sign_algorithm.

-- Opt replication traffic into a hybrid PQC group first; clients later.
SET PERSIST replication_tls_kex   = 'X25519MLKEM768:X25519';
SET PERSIST replication_force_pqc = ON;

-- Verify on an established replication session.
SHOW SESSION STATUS LIKE 'Tls_key_exchange_algorithm';

The performance angle is real but small: ML-KEM handshakes carry a larger key share, so the cost lands on connection establishment, not on the data path. For a pooled application it is noise. For a workload that opens thousands of short-lived TLS connections per second it is measurable, and it stacks with the doubled caching_sha2_password_digest_rounds. Watch Connections per second against CPU before turning on force_pqc for the client channel. The build dependency matters too: distro packages built against OpenSSL 3.0 silently lack the capability, so check SHOW VARIABLES LIKE 'tls_version' alongside @@version_compile_os and the linked OpenSSL version reported at startup.

What is still Enterprise-only in MySQL 26.7 and 9.7

After the 9.7.0 transfer (hypergraph, telemetry, the three Group Replication components, replication applier metrics, JSON duality-view DML) and the 26.7 thread-pool transfer, the Enterprise value proposition has moved from performance and HA to security, backup and AI. That is worth stating plainly because it changes the renewal conversation. This is the remaining list as of the July 2026 releases:

MySQL Enterprise Monitor is absent from that table because it reached end of life on 1 January 2025. Estates still running it should be on a Percona Monitoring and Management migration path regardless of edition. The renewal audit we run before offering any opinion is short: SHOW PLUGINS, the information_schema.plugins rows with a non-null library, the audit% and keyring% variables, and whether MEB appears in the backup jobs. In most Enterprise estates the answer is MEB plus Audit, and both have substitutes; on 26.7 specifically, the thread pool is no longer a reason to renew.

Upgrade checklist before the first MySQL 26.7 host

Whether the target is 9.7 LTS or MySQL 26.7, the pre-flight is the same, because the landmines arrived in 9.3, 9.5 and 9.6 and 26.7 inherits all of them. Run these on every source and replica and keep the output with the change record:

-- 1. Replication defaults that flip on upgrade (9.5+).
SELECT @@gtid_mode,
       @@enforce_gtid_consistency,
       @@binlog_format;

SELECT channel_name,
       ssl_allowed,
       ssl_verify_server_cert
  FROM performance_schema.replication_connection_configuration;

-- 2. Variables removed in 9.3 that abort startup if left in my.cnf.
SELECT variable_name
  FROM performance_schema.global_variables
 WHERE variable_name IN ('innodb_undo_tablespaces',
                         'innodb_log_file_size',
                         'innodb_log_files_in_group',
                         'replica_parallel_type');

-- 3. Authentication plugins that no longer load by default (8.4+).
SELECT user, host, plugin
  FROM mysql.user
 WHERE plugin IN ('mysql_native_password', 'sha256_password');

-- 4. Functions moved out of core in 9.6 (MD5, SHA1 -> classic_hashing component).
SELECT table_schema, table_name, column_name, generation_expression
  FROM information_schema.columns
 WHERE generation_expression REGEXP 'MD5\\(|SHA1\\(';

# 5. Oracle's upgrade checker (MySQL Shell). 26.7 adds live progress reporting.
mysqlsh -- util check-for-server-upgrade \
    ${MYSQL_USER}@${MYSQL_HOST}:3306 \
    --target-version=26.7.0 \
    --output-format=JSON \
    --config-path=/etc/my.cnf > /var/tmp/upgrade-check-$(hostname).json

Then capture the baseline you will compare against after the upgrade: the top-50 digests by total wait from events_statements_summary_by_digest, replication lag distribution over a representative week, binlog growth per hour, and connection and CPU counters. Without the baseline, the post-upgrade argument about whether the hypergraph optimizer or the change-buffer default helped or hurt is opinion. Test on a clone with production-shaped load, keep a downgrade path inside the LTS series, and treat the Innovation track as something you can roll forward from but not back.

Where MySQL 26.7 fits in a production estate

MySQL 26.7 is the most substantial Innovation release since the track was introduced, and for once the interesting parts are not previews. The Community thread pool solves a concurrency problem that used to cost an Enterprise subscription or a switch to Percona Server. The Change Stream Applier is a genuinely new replication architecture, and any estate that has fought replica lag with replica_parallel_workers tuning should benchmark it. The MYSQL communication stack default and post-quantum TLS are both changes you can defer, but not ignore.

The deployment answer for most fleets is still 9.7 LTS for anything that has to stay put, with MySQL 26.7 on replicas and on quarterly-refreshed tiers where the CSA and the thread pool pay for the operational cadence. Whichever way you go, the version ladder is fixed: 8.0 to 8.4 to 9.7, adjacent only, and 8.0 is already out of patches.

If you want a second pair of eyes on an upgrade plan, a Change Stream Applier benchmark or a Group Replication stack migration, our MySQL consulting and MySQL upgrade and migration teams do this work every week across Community, Enterprise and Percona builds. As always: test every change here on a non-production copy first, and keep the DR posture verified before the upgrade window, not after.

References

MySQL 26.7.0 release notes · MySQL 9.7.2 release notes · Oracle: MySQL July 2026 GA releases · Oracle: Introducing the Change Stream Applier · Thread pool operation, MySQL 26.7 reference manual · Group Replication communication stacks · MySQL end-of-life notice · Ronald Bradford: a first look at MySQL 26.7 Early Access