Learn
How long to keep MySQL binary logs for CDC
Why binary log retention decides whether MySQL CDC can recover from an outage, what to set it to, and how to change it on RDS, Aurora, Cloud SQL and Azure.
A CDC pipeline reads MySQL's binary log from a saved position. If it stops (an outage, a network change, a paused pipeline) and MySQL deletes the logs it hasn't read yet, it can't continue: the tables have to be copied again.
What to set
Keep at least 3 days, ideally 7, so a problem that starts on a Friday evening can be fixed on Monday. Binary logs take disk space roughly proportional to your write volume, so check free storage after raising it.
By host
- Self-hosted MySQL 8:
SET PERSIST binlog_expire_logs_seconds = 604800;(7 days; MySQL 8's default is 30 days). - Amazon RDS and Aurora:
CALL mysql.rds_set_configuration('binlog retention hours', 168);and check withCALL mysql.rds_show_configuration;. Without it, RDS can remove binary logs soon after they're written. - Google Cloud SQL: binary logs are kept for the point-in-time recovery window; set the transaction log retention in days on the instance.
- Azure Database for MySQL: set the
binlog_expire_logs_secondsserver parameter.
How Quayen helps
The connection test checks the retention and warns if it's too short. If logs were already purged when a pipeline resumes, Quayen says so plainly and lets you re-copy the affected tables instead of silently skipping changes.