☰

在 automysqlbackup 中的哪里添加 mysqldump 参数？

tag-icon • tag-icon backup mysql
在 automysqlbackup 中的哪里添加 mysqldump 参数？

如何停止 automysqlbackup 的 cron.daily 脚本——安装和配置后apt-get install automysqlbackup——抛出以下错误：

 mysqldump: Got error: 1142: SELECT,LOCK TABL command denied to user 
'debian-sys-maint'@'localhost' for table 'cond_instances' when using LOCK TABLES

升级到 MySQL 5.5 后会发生这种情况，这是升级到 Ubuntu 12.04 LTS 的副作用。

正确的解决方案（感谢 @sr_ 指向相应错误报告的指针）是从 mysqldump 中排除“performance_schema”数据库。

所以问题是：如何在尊重 Debian 软件包和配置的同时做到这一点？

升级到 MySQL 5.5 后，该问题每天都会出现。

背景： 我的目标是以尽可能标准的方式保留 Ubuntu Debian 安装的软件包和配置。但实际上，这是软件包安装/升级方式的一个错误，因此有必要更新提供的配置文件之一。

debian-sys-maint无论如何，拥有最完整的权限，因此在转储每个表之前已经有足够的权限来锁定它。

令人困惑的是，它/usr/share/doc/automysqlbackup/README.Debian说

所有参数都可以通过编辑 /etc/default/automysqlbackup 文件来设置

/etc/default/automysqlbackup使用 /etc/mysql/debian.cnf以下设置调用 mysqlbackup：

自动生成 Debian 脚本。请勿触摸！。

答案1

这个解决方案已经为我解决了这个问题。

根据这个错误报告有必要停止 automysqlbackup 转储“performance_schema”数据库，这可以通过/etc/default/automysqlbackup如下编辑来完成：

向 grep 步骤添加一个附加管道，以从 DBNAMES 列表中删除“performance_schema”。

因此，在开始的行中DBNAMES=以及| grep -v ^mysql$插入之后

| grep -v ^performance_schema$

前| tr \\\r\\\n ,\

感谢杰罗姆·杜洛埃

此解决方案适用于 Ubuntu 12.04 中的 Debian 版本的 automysqlbackup。显然，排除“performance_schema”数据库的语法因 Linux 发行版而异——请参阅下面的@stat。

答案2

编辑：忘记我所说的一切。

看这个错误报告。也许您找到了一种方法“从 mysqldump 中排除 'performance_schema' 数据库”，如注释 #2 所示；否则，错误报告的发布者编辑了automysqlbackup脚本以添加--skip-lock-tables参数，但我认为这可能会伤害您（如下所示）。

简短回答：你可能想锁定它们。

我猜不锁定它们不是您想要的，因为它可能会给您带来无用的备份，即当表发生更改时正在备份时---这是什么锁有没有可以预防的。

这个分支的自述文件也该块条目提及有关授予用户的内容'autobackup'@'localhost'访问权限的内容锁表。

也就是说，您的错误消息表明有问题的“用户”实际上是'debian-sys-maint'@'localhost'. 所以我猜如果您授予所需的权限这用户或者更改备份脚本的凭据automysqlbackup.conf（这可能/etc/default/automysqlbackup在 Debian 中，请咨询man automysqlbackup和/usr/share/doc/automysqlbackup/README.Debian），你应该没问题。

编辑 从本手册我引用--lock-tables应该做什么

--lock-tables, -l

对于每个转储的数据库，在转储之前锁定所有要转储的表。

它与手册中唯一出现的 相关联--skip-lock-tables，所以我认为它意味着--skip-lock-tables导致mysqldump转储表时不锁定表。正如我上面所说，这是不可取的。我认为这与转储锁表但与锁定表。

然而，我不明白为什么它不起作用，如果正如你所说，有问题的用户应该能够做到这一点......

答案3

我错误地看到了解决方案 1，它确实可以在 debian 上运行

我可以通过将行更改 /etc/default/automysqlbackup为以下内容来“暂时”修复此问题：

CONFIG_db_exclude=( 'information_schema' 'performance_schema' )

我不确定这会产生什么影响，但测试恢复对我有用，并且备份完成时没有错误。

上次更新后，我在 debian sid 上的解决方案失败了，但解决方案一（之前对我不起作用）确实有效。这是 grep /etc/default/automysqlbackup 并添加行 | grep -v ^性能模式$。上面排除了我之前使用的似乎在转储中被忽略的内容。

相关内容