Binary logging is used for some operations such as clone and replica creation [1][2], and it is useful for recovering an instance to a specific point-in-time [3]. For First Generation instances, the space used by binary logs counts against the total storage used by the instance. For Second Generation instances, binary logs are charged at the regular storage rate. And when you disable binary logging, all the existing binary logs are deleted [4].
As binary logs use storage space and are automatically deleted with their associated automatic backup [5]. You should check to see if you have setup *automatic backup* or *on-demand backup* by Navigating to your Cloud SQL instance from your GCP Cloud Console to view information about it [6]. From there you can *edit* the instance settings [7][8].
Do you have a First Generation or Second Generation Instance? The most recent 7 automated backups, and *all on-demand backups, are retained* for Second Generation instances [9]. So if you have on-demand backup configured instead of automated backups then this could be the reason why you are seeing binary logs beyond 7 days. If the size of the binary logs is an issue to your instance, then you can delete the binary logs by disabling and then reenabling binary logging [4].
Note that you cannot manually delete binary logs, nor change the 7-day time period on automated backups. So try disabling binary logging if you want to delete existing binary logs.
To change the 'expire_logs_days' you need to have configured an external replica on a Cloud SQL 2nd Generation instance [10], and to purge those binary logs you need to have Super privileges. There is an internal feature request being evaluated to allow manual purging on binary logs. If you'd like to show your support for this you can do so in our Public Issue Tracker tool [11]. This carries the benefit of allowing you to interact with the engineering team directly regarding this functionality being implemented and also allows other users who would like to see this to show their support by 'starring' the issue.
[1] https://cloud.google.com/sql/docs/mysql/backup-recovery/backups#what_backups_provide
[2] https://cloud.google.com/sql/docs/mysql/replication/tips#bin-log-impact
[3] https://cloud.google.com/sql/docs/mysql/backup-recovery/restoring#pitr
[4] https://cloud.google.com/sql/docs/mysql/backup-recovery/restore#about_enabling_binary_logging
[5] https://cloud.google.com/sql/docs/mysql/instance-info#available_metrics
[6] https://cloud.google.com/sql/docs/mysql/instance-info#info
[7] https://cloud.google.com/sql/docs/mysql/edit-instance
[8] https://cloud.google.com/sql/docs/mysql/instance-settings
[9] https://cloud.google.com/sql/faq#backup-and-recovery
[11] https://issuetracker.google.com/35904375
You received this message because you are subscribed to the Google Groups "Google Cloud SQL discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-cloud-sql-discuss+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-cloud-sql-discuss/df80cadc-ea9c-4373-993e-d7c3f4fa5a1f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
No comments:
Post a Comment