Skip to content

CONCEPT Cited by 1 source

InnoDB silent cascade in binlog

Definition

InnoDB silent cascade in binlog is the architectural property — specific to MySQL + InnoDB — that when a parent-side DELETE or UPDATE fires foreign-key cascading actions (ON DELETE CASCADE / ON UPDATE CASCADE / ON DELETE SET NULL / ON UPDATE SET NULL), the resulting child-row writes are applied inside the InnoDB storage engine and are never written to the binary log. Only the original parent-side statement makes it into the binlog.

Canonical verbatim framing (Noach + Gupta, 2023):

"any cascading of operations (say an ON DELETE SET NULL or ON UPDATE CASCADE) is only done by InnoDB. If you DELETE or UPDATE a row on a parent table, and that, in turn, affects rows in a child table, those changes to the child are done internally in InnoDB, and are never logged to the binary log." (Source: sources/2026-04-21-planetscale-the-challenges-of-supporting-foreign-key-constraints)

Why MySQL designed it this way

MySQL's storage-engine architecture historically split responsibility: the server layer managed parsing, plans, and the binlog; storage engines (InnoDB, MyISAM, NDB, ...) managed row storage. Foreign keys arrived as an InnoDB-specific extension, not a server-layer feature. A never-completed server-level FK effort was abandoned once Oracle consolidated both MySQL and InnoDB — InnoDB owns FK logic, and the binlog reflects only the server-layer statements.

MySQL compensates on the replication path by trusting the replica's InnoDB to replay the cascade identically. If primary and replica both run InnoDB with the same FK schema, the replica applies the parent-side statement, and its local InnoDB re-executes the cascade. Consistency by symmetric re-execution, not by transport.

What breaks when the assumption is violated

Any consumer that tails the binlog but doesn't run InnoDB with the same FK schema sees the gap:

  • Change-Data-Capture tools (Debezium, VStream exposed to external drivers, Airbyte/Fivetran/PlanetScale Connect). They see the parent delete/update, they don't see the child cascades. Downstream tables drift. See concepts/change-data-capture.
  • Replicas with FKs stripped. Drop the child-table FKs on a replica via ALTER TABLE ... DROP FOREIGN KEY, keep replication running, watch replication break — or (worse) silently drift — as soon as the parent cascades something. The PlanetScale post uses this as a differential testing oracle (see patterns/mysql-compatible-differential-fuzzing applied to FK semantics): if Vitess is correctly handling cascades at the application layer, the replica sees every child-row change explicitly in the binlog, and a FK-stripped replica stays consistent. If Vitess is letting InnoDB do any of the cascading, the FK-stripped replica drifts — test failure.
  • Snapshot-plus-catch-up replication tools (VReplication, gh-ost). These rely on the binlog being the authoritative record of every committed change. If the shadow / target table has the same FKs as the source, InnoDB on the target runs its own cascade — but only if the target row already exists. During backfill, only partial data is present, so the target's InnoDB can't reliably re-apply. See patterns/shadow-table-online-schema-change for why this forces either shadow tables to be FK-exempt or a different snapshot strategy (single-bulk-snapshot + tail, instead of alternating copy+tail, for Database Imports with cascading FKs).

Why Vitess reimplemented FK logic above MySQL

PlanetScale considered patching InnoDB to log cascades into the binlog. They chose not to, for four reasons:

  1. InnoDB's codebase is "very much detached from the MySQL codebase" — parallel constructs, high risk to modify.
  2. Adding FK logic to Vitess is also a lot of work, but Vitess maintainers have "clarity of the scope of work"; risk is low.
  3. A cross-shard future requires FK logic above MySQL anyway — the binlog cascade-gap would persist even if patched on a single server. Cross-server FK enforcement needs a logical layer that understands the shard topology; that layer is Vitess, not MySQL.
  4. The trade-off "more locking and more communication with the MySQL server" is accepted in exchange for the cross-shard roadmap.

See concepts/vitess-foreign-key-enforcement for the application-level implementation.

Load-bearing position in the Vitess FK story

This single property is the root cause of every architectural challenge in the 2023-12-05 post:

  • Online DDL breaks because shadow tables with the same FKs as the source interfere with parent writes — fix: FK-exempt shadow tables via MySQL-fork patch.
  • Query serving diverges from the normal "delegate to MySQL" pattern — fix: Vitess orchestrates cascade by hand.
  • Database Imports can't use alternating snapshot+tail — fix: single-bulk-snapshot then tail, modelled after a point-in-time recovery, for FK tables with cascading actions.
  • Differential testing becomes possible — use the gap as an oracle: FK-stripped replicas will drift iff Vitess is doing something wrong.

Seen in

  • sources/2026-04-21-planetscale-the-challenges-of-supporting-foreign-key-constraints — canonical wiki home for the concept. Verbatim quote above + the four architectural consequences Noach + Gupta walk through. "By way of experiment (not on your production environment), try removing the foreign key constraints on a replica server, then see how long it takes for replication to break." — the quote that makes the concept operationally grounded.
Last updated · 550 distilled / 1,221 read