我有一些具有故障转移复制功能的 Google Cloud SQL MySQL 第二代 5.7 实例。最近我注意到其中一个实例因存储重载而导致二进制日志重载，并且旧的二进制日志由于某种原因未删除。 我尝试重新启动此实例，但自 3 月 17 日起它就无法启动。
其他服务器上有 binlog 的正常进程:
服务器有问题。 Binlog 未清除，服务器无法启动，并且始终在 gcloud 控制台中进行维护。
我还创建了另一台具有相同配置的服务器，并且二进制日志从未清除。我这里已经有 5326 个二进制日志，而在普通服务器上我有 1273 个二进制日志，而且它们每天都会被清除。
我对问题服务器的尝试: 1 - 从 Google Cloud Platform 前端删除它。响应:实例 ID 当前不可用。 2 - 使用 gcloud 命令重新启动它。响应:错误:(gcloud.sql.instances.restart) HTTPError 409:实例或操作未处于处理请求的适当状态。我使用 gcloud 发送的任何其他命令都有相同的响应。
我还尝试解决 binlogs 的问题，以使用 expire_logs_days 选项进行配置，但 google cloud sql 实例似乎不支持此选项。
最佳答案
经过三天的挖掘，我找到了解决方案。超过 7 天后，二进制日志必须自动清除。 8 天之内必须清除二进制日志。它仍然没有为我删除，存储空间仍在攀升，但我相信它很快就会清除(我猜是今天)
正如我所说 - SQL 实例始终处于维护状态，无法从 gcloud 控制台命令或前端删除。但这很有趣，因为我仍然可以使用 mysql 命令连接到实例，例如 mysql -u root -p -h 123.123.123.123 。所以，我只是连接到实例，删除了未使用的数据库(或者我们可以使用 mysqldump 来保存当前的实时数据库)，然后我就把它删除了。在 mysql 日志中(我为此使用 Stackdriver)，我收到了很多这样的消息: 2018-03-25T09:28:06.033206Z 25 [ERROR] Disk is fullwriting '/mysql/binlog/mysql -bin.034311'(错误代码:-255699248 - 设备上没有剩余空间)。正在等待有人释放空间...。让我成为这个“某人”。
当我删除数据库时，它重新启动，然后又启动。中提琴。现在我们有了实时实例。现在我们可以删除它/恢复它的数据库/更改它的存储。
关于mysql - Google Cloud SQL 实例始终处于维护状态和二进制日志问题，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/49424706/