Introduction

Replication performance depends on every stage in the pipeline, from the source database to transport and ultimately to commit on the replica. On the replica side, much of that performance comes down to how efficiently changes are read, scheduled, and applied under real operational pressure. In practice, that directly affects steady-state lag, backlog recovery after bursts, and catch-up time after maintenance or network interruptions.

This post introduces a MySQL Labs Release that includes a new implementation of the replica log applier: the Change Stream Applier (CSA). The Change Stream Applier explores a different execution model for parallel replication, with a focus on improved backlog recovery, higher throughput in tested scenarios, and a more modular foundation for future applier work.

For operators running write-heavy environments, the applier is often where replication either keeps pace or falls behind. In practice, that affects not only steady-state performance, but also how quickly a replica can recover after interruptions or absorb bursts of accumulated relay-log work.

The Change Stream Applier is designed to:

  • improve throughput in tested workloads
  • increase backlog drain rate and reduce catch-up time in tested scenarios
  • provide a modular foundation for future features

Motivation

The existing multi-threaded applier (MTA) has served MySQL well across a broad range of replication workloads. The Change Stream Applier (CSA) builds on that foundation while exploring a different execution model aimed at workloads where greater parallelism and faster backlog drain can make a meaningful operational difference.

In practice, replicas need to do more than keep up during steady-state traffic. They also need to absorb bursts, recover after interruptions, and catch up efficiently when relay-log backlog accumulates. The Change Stream Applier was developed to improve behavior in those situations while preserving the replication guarantees operators expect.

The Change Stream Applier adds another applier design option in MySQL, with a focus on modularity, backlog recovery, and channel-level control. For the MySQL community, two aspects are especially worth watching:

  • better catch-up behavior for row-based GTID replication workloads
  • a more modular apply engine that is easier to extend over time

You can download the MySQL Labs Release for the Change Stream Applier from MySQL Labs.

Disclaimer

DISCLAIMER: This is a Labs Release of MySQL Community Edition provided specifically for community testing, evaluation, and feedback purposes.

Oracle does not recommend using this build with production products, services, or databases, or for any other production purpose.

Nature of the Build: Labs Release builds have undergone limited testing and are provided “AS IS.” They may contain bugs, security vulnerabilities, or experimental features, and they are not warranted to be error-free. Use of this build is entirely at your own risk. Oracle does not provide technical support for Labs Release builds, and there is no guaranteed upgrade path to future Labs Release or General Availability (GA) releases.

Non-Commitment and Future Functionality: The features and functionality in this MySQL build are subject to change at any time. Their presence should not be relied upon in making purchasing decisions. Nothing in this build should be interpreted as a commitment to deliver any software, code, or functionality in a future release, and you should not rely on the future availability of any feature or functionality in the product.

We value your feedback. If you encounter bugs or performance issues during your evaluation, please report them through our community tracker, bugs.mysql.com, under the “MySQL Server: Replication” category.

How It Works

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

At a high level, the Change Stream Applier organizes provider, dependency adaptation, scheduling, execution, session management, and resource governance into more explicit components. That makes it possible to change how work moves through the applier while preserving the replication guarantees operators expect. In practice, that enables several important behavior changes:

  • Later independent transactions can continue moving forward while earlier transactions wait on dependencies.
  • Apply progression and commit progression are separated.
  • With replica-preserve-commit-order enabled, commit order is preserved while avoidable worker parking is reduced in many cases.
  • Relay-log events are read closer to execution time and released after use.

From a user perspective, the Change Stream Applier is still an applier, but it gives MySQL another execution model for parallel replication, with an emphasis on backlog recovery, channel-level governance, and future extensibility.

Performance

Let us start by comparing the existing multi-threaded applier (MTA) with the Change Stream Applier (CSA).

In this Labs benchmark set, results were encouraging, with the strongest backlog gains appearing in lighter durability profiles.

In this section, NOLOGS refers to runs with compression OFF, binlog OFF, redo OFF, and replica-preserve-commit-order OFF. Suffixes such as +REDO and +RPCO indicate which options were enabled for a given run. DEFAULT refers to the fully loaded profile used here, with binlog ON, redo ON, and replica-preserve-commit-order ON, without compression.

Across these 64-worker benchmark runs, the Change Stream Applier usually outperformed MTA in both online apply and catch-up scenarios. In the DEFAULT profile, online throughput improved by about 45% in the 10-update workload (10.5k TPS vs. 7.22k TPS). The largest backlog gains in this set appeared in lighter durability configurations, where representative results included:

  • 54.5k vs. 49.7k in NOLOGS (1 update)
  • 43.8k vs. 36k in NOLOGS+REDO (1 update)
  • 30.2k vs. 10.6k in NOLOGS (10 updates)
  • 25.5k vs. 9.22k in NOLOGS+RPCO (10 updates)

These results suggest that the Change Stream Applier may be especially useful when the goal is to reduce backlog and shorten catch-up time after bursts or maintenance windows, particularly in configurations with less logging and durability overhead.

The results also show that the Change Stream Applier does not outperform MTA uniformly across all tested configurations. Under more durable or compression-heavy configurations, backlog gains were smaller, and in some runs MTA still came out ahead. Resource behavior also varied by workload: in many backlog runs, the Change Stream Applier used more CPU because it completed the work faster.

This benchmark set remains a micro-benchmark, not a full production proxy. It is useful for comparing steady-state throughput and backlog drain behavior, but it does not fully represent conflict-heavy hot rows, multi-channel interference, or long-haul operational tails.

Benchmark Methodology

We present 64-worker benchmarks comparing the Change Stream Applier (CSA) and the multi-threaded applier (MTA) using sysbench oltp_write_only with non-index updates across both online and backlog scenarios, focusing on 1-update and 10-updates transaction profiles.

The setup used three machines:

  • source server for online runs: 32 logical cores, 256 GB RAM, SR-IOV networking, 4 x 1 TB 20 VPU block volumes in LVM RAID 0, CPU boost disabled
  • replica server for online runs and backlog execution: 32 logical cores, 256 GB RAM, SR-IOV networking, 4 x 1 TB 20 VPU block volumes in LVM RAID 0, CPU boost disabled
  • client machine: 8 logical cores, 256 GB RAM, SR-IOV networking, and the same storage layout

The workload used 8 tables with 8,000,000 rows each, 256 sysbench threads, 600 seconds, and 1,000,000 events. To maximize write pressure, the workload used non-index updates only, with index updates and delete-insert operations disabled.

Unless stated otherwise, the applier worker count was 64. The benchmark matrix varied transaction compression, redo logging, log-replica-updates, and replica-preserve-commit-order. Results in this post were collected using mysql-9.7.0-labs-csa (Early Release).

Requirements and Limitations

The Change Stream Applier (CSA) is currently optimized for row-based GTID replication. In this Labs Release, it focuses on a narrower scope than the multi-threaded applier (MTA) rather than trying to cover every existing replication path.

Requirements

  • Row-based replication (REQUIRE_ROW_FORMAT=1)
  • GTID-only mode (GTID_ONLY=1)

Limitations

  • No support for deprecated binary log formats: statement or mixed
  • No support for filename/offset replication channels
  • No support for delayed applier mode (SOURCE_DELAY > 0)
  • No support for ASSIGN_GTIDS_TO_ANONYMOUS_TRANSACTIONS
  • No support for extended applier statistics
  • No support for replica_pending_jobs_size_max (replaced with per-channel APPLIER_EVENT_MEMORY_LIMIT)

Outside GTID-only operation, the following paths remain out of scope:

  • No support for UNTIL clauses other than SQL_BEFORE_GTIDS and SQL_AFTER_GTIDS
  • No support for sql-replica-skip-counter
  • No support for IGNORE_SERVER_IDS in CHANGE REPLICATION SOURCE TO

Configuring and Evaluating the Change Stream Applier

The Change Stream Applier (CSA) is configured per channel using CHANGE REPLICATION SOURCE TO. In this Labs Release, CSA is easiest to evaluate on channels that already use row-based replication and GTID-only mode.

CSA introduces the following configuration parameters:

  • APPLIER_VERSION (1 = MTA, 2 = CSA)
  • APPLIER_WORKER_COUNT (CSA only; range 1..1024)
  • APPLIER_EVENT_MEMORY_LIMIT (CSA only; values below replica_max_allowed_packet are raised to that minimum with a warning)

APPLIER_EVENT_MEMORY_LIMIT defines a per-channel memory budget for cached binlog events in the Change Stream Applier, helping keep apply memory bounded under backlog pressure. These parameters are persisted and survive instance restarts.

Example:

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

For evaluation, a practical rollout is to begin with a non-critical channel that already uses row-based replication and GTID-only mode. Start with the same worker count used for MTA, then measure backlog drain time and lag behavior during representative peaks. From there, tune worker count and event-memory limit per channel as needed.

As with other CHANGE REPLICATION SOURCE TO parameters, CSA configuration is visible in Performance Schema:

SELECT *
  FROM performance_schema.replication_applier_configuration;

For runtime statistics, the same Performance Schema views commonly used with MTA can also be used to observe the Change Stream Applier.

Low-Level Details

The Change Stream Applier (CSA) is a new architectural approach, not just a tuning pass.

Key design changes include:

  • Explicit separation of provider, replication storage (for example, relay-log access), dependency adaptation, scheduler, thread pool, session service, statistics monitor, and resource monitor
  • Reusable concurrency and scheduling libraries in libs/mysql/concurrency and libs/mysql/scheduler
  • A read-near-execution, release-after-use event lifecycle
  • Subscriber-driven relay-log purge for earlier safe file reclamation
  • Explicit stop orchestration for more responsive shutdown behavior

That matters beyond this first Labs Release. It gives MySQL a cleaner path for follow-on work, including future support for changing worker count without stopping the applier, alternative relay-log storage backends, and earlier scheduling opportunities for long transactions.

For readers who want additional implementation detail, the corresponding worklog design is available here.

How To Provide Feedback

Feedback is very welcome. When sending feedback, please include exact build information and a reproducible scenario.

Priority feedback areas include:

  • Regressions versus previous versions
  • Upgrade and downgrade behavior
  • Performance deltas, whether positive or negative
  • Replication and HA edge cases, including Group Replication and InnoDB Cluster
  • Feedback on new features

You can reach the development team through the usual community channels:

When filing a bug, please include:

  • Exact Early Release build identifier and platform (for example, mysql-9.7.0-labs-csa), under the category MySQL Server: Replication
  • Minimal reproducible steps
  • Expected versus actual behavior
  • Configuration and relevant logs or errors

Conclusion

The Change Stream Applier (CSA) introduces a new replication applier for MySQL aimed at two practical goals: better parallel apply throughput and faster backlog recovery. In the current 64-worker benchmark set, the Change Stream Applier usually improved online apply performance, while the largest catch-up gains appeared in lighter durability configurations. More durable and compression-heavy cases showed smaller or mixed results.

For operators already using row-based GTID replication, the Change Stream Applier is worth testing in non-production environments. If these early results hold across broader workloads, CSA could improve day-to-day replication behavior while also providing a stronger architectural base for future applier work.

Please try this feature preview and let us know what you think.