MySQL Binary Logs From Replication Tool to Enterprise Event Platform
summary
Percona 8.4 production uses MySQL binary logs as a live change bus: Debezium reads row-format binlogs (some tables written to a black hole engine shadow table) and publishes invalidation events to Kafka so hundreds of app servers clear caches; analytics stream to ClickHouse/BigQuery. Binary-log GTIDs plus original and immediate commit timestamps expose replication lag — a 2s spike traced to single transactions touching millions of rows and fixed by breaking them into smaller batches. Forensics use base64-decoded binlog rows and PMM dashboards; recommend sync_binlog=1, row_image=FULL, enforce_gtid_consistency.
AI-written summary · about
chapters (10)
- 0:00MySQL binary logs beyond replication
- 1:29Binary logs as event platform
- 3:17Change data capture and cache invalidation
- 7:52Real-time analytics with binary logs
- 9:58Monitoring replication lag
- 12:45Resolving replication lag
- 15:13Forensic analysis and incident response
- 17:19MySQL config for binary logs
- 18:21Key takeaways and tools
- 19:52Q&A
related talks
52mMySQL replication deep dive, and ideas for PostgreSQL
50mMySQL 8.0 at 4. Where are we now?
22mMySQL Replication: Latest Developments
49mMySQL Replication — Advanced Features
22mReliable Data Replication
26mUnderstanding MySQL Concepts
53mMySQL replication setup, benefits, limitations
51mReplication latest features: the community sceptic roundup