主页 / dba / 问题 / 47046
Accepted
lamp_scaler
Asked: 2013-07-27 00:20:49 +0800 CST

为什么 MySQL bin 日志文件在清除或刷新后仍然存在？

  • 772

我使用了 PURGE BINARY LOGS 和 FLUSH LOGS，但是 mysql 目录仍然包含这些文件：

mysql-bin.000025
mysql-bin.000024
mysql-bin.000023
mysql-bin.000022
mysql-bin.000021
mysql-bin.000020
mysql-bin.000019
mysql-bin.index

有没有使用命令不起作用的原因？这些文件占用了大量空间。我想安全地摆脱它们。

mysql binlog

5 个回答

  1. Best Answer

    该PURGE BINARY LOGS语句删除指定日志文件名或时间戳之前的日志索引文件中列出的所有二进制日志文件。删除的日志文件也会从记录在索引文件中的列表中删除，以便给定的日志文件成为列表中的第一个。

    mysql-bin.000019我希望您已经使用命令清除了二进制日志

    PURGE BINARY LOGS TO 'mysql-bin.000019';

    如果您需要清除所有日志，请喜欢

    PURGE BINARY LOGS TO 'mysql-bin.000025';

    这将删除二进制日志至mysql-bin.000025.

    更新

    你可以试试

    RESET MASTER;

    RESET MASTER删除索引文件中列出的所有二进制日志文件，将二进制日志索引文件重置为空，并创建一个新的二进制日志文件

    与 PURGE BINARY LOGS的效果RESET MASTER在两个关键方面有所不同：

    1. RESET MASTER删除索引文件中列出的所有二进制日志文件，只留下一个数字后缀为 .000001 的空二进制日志文件，而编号不会被 PURGE BINARY LOGS 重置。

    2. RESET MASTER不打算在任何复制从属服务器运行时使用。当从属运行时使用时的行为RESET MASTER是未定义的（因此不受支持），而PURGE BINARY LOGS在复制从属运行时可以安全地使用。

    CAVEAT 来自 RolandoMySQLDBA

    如果您在RESET MASTER连接并运行的 Slave 的情况下运行，每个 Slave 的 IO 线程将立即失去其位置。复制因此被破坏，您将不得不花时间让所有从站上的数据再次同步。如果您想在不破坏复制完整性的情况下安全地从 Master 中删除二进制日志，请执行以下操作：

    • SHOW SLAVE STATUS\G在每个从站上运行。
    • 注意Relay_Master_Log_File。这是在 Slave 中成功执行最新语句的二进制日志）。
    • 从 的所有显示中SHOW SLAVE STATUS\G，确定哪个Relay_Master_Log_File是最旧的（例如，'mysql-bin.00123'）。
    • 你可以运行PURGE BINARY LOGS TO 'mysql-bin.00123';任何奴隶都不会失去它的位置。

    整体效果？这将在 Master 上留下二进制日志，其语句尚未在所有 Slave 上执行。

    • 12

  2. 就我而言PURGE BINARY，根本没有删除任何东西。

    我的分区使用率为 100%（我必须稍微清理一下我的慢查询日志，以便有足够的空间来重新启动 mysql），所以我做的第一件事就是更改/etc/my.cnf注释行log-bin=mysql-bin（不需要在这个服务器上，我忘了删除它），然后我重新启动了 mysql（这是需要的，因为有排队的查询阻止PURGE BINARY执行）。

    之后，我跑了，PURGE BINARY但什么也没发生。所以我阅读了手册并发现：

    如果服务器未使用 --log-bin 选项启动以启用二进制日志记录，则此语句无效。

    所以我log-bin=mysql-bin在我的 中重新启用/etc/my.cnf，重新启动，清除文件（现在成功），再次注释该行，然后重新启动。在此之后，文件被删除并且不再创建。

    • 10

  3. 我不确定这是否发生在您身上，但在我的情况下，MySQL 已停止“循环”日志，并且 mysql-bin.index 文件已因无效的 binlog 文件条目而“损坏”。

    具体来说，索引文件从 mysql-bin.000001 开始并到达 mysql-bin.000220 但不知何故又从 001 开始。当我将其与服务器上的文件进行比较时，我可以看到我的文件从 001 到022.

    起初我尝试过PURGE LOGS TO 'mysql-bin.000022';，但这没有用。

    最后，我停止了 MySQL 并手动编辑了索引文件，直到它与我服务器上的文件匹配。当我重新启动 MySQL 时，它清理了 binlog 文件以尊重expire_logs_days设置并再次开始正常工作。

    • 8

  4. 这对我有用：（MySQL服务器版本：5.6.14）

    PURGE BINARY LOGS BEFORE NOW();

    删除我系统上的所有二进制日志。

    • 6

  5. 您可以使用以下命令轻松删除所有日志：

    PURGE BINARY LOGS BEFORE NOW();

    或者用引号中的任何日期替换 func NOW()：

    PURGE BINARY LOGS BEFORE '2018-02-15 00:00:00';

    expire_logs_days = 10或者您可以在 my.cnf中自动执行此操作。默认expire_logs_days为0 = 从不删除日志。

    （来源）

    • 1

相关问题