Download the New 2026 State of Open Source Database Management Report

Downloads

Blog

Meet MySQL 26.7: A New Versioning Era Begins

October 12, 2026

Author

Share this Post:

Over the period, we have witnessed how MySQL versioning evolved from 8.0 to 9.7 LTS, and now it has entered a new era: a calendar-based model.

Let’s first take a brief look at how MySQL versioning has evolved over time.

Phase 1 – MySQL 8.0 (2018–2026) used a traditional single-track release model, with all new features and bug fixes rolled into the same 8.0 release line.
Phase 2 – Oracle launches an Innovative/LTS dual-track model (Mid 2023). Innovation releases focus on new features and changes to short-lived performance on a quarterly basis. The LTS (Long Term Stable) release is steadier and has a long lifespan, with a cycle of 5 years of Premier Support + 3 years of Extended Support, and it typically launches every 2 years.
Phase 3 – There are chains of Innovation releases following (8.1, 8.2, 8.3) between (2023- 2024), leading to the first LTS (8.4) in April 2024.
Phase 4 – There was a shift in the Innovative versioning numbering, and we moved in the next 9.7 series. v9.0 to v9.6 are part of the Innovative release model (2024-26). We got our second LTS (9.7) in April 2026, with a 5-year Premier Support cycle followed by 3 years of Extended Support.

After going through all those phases, we have finally reached a major shift in the overall versioning model. Instead of the next Innovation release to v9.8, Oracle switched to calendar versioning mode (Year.Month.Patch). So, the new Innovative release shipped as v26.7.0 instead of v9.8.

Now, let’s discuss the new versioning model a bit.

The new versioning model is denoted as Year.Month.Patch, or YY.M.P.

26 represents 2026(Year).
7 represents July (Month).
0 is the PATCH Number.

The same quarterly cycle is followed for each subsequent Innovative release; the only difference is that it now uses the calendar versioning model. For example, the next innovation release would tentatively be v26.10.0, scheduled for launch in October 2026.

The LTS release can also be considered roughly every 2 years under the new versioning model. The next LTS release in the new scheme is expected in April 2028 as 28.4.0.

Why choose the new Versioning Model?

The real advantage we see is that with the format (Year.Month.Patch), we can better assess when releases/packages were shipped and how they relate to overall release planning (Innovative/LTS, etc.). This was a problem with the previous versioning model, say 8.4/9.7, as we don’t get much clue or information.

This has no impact on the existing LTS (8.4/9.7); they will get the usual quarterly maintenance updates (bug fixes and security patches) while all Innovation or new features are offered under the new Calendar series.

How does the upgrade cycle work?

MySQL 9.7.x LTS is the sole entry point into the first calendar-versioned lineage 26.7.0, so we must first upgrade to 9.7 LTS if we need to go with a calendar version upgrade to 26.7.0.
8.4.x LTS or any previous version won’t simply work when considering upgrading to a new lineage.
Singe hope upgrade from v9.7.x LTS to 26.7.0 or any later release in that same lineage (e.g., 26.10.0, 27.1.0, 27.4.0) is still valid until the next LTS, v28.4.0.

E.g,

8.4.x LTS -> 9.7.x LTS -> 26.7.0

1	8.4.x LTS -> 9.7.x LTS -> 26.7.0

So if someone is still using an EOL version like 5.7, 8.0 has to follow the above path and upgrade to 8.4 LTS first.

What features and enhancements does v26.7 bring to the table?

1) Change Stream Applier for Multi-Threaded Replication

The new change stream applier (CSA) introduces further improvements to parallel transaction scheduling and execution. The original model, Multi-threaded Applier (MTA), basically uses a coordinator to read transactions sequentially from the relay files and then hand them off to worker threads for parallel applying and execution. This can be a limitation, especially when a worker thread is waiting/sitting Idle for a commit due to any prior or dependency transaction.

Change stream applier (CSA) basically separates the transaction applying from commit ordering. For example, if a worker finishes applying a transaction but has to wait for the commit order, it can work on another dependency-ready transaction instead.

The replication configurations below are introduced by CSR adoption. Please note that it works for each channel separately.

APPLIER_VERSION  -  “1” denotes for MTA and “2“ denotes for CSA
APPLIER_WORKER_COUNT - different worker count based on each replication channel 
APPLIER_EVENT_MEMORY_LIMIT - Per-channel memory limits for cached binlog events

APPLIER_VERSION - “1” denotes for MTA and “2“ denotes for CSA

APPLIER_WORKER_COUNT - different worker count based on each replication channel

APPLIER_EVENT_MEMORY_LIMIT - Per-channel memory limits for cached binlog events

CSA has some more added advantages:

CSA workers can simultaneously read transaction events from the relay log and release event memory when events are consumed.
Relay log files can also be marked for concurrent purging once all transactions have been applied successfully and there is nothing left to read from the relay files.

How to apply the change stream applier?

mysql> STOP REPLICA FOR CHANNEL 'mysql1';

1	mysql> STOP REPLICA FOR CHANNEL 'mysql1';

mysql> CHANGE REPLICATION SOURCE TO
APPLIER_VERSION = 2,
APPLIER_WORKER_COUNT = 8,
APPLIER_EVENT_MEMORY_LIMIT = 1073741824,
REQUIRE_ROW_FORMAT = 1,
GTID_ONLY = 1
FOR CHANNEL 'mysql1';

mysql> CHANGE REPLICATION SOURCE TO

APPLIER_VERSION = 2,

APPLIER_WORKER_COUNT = 8,

APPLIER_EVENT_MEMORY_LIMIT = 1073741824,

REQUIRE_ROW_FORMAT = 1,

GTID_ONLY = 1

FOR CHANNEL 'mysql1';

mysql> START REPLICA FOR CHANNEL 'mysql1';

1	mysql> START REPLICA FOR CHANNEL 'mysql1';

Requirements to use CSA

Row-Based replication (binlog_format=ROW)
GTID enforcement (gtid_mode=ON)

1 2	Row-Based replication (binlog_format=ROW) GTID enforcement (gtid_mode=ON)

2) Thread Pool Plugin

The good news is that the Thread Pool Plugin is now available in MySQL Community releases, removing the previous dependency on the Enterprise Edition to use the Thread Pool mechanism.

MySQL traditionally uses a one-thread-per-connection model, where each client connection creates a dedicated server thread. This approach can become a problem when an application establishes a very large number of concurrent connections, especially when many of those connections are Idle/Sleep(waiting for work).

The Thread Pool addresses this by managing a high volume of client connections through a smaller number of worker threads. So, instead of creating a new thread for each connection, the Thread Pool uses the connections from the existing pool of threads and schedules their work across a controlled number of worker threads.

This could be useful in an environment where applications trigger a very high number of concurrent database connections, and simply increasing max_connections is not an option, as it would lead to excessive thread creation and resource consumption during database setup.

How to enable the Thread Pool?

Load thread pool plugin

[mysqld]
plugin-load-add=thread_pool.so

1 2	[mysqld] plugin-load-add=thread_pool.so

Restart the database service

bash> Systemctl restart mysql

1	bash> Systemctl restart mysql

Verify plugin active

mysql >  SELECT PLUGIN_NAME, PLUGIN_STATUS
    ->        FROM INFORMATION_SCHEMA.PLUGINS
    ->        WHERE PLUGIN_NAME LIKE 'thread%';
+-------------+---------------+
| PLUGIN_NAME | PLUGIN_STATUS |
+-------------+---------------+
| thread_pool | ACTIVE        |
+-------------+---------------+
1 row in set (0.004 sec)

mysql > SELECT PLUGIN_NAME, PLUGIN_STATUS

-> FROM INFORMATION_SCHEMA.PLUGINS

-> WHERE PLUGIN_NAME LIKE 'thread%';

+-------------+---------------+

| PLUGIN_NAME | PLUGIN_STATUS |

+-------------+---------------+

| thread_pool | ACTIVE |

+-------------+---------------+

1 row in set (0.004 sec)

Thread Pool configuration/Monitoring

The thread pool size and other related parameters can be listed and configured as needed.

mysql> show variables like 'thread_pool%';
+----------------------------------------+-------+
| Variable_name                          | Value |
+----------------------------------------+-------+
| thread_pool_algorithm                  | 1     |
| thread_pool_connection_report_interval | 120   |
| thread_pool_dedicated_listeners        | OFF   |
| thread_pool_high_priority_connection   | 0     |
| thread_pool_longrun_trx_limit          | 2000  |
| thread_pool_max_active_query_threads   | 0     |
| thread_pool_max_transactions_limit     | 192   |
| thread_pool_max_unused_threads         | 32    |
| thread_pool_prio_kickup_timer          | 1000  |
| thread_pool_query_threads_per_group    | 2     |
| thread_pool_size                       | 6     |
| thread_pool_stall_limit                | 6     |
| thread_pool_transaction_delay          | 0     |
+----------------------------------------+-------+
13 rows in set (0.003 sec)

mysql> show variables like 'thread_pool%';

+----------------------------------------+-------+

| Variable_name | Value |

+----------------------------------------+-------+

| thread_pool_algorithm | 1 |

| thread_pool_connection_report_interval | 120 |

| thread_pool_dedicated_listeners | OFF |

| thread_pool_high_priority_connection | 0 |

| thread_pool_longrun_trx_limit | 2000 |

| thread_pool_max_active_query_threads | 0 |

| thread_pool_max_transactions_limit | 192 |

| thread_pool_max_unused_threads | 32 |

| thread_pool_prio_kickup_timer | 1000 |

| thread_pool_query_threads_per_group | 2 |

| thread_pool_size | 6 |

| thread_pool_stall_limit | 6 |

| thread_pool_transaction_delay | 0 |

+----------------------------------------+-------+

13 rows in set (0.003 sec)

Performance_schema provided a few tables to monitor thread pool activity, along with the status variables.

mysql > show tables like 'tp%';
+------------------------------------+
| Tables_in_performance_schema (tp%) |
+------------------------------------+
| tp_connections                     |
| tp_thread_group_state              |
| tp_thread_group_stats              |
| tp_thread_state                    |
+------------------------------------+
4 rows in set (0.001 sec)

mysql > show tables like 'tp%';

+------------------------------------+

| Tables_in_performance_schema (tp%) |

+------------------------------------+

| tp_connections |

| tp_thread_group_state |

| tp_thread_group_stats |

| tp_thread_state |

+------------------------------------+

4 rows in set (0.001 sec)

mysql>  show status like 'thread_pool_%';
+---------------------------+-------+
| Variable_name             | Value |
+---------------------------+-------+
| Thread_pool_query_threads | 14    |
+---------------------------+-------+
1 row in set (0.001 sec)

mysql> show status like 'thread_pool_%';

+---------------------------+-------+

| Variable_name | Value |

+---------------------------+-------+

| Thread_pool_query_threads | 14 |

+---------------------------+-------+

1 row in set (0.001 sec)

3) Undo Log Truncation Improvement

MySQL 26.7 improves the robustness of InnoDB undo tablespace truncation. Previously, InnoDB used a separate undo_{space_number}_trunc.log file to keep track of an undo tablespace truncation operation. This external file was used to determine whether a truncation operation was in progress, particularly during recovery.

Now this approach has changed: instead of maintaining a separate truncate log file, the truncation state is captured directly in the undo tablespace header.

This improves both undo truncation and recovery as it does not rely on a separate dedicated file.

4) InnoDB recovery and metadata infrastructure Improvement

There were some internal changes, or rather improvements, to the structure and efficiency of the core InnoDB recovery, metadata, redo-log, tablespace, and transaction-visibility code paths.

This doesn’t bring any changes to the usage point of view. The goal is to make these components easier to maintain, test, and extend without changing user-visible SQL semantics.

5) Group Replication default communication stack

The group_replication_communication_stack now defaults to “MySQL” from “XCOM”. This change is more aligned with the MySQL Server authentication and connection security.

This also means no separate communication port needs to be specified for group replication variables (group_replication_local_address and group_replication_group_seeds). The native MySQL port (3306)/ MEMBER_PORT or whatever is defined for MySQL nodes can be used instead.

In short, the default MySQL communication stack provides the benefits below.

Overall, it simplifies the creation of InnoDB Clusters by using MySQL Server’s connection security in place of the Group Replication implementation.
It removes the need for an extra network address or port for internal Group Replication communications.
Using the MySQL protocol means that standard user authentication methods can be used to grant or revoke access to the group, in place of the allow list.
Supports network namespaces for Group Replication.

Note – If migrating from the old environment or switching from “XCOM” to “MySQL” simply switching the communication stack wouldn’t work.

mysql> set global group_replication_communication_stack = 'MySQL';

1	mysql> set global group_replication_communication_stack = 'MySQL';

Group replication must be stopped on all members, and then the relevant changes should be applied. Finally, the cluster needs to be bootstrapped.

Basically, this activity requires downtime to successfully switch the communication stack.

Also, the XCom communication stack is deprecated and could be removed in future releases, so better to switch to the MySQL stack. Further complete release notes can be checked here – https://dev.mysql.com/doc/relnotes/mysql/26.7/en/news-26-7-0.html

Conclusion

The transition to MySQL 26.7 introduces a major shift to a calendar-based versioning scheme (Year.Month.Patch), providing clearer alignment with release timelines and future planning across both Innovation releases and long-term support cycles. Upgrading to this new series requires being on MySQL 9.7 LTS as the primary baseline before moving forward into the 26.x series.

Alongside versioning improvements, MySQL 26.7 delivers significant architecture and usability enhancements. Key features include the Change Stream Applier (CSA) for optimised parallel transaction execution and replication performance, as well as the native availability of the Thread Pool Plugin in Community editions to manage high-concurrency connections effectively without relying on Enterprise Edition extras.