Google CloudSQL实例存储正在失去控制。

Question

我遇到了Ggoole (第2代)的问题。由于某种原因，经过一段时间后，数据库在几个小时内从20 of上升到64 of。它过去从20上升到25，然后清除随着时间的增加和删除的条目。

在连接到数据库的服务器上没有发生任何事情，我将Cloud标志设置为off。还有什么我还能尝试的吗？

​

​

Answer 1

这很可能是二进制日志造成的。启用它们后，MySQL将记录所有更改，这是复制或实时恢复所需的。这意味着二进制日志的增长与修改行的数量大致成正比(即使这些行实际上被删除，db的总大小减小了)。

请注意，它们不会无限期地增长。比最老的自动备份(7天)更早的二进制日志将自动清除。

还请注意，可以增加存储大小(我相信您已经启用了自动存储增长)，但它不能减少，如文档所示的这里。这意味着当清除二进制日志时，空闲磁盘空间将增加，但总的存储大小将保持不变。如果要在清除绑定日志后减小磁盘大小，可以按照建议的方法这里。

Answer 2

下面是一些关于这个问题的Google文档：https://cloud.google.com/sql/docs/mysql/replication#bin-log-impact

下面是一些有趣的mysql命令来查看和清除它们：

mysql> SHOW BINARY LOGS;
+------------------+-----------+
| Log_name         | File_size |
+------------------+-----------+
| mysql-bin.000001 | 106930110 |
| mysql-bin.000002 | 102842758 |
| mysql-bin.000003 | 109947365 |
....

https://dev.mysql.com/doc/refman/5.7/en/show-binary-logs.html

mysql> PURGE BINARY LOGS BEFORE '2020-10-28 00:00:00';

https://dev.mysql.com/doc/refman/5.7/en/purge-binary-logs.html

Answer 3

我们也遇到了类似的问题，而不是二进制日志。进行维护可以解决问题，但这不是根本原因。

问题出在一个糟糕的查询上！

如果您对查询进行了“解释”，并且看到“使用临时的；使用文件”，这意味着MySQL创建了一个临时文件。

这个文件可能很大(特别是如果查询生成一个外部联接！)