February 13, 2026
Ghost deletes get receipts
MySQL Foreign Key Cascade Operations Hit the Binary Log
MySQL finally shows its “hidden deletes” — cheers, jeers, and Postgres shade
TLDR: MySQL 9.6 now logs cascade deletes/updates so replicas and data streams see every change. Commenters celebrated the long-overdue fix while Postgres fans mocked and performance skeptics warned about slower writes—kicking off a fresh “correctness vs speed” debate that matters for anyone syncing or auditing data.
MySQL just did a big grown‑up thing: in 9.6, those “invisible” chain reactions when you delete a record (called cascades) finally show up in the change log. Translation: replicas and Change Data Capture tools like Debezium and Readyset can see every row that gets zapped, not just the first domino. It’s possible because foreign key rules moved from the storage engine to the SQL layer. For non‑DB folks: this helps stop “ghost” data and messy surprises during replication. The long‑running 2007 bug report? Considered addressed.
The comments, though, turned into a backyard barbecue. Performance hawks like XCSme asked, “Am I crazy to turn off the binlog?” and a crowd shouted back: not crazy—just choosing speed over receipts. Postgres fans strutted in with “This is why we use Postgres” energy, dropping the classic “footgun” meme. Meanwhile, data engineers are popping confetti because their pipelines finally capture the full story, while cautious admins are clutching pearls over upgrade paths and write overhead. Jokes flew—“ghost deletes got receipts,” “InnoDB’s secret garden now has a hall monitor,” and “MySQL in 2026 fixing 2007 is peak tech.” Love it or roast it, the vibe is clear: correctness vs. performance is back on the main stage, with MySQL taking a bow for finally making the cascades visible.
Key Points
- •MySQL 9.6 (Jan 20, 2026) moves foreign key enforcement to the SQL layer so cascaded operations are recorded in the binary log.
- •Previously, InnoDB executed cascades internally, making child-row changes invisible to the server and binlog under both SBR and RBR.
- •A worked example shows only the parent DELETE appearing in SHOW BINLOG EVENTS, with no entries for cascaded child deletes.
- •The legacy workaround required identical InnoDB FK definitions on replicas; it failed with non-FK engines like MyISAM or RocksDB.
- •CDC tools that read the binlog (e.g., Readyset, Debezium) previously missed cascaded events; the 9.6 change improves CDC and replication correctness.