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


12

我已经使用了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

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

Answers:


10

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

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

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

如果您需要清除所有日志,请执行以下操作

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

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

更新

你可以试试

RESET MASTER;

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

的影响RESET MASTER从2种键方式对这些PURGE二进制日志的不同:

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

  2. RESET MASTER不能在任何复制从属服务器运行时使用。RESET MASTER从属运行时何时使用的行为是不确定的(因此不受支持),而PURGE BINARY LOGS复制从属运行时可以安全使用。

RolandoMySQLDBA的CAVEAT

如果在RESET MASTER连接并运行从站的情况下运行,则每个从站的IO线程将立即失去其位置。复制因此而中断,您将不得不花费时间来重新同步所有从站上的数据。如果要从主数据库安全删除二进制日志而不破坏复制完整性,请执行以下操作:

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

整体效果如何?这将在主服务器上留下二进制日志,这些日志的语句尚未在所有从站上执行。


是。我已经试过了 不工作
lamp_scaler

将二进制日志清除到'mysql-bin.000025'; 当您运行此错误是什么。
Abdul Manaf

是。我已经试过了 不工作
lamp_scaler 2013年

我已经更新了答案。您可以尝试RESET MASTER。
Abdul Manaf 2013年

1
@ydaetskcoR不,我的意思是最老的。让我澄清一下:如果您在任何时间运行CHANGE MASTER TO,它将删除所有中继日志。如果Relay_Master_Log_filemysql-bin.00123,则是从站知道的最旧的二进制日志。如果mysql-bin.00123在主服务器上不再存在,那么如果您CHANGE MASTER TO在不引用较新日志的从服务器上运行任何内容,则可能会丢失适当的复制位置。这很容易被忽略,最终导致您手动中断复制。
RolandoMySQLDBA 2014年

5

我不确定这是否发生在您身上,但是在我的情况下,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设置并再次开始正常工作。


1
...这就是解决MySQL日志循环问题的方法。尽管这是非常罕见的情况。我不得不这样做。有趣的是,PURGE LOGS仅在理想的设置下有效:1)当所有二进制日志都连续时,2)所有二进制日志都在mysql-bin.index文件中命名,3)没有多余的日志未提及mysql-bin.index。+1 !!!
RolandoMySQLDBA 2014年

3

就我而言,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,重新启动,清除了文件(现在成功),再次注释了该行,然后重新启动。之后,文件将被删除,不再创建。


2

这对我有用:(MySQL服务器版本:5.6.14)

PURGE BINARY LOGS BEFORE NOW();

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


只要二进制日志和二进制日志索引文件完美对齐,您的答案就会起作用。请参阅答案dba.stackexchange.com/a/74498/877以查看它何时不起作用。您的答案仍然是+1 !!!
RolandoMySQLDBA 2014年

0

您可以使用以下方法轻松删除所有日志:

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_days0 =永不删除日志。

来源

By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.