Context
MySQL can experience write stalls when redo generation approaches the space available before checkpointing must advance. Increasing redo capacity may help a suitable workload, but it does not create unlimited flushing throughput. Diagnose generation rate, checkpoint progress, storage behavior, and recovery requirements before changing durability settings.
Separate redo from binary logging
InnoDB redo supports crash recovery of changes within the engine. Binary logs support a different set of replication and recovery workflows. Enlarging one does not automatically solve retention or capacity pressure in the other.
Record MySQL version, effective redo configuration, storage location, free space, durability settings, and recent workload changes. Current MySQL releases use innodb_redo_log_capacity; older releases have different configuration procedures. Use the exact version's supported method and never remove redo files manually as a tuning shortcut.
Measure generation and checkpoint progress
Inspect supported InnoDB status and metrics to compare current log sequence progress with the checkpoint horizon. Capture interval changes rather than one historical value. Relate the gap to the effective redo capacity and engine behavior documented for the installed version.
Measure redo generated per second during normal traffic, imports, and scheduled jobs. A bulk update can consume the available horizon much faster than ordinary operations. Include transaction size, commit rate, dirty-page behavior, storage latency, and application stalls.
Distinguish a growing backlog from a short peak that the system catches up with. An alert based only on bytes without a trend or workload context can be difficult to act on. Preserve synchronized observations from the engine and storage layer.
Determine whether capacity or throughput dominates
A larger redo space can provide more room for checkpoint behavior and reduce unnecessary pressure in an appropriate configuration. If the underlying storage cannot flush sustained dirty-page demand, extra capacity may merely delay the next stall.
Review application work as well. Large transactions, unnecessary updates, inefficient indexes, and overlapping maintenance can increase write amplification or burst size. Splitting a business operation must preserve its correctness contract; smaller batches are not automatically equivalent to one atomic transaction.
Assess storage queueing and latency during the event. A changed disk tier, competing backup, or instance-level I/O limit can reduce checkpoint progress even when redo settings did not change. Avoid using a configuration increase to conceal a separate storage regression.
An illustrative import slowdown
A nightly import generates a much larger write burst after a data-model change. The service begins pausing writes and the team considers weakening commit durability. Evidence instead shows rapid redo generation and constrained flushing during a competing backup.
The team tests a reviewed redo-capacity adjustment, revised import batching with correct semantics, and scheduling separation. It validates crash recovery on a test copy. The production change preserves the agreed durability contract and is accepted on completed imports and interactive latency.
Quick diagnostic map
| Evidence | Hypothesis | Next check |
|---|---|---|
| Checkpoint gap grows rapidly during imports | Burst exceeds current headroom | Redo generation and capacity |
| Larger capacity delays but does not remove stalls | Sustained flush bottleneck | Storage and dirty-page throughput |
| Redo stable; binary logs fill disk | Different log lifecycle | Replication and binlog retention |
| Stalls align with backup overlap | Shared I/O contention | Aggregate storage activity |
A focused operator exercise
Use a test database with representative data and the same MySQL major version. Record redo settings, storage characteristics, transaction profile, and application acceptance targets. Replay the bounded import and normal traffic together while collecting checkpoint and latency evidence.
Change one supported setting or workload behavior at a time. Measure peak disk usage and perform a controlled recovery rehearsal on the disposable environment. Validate row counts, business invariants, import completion, and recovery duration. Keep a rollback configuration and enough free space for the supported resize procedure.
Include recovery in sizing
Redo capacity affects the operating envelope and can influence recovery work. Evaluate startup and recovery behavior rather than selecting the largest supported value by default. Keep the accepted size and its workload assumptions in reviewed configuration.
Frequently asked questions
Does increasing redo capacity always fix write latency?
No. Storage flushing, transaction shape, and other contention can remain limiting. Measure whether the backlog eventually catches up.
Should I reduce durability to improve the benchmark?
That changes the recovery contract. Investigate capacity and workload causes first and evaluate any durability decision separately with explicit requirements.
Continue the investigation
- MySQL Binary Logs: Size Retention for Offline Consumers
- Linux Iowait: Connect CPU Accounting to Storage Evidence
Browse the cloud, server and infrastructure guide library for related operational questions.
Explore Clouvenix MySQL Administration & Query Tuning to discuss implementation, validation and operational handover.
Technical reference
MySQL :: MySQL 8.4 Reference Manual :: 10.5.4 Optimizing InnoDB Redo Logging
MySQL :: MySQL 8.4 Reference Manual :: 17.8.1 InnoDB Startup Configuration