mysqldump & gzip 命令使用 crontab 正确创建 MySQL 数据库的压缩文件

Posted 2023-02-24

【中文标题】mysqldump & gzip 命令使用 crontab 正确创建 MySQL 数据库的压缩文件

【英文标题】：mysqldump & gzip commands to properly create a compressed file of a MySQL database using crontab

【发布时间】：2014-04-12 06:15:15

【问题描述】：

我无法让crontab 工作。我想自动备份 mysql 数据库。

设置：

Debian GNU/Linux 7.3 (wheezy) MySQL 服务器版本：5.5.33-0+wheezy1(Debian) directories 用户、backup 和 backup2 拥有 755 权限 MySQL db 和 Debian 账户的用户名相同

此命令在 shell 中起作用

mysqldump -u user -p[user_password] [database_name] | gzip > dumpfilename.sql.gz

当我使用 crontab -e 将它放在 crontab 中时

* * /usr/bin/mysqldump -u user -pupasswd mydatabase | gzip> /home/user/backup/mydatabase-backup-`date +\%m\%d_\%Y`.sql.gz >/dev/null 2>&1

/home/user/backup 目录中每分钟创建一个文件，但有 0 个字节。

但是，当我将此输出重定向到第二个目录 backup2 时，我注意到在其中创建了适当压缩的正确 mysqldumpfile。我无法弄清楚我所犯的错误是什么导致第一个目录中的 0 字节文件和第二个目录中的预期输出。

* * /usr/bin/mysqldump -u user -pupasswd my-database | gzip> /home/user/backup/mydatabase-backup-`date +\%m\%d_\%Y`.sql.gz >/home/user/backup2/mydatabase-backup-`date +\%m\%d_\%Y`.sql.gz 2>&1

非常感谢您的解释。

谢谢

【问题讨论】：

对不起，第一行代码中的拼写错误应该是 gzip 而不是 zip

我不会每分钟都运行这个

我运行它只是为了测试命令。

【参考方案1】：

您可以使用tee 命令重定向输出：

/usr/bin/mysqldump -u user -pupasswd my-database | \
tee >(gzip -9 -c > /home/user/backup/mydatabase-backup-`date +\%m\%d_\%Y`.sql.gz)  | \
gzip> /home/user/backup2/mydatabase-backup-`date +\%m\%d_\%Y`.sql.gz 2>&1

参见文档here

【讨论】：

我的问题是第一个重定向如何生成 0 字节文件，而第二个重定向如何生成完整文件

对此感到抱歉-我发布了对您原始问题的答案。我将把它留在这里 - 希望这个小 sn-p 对某人有用。

确实是:)

【参考方案2】：

首先执行 mysqldump 命令并使用管道重定向生成的输出。管道将标准输出作为标准输入发送到 gzip 命令。在 filename.gz 之后，是输出重定向运算符 (>)，它将继续重定向数据，直到最后一个文件名，即数据将保存的位置。

例如，这个命令会转储数据库并通过gzip运行它，数据最终会落在three.gz中

mysqldump -u user -pupasswd my-database | gzip > one.gz > two.gz > three.gz

$> ls -l
-rw-r--r--  1 uname  grp     0 Mar  9 00:37 one.gz
-rw-r--r--  1 uname  grp  1246 Mar  9 00:37 three.gz
-rw-r--r--  1 uname  grp     0 Mar  9 00:37 two.gz

我最初的答案是将数据库转储重定向到许多压缩文件（不进行双重压缩）的示例。 （因为我扫描了问题并严重错过了 - 对此感到抱歉）

这是一个重新压缩文件的例子：

mysqldump -u user -pupasswd my-database | gzip -c > one.gz; gzip -c one.gz > two.gz; gzip -c two.gz > three.gz

$> ls -l
-rw-r--r--  1 uname  grp  1246 Mar  9 00:44 one.gz
-rw-r--r--  1 uname  grp  1306 Mar  9 00:44 three.gz
-rw-r--r--  1 uname  grp  1276 Mar  9 00:44 two.gz

这是解释 I/O 重定向的好资源：http://www.codecoffee.com/tipsforlinux/articles2/042.html

【讨论】：

我遇到的问题是 mysqldump 和 gzip 命令有效。在第一次重定向到目录“备份”时，会创建一个 0 字节文件。第二次重定向到不涉及任何重新压缩的目录“backup2”会创建我想要的文件。我想知道为什么会这样。

输出没有通过管道传输到 gzip 中，而是被重定向。它将重定向直到到达最后一部分。这就是 gzip 将它拾取并压缩它的时候

Bash 识别出重定向并首先尝试打开文件。文件被打开（创建），然后 bash 确定如何重定向数据。如果打开文件出错，则命令失败并将错误写入标准错误。如果再次重定向输出，则第一个命令的标准输入将发送到行中的下一个文件。如果文件打开并且没有其他重定向，则将数据写入文件。

感谢您解释 bash 会将标准输入输出重定向到行尾，然后 gzip 会在最后压缩文件。我认为我的初始代码中有 > /dev/null 2>&1 并且 mysqldump 文件被发送到 /dev/null 并被丢弃。我现在的代码可以正常工作了。

minor：不要在命令中添加密码。它将最终出现在您的历史记录中并且可以检索。 （对于 cron 很好）

【参考方案3】：

如果您需要在备份文件名 (Centos7) 中添加日期时间，请使用以下命令：

/usr/bin/mysqldump -u USER -pPASSWD DBNAME | gzip > ~/backups/db.$(date +%F.%H%M%S).sql.gz

这将创建文件：db.2017-11-17.231537.sql.gz

【参考方案4】：

就我个人而言，我已经在根目录中创建了一个 file.sh（右 755），执行此工作的文件，按照 crontab 的顺序。

crontab 代码：

10 2 * * * 根 /root/backupautomatique.sh

File.sh 代码：

rm -f /home/mordb-148-251-89-66.sql.gz #(删除旧的)

mysqldump 铁道部 | gzip > /home/mordb-148-251-89-66.sql.gz（你做了什么）

scp -P2222 /home/mordb-148-251-89-66.sql.gz root@otherip:/home/mordbexternes/mordb-148-251-89-66.sql.gz

（如果发送服务器崩溃，则将副本发送到其他地方，因为太旧了，就像我一样;-)）

【参考方案5】：

除了m79lkm 的解决方案，我在这个话题上的 2 美分：

不要直接管道 |结果进入 gzip，但首先将其转储为 .sql 文件，然后 gzip。 因此，如果您有可用的磁盘空间，请使用 && gzip 而不是 | gzip。

转储本身将速度提高一倍，但您将需要大量更多可用磁盘空间。您的表将锁定更短的时间，从而减少您的应用程序的停机时间/响应缓慢。最终结果将完全相同。

首先检查可用磁盘空间非常重要df -h

然后像这样执行你的转储：

mysqldump -u user-p [database_name] > dumpfilename.sql && gzip dumpfilename.sql

另一个好的提示是使用选项--single-transaction。它可以防止表被锁定，但仍会导致可靠的备份。因此，您可能会考虑使用该选项。 See docs here。而且由于这不会锁定您的表对于大多数查询，您实际上可以通过管道转储 |直接在 gzip 中...（以防你没有可用的磁盘空间）

mysqldump --single-transaction -u user -p [database_name] > dumpfilename.sql && gzip dumpfilename.sql