Вообще-то правильный mysqldump - это lvm snapshot Есть утилита http://packages.debian.org/lenny/mylvmbackup но она мне не нравится, т.к. в случае, если что-то пошло не так - перестает работать.
Правильный, только там надо несколько дел сразу делать, в частности 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 пройдет намного быстрее и время частичной доступности будет минимально.
Comments 7
Есть утилита http://packages.debian.org/lenny/mylvmbackup но она мне не нравится, т.к. в случае, если что-то пошло не так - перестает работать.
Reply
Получившиеся файлы могут занимать очень много места из-за ключей.
Конечно, и эту проблему можно решить, запустив еще один mysqld на снапшоте, и сделав с него простой дамп, но тогда непонятно, почему бы его просто не сделать с самой базы используя --single-transaction?..
Другой хороший способ - бекап со слейва, когда ты все то же что и выше делаешь на слейве и, соответственно, нет и не может быть вообще никакого перерыва в обслуживании на бекап.
Reply
> Конечно, и эту проблему можно решить, запустив еще один mysqld на снапшоте, и сделав с него простой дамп, но тогда непонятно, почему бы его просто не сделать с самой базы используя --single-transaction?..
1) скорость; mysqldump - очень медленная штука
2) скорость; восстановление при помощи cat dump | mysql - очень медленная штука
3) если есть нетранзакционные таблицы (а они очень часто есть) --single-transaction не спасает
в общем, по совокупности - это все на порядок быстрее.
перед FLUSH TABLES WITH READ LOCK можно уменьшить размер cache (с ходу не помню параметр) и немного подождать - тогда FLUSH пройдет намного быстрее и время частичной доступности будет минимально.
backup на слейве - намного правильнее, да.
Reply
Reply
http://dev.mysql.com/doc/mysql/en
Если ты про это :)
Reply
#
# 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 <&1
Reply
Reply
Leave a comment