Google Cloud SQL 无缘无故地增加大小直到磁盘满

问题描述

我不知道如何解释这个问题，但我会尝试.

I don't know how to explain this well, but I will try.

• 我使用具有 20 GB 磁盘大小的 Google Cloud SQL 第二版.
• 我有几个 wp.总大小为 166.5 MB 的数据库.

现在我的存储空间使用量为 9.52 GB！(使用 166.5 MB SQL 数据...)并且增加速度仍然更快...

And right now my Storage usage is 9.52 GB! (With 166.5 MB SQL data...) and increasing still going faster...

怎么办?！

更新:

我解决了这个问题:

• 我在存储桶中进行了导出
• 我创建了一个新的 Cloud SQL 实例
• 从存储桶导入
• 并删除有问题的实例.

(并从我的应用程序更改了 ip)

(And changed ip from my applications)

我不知道问题从何而来，但可能是二进制日志的存储开销".

I don't know sure where problem come from but could be a "Storage overhead from binary logs".

下次将检查二进制日志:mysql>显示二进制日志；

Next time will check binary logs with : mysql> SHOW BINARY LOGS;

我认为 Google 缺少的是清除二进制日志！(一个简单的方法！)

What I think Google is missing is a purge binary logs! (an easy way!)

更新最终版:

启用二进制日志后，您的云 SQL 存储将不断扩展.

With binary logs active, storage of your cloud SQL will expand continuously.

对于处于相同情况的任何人，您可以编辑实例并取消选中二进制日志，之后当前的二进制日志将被清除.

For anyone in the same situation, you can edit the instance and uncheck binary logs, after that the current binary logs will purge.

抱歉我的菜鸟问题！:D(我是服务器管理的初学者.)

Sorry for my noob problem! :D (I'm a beginner in Server administration.)

谢谢Vadim！

推荐答案

如果您启用了二进制日志，mysql 将记录所有更改，这是复制或时间点恢复所需的.

If you have binary logs enabled, mysql will make a record of all changes, which is required for replication or point-in-time recovery.

如果您不需要这些功能，您可以禁用二进制日志，这将从您的实例中清除所有现有日志.

If you have no need for these features, you can disable binary logs which will purge any existing logs from your instance.

如果启用二进制日志，它们将不会无限增长.早于最早自动备份(7 天)的二进制日志会自动清除.

If binary logs are enabled, they will not grow indefinitely. Binary logs older than the oldest automatic backup (7 days) are purged automatically.

这篇关于Google Cloud SQL 无缘无故地增加大小直到磁盘满的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持跟版网！