我有一些带有故障转移复制的Google Cloud SQL MySQL第二代5.7实例 . 最近我注意到，由于某种原因，没有删除因重载binlogs和旧binlog而重载的实例之一 . 我试过重启这个实例，但它从3月17日开始 .
在其他服务器上使用binlog的正常进程：
问题服务器 . Binlogs没有清除，服务器不会启动，并且总是在gcloud控制台中进行维护 .
此外，我创建了另一台具有相同配置的服务器，而不是binlogs永远不会清除 . 我在这里已经有5326个binlogs了，在普通服务器上我有1273个binlogs并且他们每天都在清理 .
我尝试使用问题服务器：1 - 从Google Cloud Platform前端删除它 . 响应：实例ID当前不可用 . 2 - 使用gcloud命令重新启动它 . 响应：错误：（gcloud.sql.instances.restart）HTTPError 409：实例或操作未处于处理请求的适当状态 . 我在gcloud上发送的任何其他命令都有相同的响应 .
此外，我尝试解决binlogs的问题，以配置 expire_logs_days 选项，但似乎这个选项不支持谷歌 Cloud sql实例 .
1 回答
经过3天的挖掘，我找到了解决方案 . Binlogs必须在7天后自动清除 . 在8天内，它必须清除binlogs . 它仍然没有为我删除，仍然存储仍在攀升，但我相信它必须很快清除（今天我猜）
正如我所说 - 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 full writing '/mysql/binlog/mysql-bin.034311' (Errcode: -255699248 - No space left on device). Waiting for someone to free space.... 让我成为这个"someone" .当我删除数据库时，它重新启动然后再启动 . 中提琴 . 现在我们有了实例 . 现在我们可以删除它/恢复数据库/为它更改存储 .