Skip to content

CONCEPT Cited by 1 source

Separate binlog disk

Definition

A separate binlog disk is a MySQL operational posture in which the binary log (binlog) — the sequential append-only log of every committed transaction — is stored on a different physical volume from the one holding the database's data files (InnoDB tablespaces, indexes, undo logs). The two workloads — sequential binlog appends and random InnoDB page I/O — contend for the same volume's IOPS and throughput budget when co-located; separating them gives each its own budget and makes the database write path materially faster under load.

The canonical framing — Morrison on PlanetScale

Brian Morrison II's 2023-11-15 best-practices post canonicalises this operational rule:

"As mentioned earlier in this article, each replica in your environment will read from the binary logs of the source as their source of truth. By default, these logs are stored on the same disk as the database. As you can imagine, busy databases can be bogged down when you consider the amount of throughput being processed by a single disk (manipulating the database + reading binary logs for replication). That said, the better approach would be to store binary logs on a separate disk than the database. This approach can also save you some money in cloud environments where free volumes have hard IOPS limits." (Source: sources/2026-04-21-planetscale-mysql-replication-best-practices-and-considerations)

Two load-bearing arguments:

  1. Performance — database + binlog I/O on one disk multiplies load on the same volume. Separating them halves per-volume pressure.
  2. Cost — in the cloud (AWS EBS specifically), volumes have per-volume IOPS caps. Distributing load across two volumes means each can live in the cheaper IOPS tier, avoiding the gp3 → io1/io2 cost cliff.

The I/O pattern asymmetry

The binlog and the data files have opposite I/O shapes that compete poorly on the same volume:

Workload Pattern Optimal hardware
Binlog Pure sequential append; one writer; large sequential reads (replica tailing) Throughput-optimised; benefits from sequential-IO accounting on EBS
InnoDB data files Random read/write (buffer-pool spill + page fetch + checkpoint flush + secondary-index maintenance) IOPS-optimised; benefits from provisioned-IOPS premium tiers

When co-located: - Every binlog fsync flushes the shared disk's write cache, slowing subsequent InnoDB writes. - Every InnoDB page read competes with the replica's binlog-tailing reads. - Burst-bucket depletion happens faster because both workloads drain the same bucket.

When separated: - Each volume can be sized (throughput for binlog, IOPS for data) independently. - Fsync of one doesn't block I/O on the other. - Cloud cost is typically lower because neither volume needs the premium-tier cap.

Ties to the cloud-IOPS-cost story

The "save you some money" argument lands directly in the framing canonicalised in Ben Dicken's 2024-08-19 IOPS-cost post: the cliff between gp3 (up to 16,000 IOPS / 1,000 MiB/s at cheap flat rate) and io1/io2 (up to 256,000 IOPS / 4,000 MiB/s at 11-13× cost) is a regime shift, not a gradient. Co-locating binlog + data on one volume pushes the combined workload across the cliff sooner. Separating them keeps each workload in the cheap tier longer — and at sufficient scale, the split itself substitutes for upgrading to provisioned-IOPS storage.

Same structural argument as Dicken's sharding-as-IOPS-scaling — split the workload to avoid the cliff, whether at the volume level (binlog + data) or at the shard level (one primary per shard).

Operational considerations

The post canonicalises the rule but doesn't detail mechanics. In practice:

  • MySQL configuration: log-bin=/path/on/separate/volume/binlog-name in my.cnf, with the new volume mounted at that path.
  • Volume sizing: binlog volume sized for retention × write rate × replication lag cushion; data volume sized for working set + growth.
  • On existing systems: moving binlogs requires either a restart with log-bin pointed at the new path (binlog file rotation happens automatically; old binlogs remain readable but no new ones are written to the old path), or — for zero-downtime migration — replica-promotion-with-rebuild (take a replica offline, reconfigure its binlog path, rebuild, promote to primary, repeat).
  • Cross-AZ / failure isolation: the binlog volume can be attached to a different availability zone or storage tier than the data volume, but both must remain accessible to the MySQL process; neither gains from being on a different host.

Generalisation

The same pattern applies to Postgres's WAL (write-ahead log), commonly separated from data via pg_wal on a separate volume — same sequential-vs-random-I/O argument, same cloud-economics consequence. In general: every database's append-only log has a different I/O shape than its random-I/O data files, and volume-level separation is a durable cross-engine operational hygiene rule.

Seen in

Last updated · 378 distilled / 1,213 read