MySQL HA DB main/replica is generating a lot of binary log churn

We are using MySQL for our Grafana back end. We have DB replicas so that there is a redundant version with the dashboards and configurations in even of a failure to give us more resilience.

This is all running in Kubernetes (k3s) and was working fine until we started to add alerting. Even on a small deployment where the data directory used to only be about 8GB, we have blown Persistent Volumes in Kubernetes out to over 130 gig per db instance. Almost ALL of the increase is in the binary logs used for replication and inspection of those logs had identified a huge number of updates to grafana.alert_instance.

Is there a safe way to reduce the binlog retention for Grafana’s backend DB or to excluded the replication for ‘alert_instance’?

We are running the following:
grafana:9.5.1

Many thanks,
Connon

Should anyone else stumble on this, the current work around we are using is to change the binlog retention to 1 day. It’s manageable at the moment but I think there is probably a better way to handle this.

Also see here regarding the use of the bitnami mariadb package: