Description:
MySQL Replication remains central to high availability, scale-out reads, disaster recovery, and data movement, but its performance requirements continue to grow. This discussion invites concrete suggestions for improving replication throughput, latency, recovery time, and operational efficiency. The goal is to collect practical input from engineers, operators, and users who have seen replication limits in production and can explain which improvements would matter most.
Several areas deserve focused discussion. Streaming replication could reduce latency by moving changes through the pipeline earlier and with less batching delay. Combining logical and physical logs may create faster recovery or provisioning paths by using the most efficient representation for each phase of replication. An opt-in relay log model could reduce disk and I/O overhead for deployments that do not need the full relay log durability behavior, while still preserving correctness for users that do.
Commit processing is another important area. Batch commit of transactions can reduce per-transaction overhead and help replicas apply work more efficiently. Binlog Group Commit enhancements may improve source-side throughput by better aligning binary log coordination, storage-engine commit, and durability work. Suggestions in this area should consider both source and replica benefits, since an improvement that optimizes one side may also provide useful primitives for the other.
The binary log infrastructure itself is also a candidate for modernization. Removing `IO_CACHE` from the binlog infrastructure may simplify the code path and allow more efficient buffering or I/O strategies. Additional metadata in the binary log, including user-specific metadata, could make downstream processing, auditing, filtering, and troubleshooting more efficient. The challenge is to add useful context without increasing overhead for workloads that do not need it.
Replication can also benefit from a stronger change data capture framework and enhanced replication filters. A formal CDC framework could make it easier for internal and external consumers to read changes safely and efficiently without duplicating binlog parsing logic. More capable replication filters could reduce unnecessary data movement and apply work closer to the source of the decision, improving performance for selective replication, migration, and integration use cases.
Contributions are most useful when they describe the workload, the observed bottleneck, and the expected benefit of the proposed change. Strong suggestions should explain whether they target source throughput, replica apply speed, network efficiency, disk usage, failover, recovery, observability, or operational simplicity. By collecting input across these areas, MySQL can prioritize replication improvements that reduce lag, increase throughput, and make replication easier to operate under demanding production conditions.
How to repeat:
Please see description.
