Master binary logs taking a lot of space and not being purged.

Question

I've been having an issue with available space on my master RDS instance. It seems that the binary logs are not getting removed. Running show master logs; and summing up the file size (assuming that value is bytes) it's totaling 550gb in size. It's more that than table space totals for my data.   
  
A few things:  
  
The master is a multi AZ system   
I've run a read replica for a while.   
I've had two issues in the past where I ran out of space. I provisioned more, but on the second time, the relica would not resume replication. It was stuck at -1. I deleted that replica and started a new one, which got caught up and has been replicating fine.  
I have a script that generates a new replica to run dB dumps from for an external backup that occurs once a day.  
  
I've tried setting the retention to null on the logs, but it does not seem to purge the logs.  
I also tried a snapshot, but that didn't do anything either.  
  
I was going to try removing my my read replica while leaving the retention period null to see if that would cause them to clear out.  Could this be caused by the mutli-az setup?   
  
Other options to free that space? I'd prefer not having to continue scale up EBS volume size when less than 50% is actually usable storage space.   
  
Should I expect these binary logs to purge? If not, do I avoid using read replication then?   
  
Thanks

Answer

A quick update, removing the read replicas and setting retention period to null didn't cause the logs to purge.  
  
Do snapshots utilize the binary logs or are snapshots self contained once finished?

Answer

Update 2 On this issue.   
  
I tried removing some old snapshots and also doing a reboot of the master database without a failover. Neither of those cleaned up the binlogs.   
  
What I ended up having to do was take my read replica, making sure there was no lag in replication, then promoting it to master, switching the host of the master database to a new name, then renaming the newly promoted read replica as the origin master's hostname.  That allowed operations to resume and I didn't have the binlogs on the new database, freeing up about 500GB of space.   
  
I'm setting back up a read replica now to see if the binlogs rotate like they should.   
  
It would still be nice to learn why those logs didn't rotate though.  If it's a matter of a stuck job or something, having an interface into that insight or a way to force the job to run would be a good addition to the RDS interface.

Answer

Hi Pete,

executing stored procedure below reduces binlog to min as soon as replica is in sync:

`CALL mysql.rds_set_configuration('binlog retention hours', NULL)`

Reference:

"The default value of binlog retention hours is NULL. For RDS for MySQL, NULL means binary logs aren't retained (0 hours)."
[https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/mysql-stored-proc-configuring.html]()

Master binary logs taking a lot of space and not being purged.

Relevant content