Google Cloud SQL实例持续处于维护状态及二进制日志异常问题

碰到这种Cloud SQL MySQL实例因为二进制日志堆积导致存储过载、重启后卡在维护状态的情况确实头疼，我之前处理过类似的场景，给你梳理下排查和解决的思路：

既然其他同配置的故障转移实例都正常，问题大概率出在这台实例的特殊状态上：

• 首先检查复制链路的健康状态：故障转移架构下，主库的二进制日志清理完全依赖于备用实例（从库）是否已同步并应用了这些日志。如果备用实例宕机、复制延迟过高，或者复制链路因为错误中断，主库会一直保留旧日志以防从库需要同步。你可以通过gcloud sql instances describe [你的实例名]命令查看replicaConfiguration下的状态，或者在控制台「复制」标签页检查有没有复制错误提示。
• 确认二进制日志过期配置：Cloud SQL默认会自动清理超过7天的二进制日志，但如果手动修改过expire_logs_days参数，或者后台备份任务异常导致日志没被标记为可清理，也会出现堆积。不过现在实例卡在维护状态，暂时没法直接查看，先把这个点记下来。
• 存储过载的连锁反应：当存储被日志占满后，MySQL重启时可能因为无法写入启动日志、临时文件而卡住，进入“维护-启动失败-维护”的循环，后台自动清理日志的流程也因为存储100%无法执行。

优先级是先让实例恢复可用，再排查根本原因：

• 尝试强制触发日志清理：如果还能通过gcloud命令操作实例，执行gcloud sql instances patch [你的实例名] --database-flags expire_logs_days=1，强制设置日志1天后过期，然后执行gcloud sql instances restart [你的实例名]。注意：如果这是主库且备用实例没同步完，这么做可能会导致复制中断，但现在实例已经不可用，恢复实例是首要目标。
• 直接克隆实例：Cloud SQL的克隆功能会基于当前数据快照创建新实例，过程中会自动清理不必要的二进制日志。你已经创建了同配置的服务器，不如直接从问题实例克隆一个新实例，克隆完成后把业务流量切换过去，旧实例可以慢慢排查或者直接删除。步骤很简单：控制台选中问题实例→点击「克隆」→配置新实例的区域、故障转移参数→等待克隆完成即可。
• 联系GCP官方支持：如果以上操作都无效，说明实例的启动阻塞已经到了后台层面，直接提交支持工单，提供实例ID、故障开始时间（3月17日）、你已经尝试过的操作，让工程师手动介入清理日志或者修复启动流程。这种存储满导致的启动卡壳，很多时候需要后台操作才能解决。

避免再出现类似问题，做好这几点：

• 监控二进制日志存储：在Cloud Monitoring里创建告警规则，监控cloudsql.googleapis.com/database/binary_log_disk_usage指标，当使用率超过80%时触发告警，提前介入处理。
• 定期检查复制状态：对于故障转移实例，每周抽查备用实例的复制延迟和同步状态，确保复制链路稳定，这样主库才能正常清理旧日志。
• 不要随意修改二进制日志相关参数：Cloud SQL默认的expire_logs_days和复制配置已经适配了故障转移场景，除非有明确的业务需求，不要手动调整这些参数。

内容的提问来源于stack exchange，提问作者Nakukryskin