Mysqldump не работает в crontab

Ответ 1

Вам нужно избежать символа% с \

mysqldump -u 'username' -p'password' DBNAME > /home/eric/db_backup/liveDB_`date +\%Y\%m\%d_\%H\%M`.sql

Ответ 2

Проверьте журналы cron (должны быть в /var/log/syslog ). Вы можете использовать grep для их фильтрации.

grep CRON/var/log/syslog

Также вы можете проверить свой локальный почтовый ящик, чтобы узнать, есть ли какие-либо письма cron

/var/mail/username

Вы также можете настроить другую почтовую почту в файле crontab

[email protected]

Ответ 3

В качестве альтернативы вы можете создать пользовательскую команду mycommand. К ним вы можете добавить дополнительные параметры. Вы должны предоставить разрешения на выполнение.

Предпочтительно иметь папку, в которой они хранят все ваши резервные копии, в этом случае, используя резервную папку для записи, которая сначала создается в "вашем доме", например.

Моя команда в "usr/local/bin/mycommand":

#!/bin/bash
MY_USER="your_user"
MY_PASSWORD="your_pass"
MY_HOME="your_home"
case $1 in 
"backupall")
    cd $MY_HOME/backup
    mysqldump --opt --password=$MY_PASSWORD --user=$MY_USER  --all-databases > bckp_all_$(date +%d%m%y).sql
    tar -zcvf bckp_all_$(date +%d%m%y).tgz bckp_all_$(date +%d%m%y).sql
    rm bckp_all_$(date +%d%m%y).sql;;
*)  echo "Others";;
esac

Cron: Запускает 1-й день каждого месяца.

0 0 1 * * /usr/local/bin/mycommand backupall

Я надеюсь, что это поможет.

Ответ 4

Я пытался сделать то же самое, но обнаружил, что дамп создан с 0 КБ. Следовательно, я узнал о решении, которое сэкономило мое время.

Команда:

0 0 * * * mysqldump -u 'USERNAME' -p'PASSWORD' DATEBASE > /root/liveDB_`date +\%Y\%m\%d_\%H\%M\%S`.sql

Примечание: 1) Вы можете изменить настройку времени в соответствии с вашим требованием. Я устанавливал каждый день в команде выше.

2) Убедитесь, что вы вводите свои USERNAME, PASSWORD и DATABASE внутри одной кавычки (').

3) Запишите команду выше в Crontab.

Я надеюсь, что это поможет кому-то.

Ответ 5

Хорошо, у меня была аналогичная проблема, и я смог ее исправить.

В вашем случае вы можете вставить эту команду mysqldump в script затем укажите профиль пользователя, выполняющего команду mysqldump например:

. /home/bla/.bash_profile

затем используйте абсолютный путь команды mysqldump

/usr/local/mysql/bin/mysqldump -u root -pHERE THERE IS MY PASSWORD --all-databases | gzip > /var/db_backups/database_`date +%d%m%y`.sql.gz

Ответ 6

Создайте новый файл и выполните код там, чтобы свалить его в папку и закрепить его. Запустите script через cron

Ответ 7

Я использую Percona Server (MySQL fork) на Ubuntu. Пакет (скорее всего, и обычный пакет MySQL) поставляется с учетной записью обслуживания debian-sys-maint. Чтобы эта учетная запись использовалась, учетные данные создаются при установке пакета; и они хранятся в /etc/mysql/debian.cnf.

И теперь неожиданность: также добавлена ​​символическая ссылка /root/.my.cnf, указывающая на /etc/mysql/debian.cnf.

Этот файл файл параметров автоматически читается при использовании mysql или mysqldump. Таким образом, в основном у вас тогда были введенные учетные данные дважды - в этом файле и в командной строке. Это была проблема, которая у меня была.

Таким образом, одним из способов избежать этого условия является использование --no-defaults для mysqldump. Файл опции затем не будет считан. Однако вы предоставляете учетные данные через командную строку, поэтому каждый, кто может выпустить ps, может увидеть пароль после запуска резервного копирования. Поэтому лучше всего создать собственный файл с именем пользователя и паролем и передать его на mysqldump через --defaults-file.

Вы можете создать файл опций, используя mysql_config_editor или просто в любом редакторе.

Запуск mysqldump через sudo из командной строки как root работает, просто потому, что sudo обычно не меняет $HOME, поэтому .my.cnf не будет найден. При запуске как cronjob, это так.

Ответ 8

Резервное копирование локального хоста mysql: 0 1 * * */usr/local/mysql/bin/mysqldump -uroot -p пароль --opt база данных>/path/to/directory/filename.sql

(Между -p и паролем или -u и именем пользователя нет пробела - замените root на правильное имя пользователя базы данных.)

Меня устраивает. нет пробела между -p и паролем или -u и именем пользователя

Ответ 9

Вам также может потребоваться перезапустить службу для загрузки любых ваших изменений.

service cron restart

или

/etc/init.d/cron restart