-ripple_purge_expire_logs_days (Purge binlog files older than this days
(0=disable). This is evaluated independently of ripple_purge_keep_size.)
type: int32 default: 0
-ripple_purge_logs_keep_size (Purge binlog files if total size exeeds this
value (0=disable). This is evaluated independently of
ripple_purge_expire_logs_days.) type: uint64 default: 0

I am not sure if this is what you need. But if you have a multiple master you can use multiple rippled instances for the better purge tuning.

I am very interested in this, not so much for relaying to many, many slaves, but to see if it will serve as a temporary stop gap for very large MANY TB databases, as in 30TB, where their 3TB binlog space is not large enough to accommodate storing enough days to SAFELY do backups. The binlog data transfer on these databases is > 41GB per hour, so to date XTRABACKUP is unable to backup the data; continuously errors out on logs wrapping. Past experience we increased log file sizes from 2GB to 6GB and it usually resolved these issues, but as of recent not even 41GB log file sizes were enough.

In summary we are now LFTP..ing one of the databases offline slaves to rebuild it, thus the expire_logs_days issue risks shorting binlog space while we risk an estimated 3.5 day copy with 6 days of logs.

Yes I would love to redesign these databases, sharding to multiple smaller nodes, but management has been unwilling to improve its design. Any insights appreciated!

Thanks for sharing.