【问题标题】:Binary log error in mysqlmysql中的二进制日志错误
【发布时间】:2012-07-12 05:48:32
【问题描述】:

当我试图检查二进制日志时:

 SHOW BINARY LOGS;

我收到此错误:

ERROR 1381 (HY000):您没有使用二进制日志记录。

如何解决这个问题?有人可以帮忙吗?

【问题讨论】:

  • 您是否正在运行 Amazon RDS ???
  • 不,我没有使用 Amazon RDS。

标签: mysql


【解决方案1】:

在你的 MySQL 配置文件中设置 log-bin 变量,然后重启 MySQL。

my.cnf(在 Linux/unix 上)或 my.ini(在 Windows 上)的示例如下所示:

[client]
...

[mysqld]
...
log-bin=mysql-bin
---

一旦重新启动,MySQL 会自动创建一个新的二进制日志(每次重新启动时都会这样做)。 您可能还希望查看以下变量:

server-id        = 1
expire_logs_days = 4
sync_binlog      = 1

阅读MySQL documentation 的详细信息。如果您正在设置复制(使用二进制日志的主要原因),请查看Replication configuration checklist

【讨论】:

  • server-id = 1 expire_logs_days = 7 sync_binlog = 0
  • 抱歉,您的评论似乎被截断了。您可以重新评论或​​编辑吗?
  • 无论如何,您的设置都很好——我自己的值只是示例。请注意,在sync_binlog=0 上,您会冒一些风险,即在主设备电源故障时,事务日志和二进制日志会不同步,从而导致主数据和从数据不匹配。
  • 在 Windows 上,您需要以 / 结尾,以确保将其解释为文件夹。
【解决方案2】:

线

log-bin=mysql-bin

必须放在行上方:

[mysqld_safe]

log-error=/var/log/mysqld.log

pid-file=/var/run/mysqld/mysqld.pid

【讨论】:

  • 很好......但请添加一些解释以使其更好地理解。
【解决方案3】:

您需要在启动时激活二进制日志记录

在 /etc/my.cnf 的 [mysqld] 部分下添加以下行

[mysqld]
log-bin=mysql-bin
expire-logs-days=7

然后,运行这个

service mysql restart

下次登录mysql时,你会看到一个二进制日志列表,7天后会轮换出来。

二进制日志的默认位置是/var/lib/mysql 或定义datadir 的位置。如果在 binlog 名称之前指定一个文件夹,则该文件夹就是位置。

例如

[mysqld]
log-bin=/var/log/mysql-bin
expire-logs-days=7

更新时间:美国东部时间 2012 年 7 月 12 日凌晨 02:20

请按如下方式重启mysql并告诉我们二进制登录是否开启

service mysql restart --log-bin=mysql-bin

【讨论】:

  • 请像这样重启mysql:service mysql restart --log-bin=mysql-bin
  • 您是把log-bin=mysql-bin 放在[mysqld] 标题下还是放在my.cnf 中的不同标题下???
【解决方案4】:

要启用二进制日志,请使用 --log-bin[=base_name] 选项启动服务器。

如果未给出 base_name 值,则默认名称是 pid-file 选项的值(默认为主机名称),后跟 -bin。

如果给出了基本名称,则服务器将文件写入数据目录,除非基本名称带有前导绝对路径名以指定不同的目录。建议您指定一个基本名称。

也可以直接使用:

log-bin=mysql-bin

然后重启你的mysql服务。然后将生成二进制文件。如果你在 Linux 机器上使用 Lampp,那么你会在 /lampp/var/mysql/mysql-bin.000001 中找到这个文件

【讨论】:

    【解决方案5】:

    FWIW,我在尝试设置 my.cnf.mastermy.cnf.slave 文件以及 symlink后遇到了同样的问题> 将它们分别添加到 my.cnf 中作为主从。这个想法是能够轻松地将机器从主机切换到从机,然后再切换回来。

    事实证明,mysqld 根本没有按预期处理符号链接。 硬链接文件有效(ln my.cnf.master my.cnf)。如果你做这样的事情要小心,因为覆盖其中一个硬链接文件名可能会破坏链接并创建两个单独的文件(取决于你使用的软件所采用的重写方法)。

    【讨论】:

      【解决方案6】:

      我发现即使 my.cnf 配置正确,日志记录也会静默失败,因此您也可以尝试重新创建日志文件夹。

      如果日志处于奇怪状态,这可能是必要的。 (就我而言,我只是停止登录 my.cnf 然后重新启用它,但什么也没发生,可能是因为现有文件不是最新更新?)。

      这样的事情应该可以工作:

      sudo service mysql stop
      sudo mv /var/log/mysql /tmp/mysqlold # or rm -fr if you're brave
      mkdir /var/log/mysql
      chown -R mysql:mysql /var/log/mysql
      sudo service mysql start
      

      强制性警告:显然,删除数据库服务器上的任何内容时要小心。这将破坏/破坏/破坏使用此数据库作为主数据库的任何复制(尽管您可以恢复复制作为从属)。也就是说,我相信这应该是安全的,因为它不会删除数据库本身。

      【讨论】:

        【解决方案7】:

        在运行 Debian 的 MySQL 5.5 master 上,我对这个问题失去了理智。以上都没有奏效。最后,我重新启动了服务器并启用了日志记录。

        【讨论】:

          【解决方案8】:

          删除部分 [mysqld_safe] 并替换为 [mysqld]。 它对我有用。

          【讨论】:

            猜你喜欢
            • 1970-01-01
            • 1970-01-01
            • 1970-01-01
            • 2013-01-23
            • 1970-01-01
            • 2010-09-07
            • 1970-01-01
            • 1970-01-01
            • 2015-04-30
            相关资源
            最近更新 更多