Previous Entry Share Next Entry
MySQL Backup User
Mac
sanmai
GRANT SELECT, RELOAD, LOCK TABLES, REPLICATION CLIENT ON *.* TO 'backup'@'localhost' IDENTIFIED BY 'Password';
 ~ $ cat > /usr/local/bin/mysql_backup
#!/bin/sh
if test -z "$PASSWORD"; then PASSWORD="$1"; fi;
echo -n "Backup started at "; date;
time mysqldump -vu backup -p$PASSWORD --all-databases > `date +%F`.sql;
time nice bzip2 *.sql;
Кроме того, иногда может быть полезно добавить следующие опции:
  1. Чтобы можно было "отыграть" бинлог при восстановлении:
    --single-transaction --flush-logs --master-data=2
  2. При использовании только MyISAM:
    --lock-all-tables
  3. В самый конец, чтобы не сохранять мусор:
    --ignore-table=db.USELESS
От засорения бинлогом всего чего только можно:
 ~ $ grep expire /etc/mysql/my.cnf 
expire_logs_days = 7

Дополнения и исправления приветствуются.


  • 1
Вообще-то правильный mysqldump - это lvm snapshot
Есть утилита http://packages.debian.org/lenny/mylvmbackup но она мне не нравится, т.к. в случае, если что-то пошло не так - перестает работать.


Edited at 2009-03-11 01:29 am (UTC)

Правильный, только там надо несколько дел сразу делать, в частности FLUSH TABLES WITH READ LOCK (что тоже требует некоторого времени), и, не отключаясь, в тоже самое время, делать lvm snapshot, а потом UNLOCK TABLES.

Получившиеся файлы могут занимать очень много места из-за ключей.
Конечно, и эту проблему можно решить, запустив еще один mysqld на снапшоте, и сделав с него простой дамп, но тогда непонятно, почему бы его просто не сделать с самой базы используя --single-transaction?..

Другой хороший способ - бекап со слейва, когда ты все то же что и выше делаешь на слейве и, соответственно, нет и не может быть вообще никакого перерыва в обслуживании на бекап.

> Получившиеся файлы могут занимать очень много места из-за ключей.

> Конечно, и эту проблему можно решить, запустив еще один mysqld на снапшоте, и сделав с него простой дамп, но тогда непонятно, почему бы его просто не сделать с самой базы используя --single-transaction?..

1) скорость; mysqldump - очень медленная штука
2) скорость; восстановление при помощи cat dump | mysql - очень медленная штука
3) если есть нетранзакционные таблицы (а они очень часто есть) --single-transaction не спасает

в общем, по совокупности - это все на порядок быстрее.
перед FLUSH TABLES WITH READ LOCK можно уменьшить размер cache (с ходу не помню параметр) и немного подождать - тогда FLUSH пройдет намного быстрее и время частичной доступности будет минимально.

backup на слейве - намного правильнее, да.

нипоня-я-я-ятно!

Начинать надо отсюда:
http://dev.mysql.com/doc/mysql/en

Если ты про это :)

echo "======= MySQL backup ======="
#
# Restore:
# bzip2 -dc < mysql_database_backup-$date.sql.bz2 | mysql -u xxxxxxx -p xxxxxxx
#
/usr/bin/mysqldump --no-defaults --all-databases \
--add-drop-table --allow-keywords \
--compress --create-options \
--extended-insert --flush-logs \
--flush-privileges \
--log-error=MySQL-backup.log \
--routines \
--password='vm20=mg3j=2jh9j26k452hj256ym2620iy26' \
--user=user -v | /usr/bin/bzip2 -c > mysql_database_backup-$date.sql.bz2

/bin/cat > /var/tmp/ftplogin <<EOF
open xxx.xxx.xxx.xxx
user user pass
binary
put mysql_database_backup-$date.sql.bz2 mysql_database_backup-$date.sql.bz2
quit
EOF

/bin/cat /var/tmp/ftplogin | /usr/kerberos/bin/ftp -n 2>&1

  • 1
?

Log in

No account? Create an account