☰

mysqldumpコマンドはcronジョブでは機能しません。

tag-icon • tag-icon centos cron mysql
mysqldumpコマンドはcronジョブでは機能しません。

cronにスケジュールされてからbashスクリプトを使用してバックアップを実行しようとしています。

#!/bin/bash
echo "Hello"
while read table
do
/usr/bin/mysqldump -uroot -pxxxxxx CMAYA_RadiusUserLogs $table > sc_back/${table}.sql
done < tables.txt

クローンの配列は次のとおりです。

58 16 * * * root /bin/sh -x /backup/call_backup.sh > /backup/backup.log

/var/log/cronは次のようになります

Jul  3 16:27:01  (root) CMD (/bin/sh -x /backup/backup.sh > /backup/backup.log)

/バックアップ/backup.log

[root@ backup]# cat backup.log
Hello

この同じスクリプトを手動で実行すると正常に動作し、スクリプトに入力した他のコマンドはcronジョブで機能します。

答え1

tables.txtパスを修正しましたが、問題はまだ存在しますが、std err 2>＆1をリダイレクトした後に機能し始めました。 「警告：コマンドラインインターフェイスでパスワードを使用するのは安全ではないかもしれません」という警告メッセージの理由を見つけました。問題を起こしました。このメッセージが表示された後にmysqldumpが終了したため、エラーをリダイレクトして操作を開始しました。 mysqlを5.6にアップグレードした後、この現象が発生しました。

#!/bin/bash

echo "Hello"
while read table
do
touch sc_back/${table}.sql
/usr/bin/mysqldump -uroot -pxxxxx CMAYA_RadiusUserLogs $table > /backup /sc_back/${table}.sql
done < /backup/tables.txt

答え2

問題は、スクリプトの最後の行にファイルの絶対パス全体を入力する必要があることですtables.txt。そうしないと、cronジョブはファイルを見つけることができません。

スクリプトを手動で起動するとスクリプトが機能するのは、ファイルがtables.txt現在のディレクトリにあるため、システムが簡単に見つけることができるためです。

答え3

cronがスクリプトを実行すると、現在の作業ディレクトリはcronテーブルのユーザーのホームディレクトリ（明らかに/ root）であり、スクリプトとそのファイルは/ backupの下にあります。これがスクリプトがtable.txtを見つけることができず、テーブルループが繰り返されない理由です。

まず、スクリプトディレクトリにCDを移動してから実行する必要があります。たとえば、次のようになります。

58 16 * * * root cd /backup && /bin/sh -x call_backup.sh > backup.log

関連情報