我在托管/云 SQL 上遇到一个问题，其中一个实例意外（也在维护窗口设置之外）进入维护模式并且已超过 10 小时不可用。
以下是一些详细信息：
第二代 MySQL，数据库大小约为 180GB；
CPU 使用率低，连接数也低；
连接似乎被接受了，但随后又立即被拒绝：
ERROR 2013 (HY000): Lost connection to MySQL server at 'reading initial communication packet', system error: 2无法停止/重新启动或编辑该实例（因为它处于维护模式）。此 SQL 实例的 Google Cloud 控制台页面上的大多数控件均已禁用。
好像夜间备份在进入维护模式的那天晚上就被跳过了
Mysql 日志没有显示任何可疑内容，即 page_cleaner 运行（但我不是解析 mysql 日志的专家）
另一件可疑的事情是数据库的大小“没有减少”，而它似乎每晚都会定期减少，可能是因为跳过了二进制日志的清理？
这篇 serverfault 帖子可能与我的问题有关，但我不确定。我不喜欢的是，那里的解决方案是删除数据库并重新创建。这对我们来说不是一个选择，因为我们有生产数据，并且由于这个问题，备份被跳过，积压了一天。- https://stackoverflow.com/questions/49424706/google-cloud-sql-instance-always-in-maintenance-status-binary-logs-issue
答案1
这个问题已经由谷歌技术支持解决。基本上是有一个计划外的（维护窗口之外）更新，由于某种原因导致我们的数据库实例崩溃/禁用。花了很长时间和精力（因为这是一个生产数据库）才解决。
发布为对 OP 评论的回答，以防止问题解决后社区受到冲击。