MySQL backup

L
На сайте с 03.05.2006
Offline
171
3666

Я сейчас делаю бакап mysql вот так

mysql-server stop;

rsync -av path-to-mysql path-to-backup

mysql-server start;

На сколько нужна первая и последняя строчки, будет ли работать без них? или это будет плохо?

[umka]
На сайте с 25.05.2008
Offline
456
#1

На открытых файлах делать дамп, конечно же, не следует. Ничего хорошего из этого не выйдет.

Используйте mysqldump.

Лог в помощь!
M
На сайте с 16.09.2009
Offline
278
#2

Если выделенный сервер - делать lvm-снапшоты, потом rsync.

На vps - mysqlhotcopy (если неприменно хочется решение, копирующее

каталоги с таблицами). Или mysqldump, как советовали выше.

Абонементное сопровождение серверов (Debian) Отправить личное сообщение (), написать письмо ().
zexis
На сайте с 09.08.2005
Offline
388
#3

для бэкапа используйте mysqldump

S
На сайте с 01.04.2008
Offline
91
#4

mysqldump конечно же, бэкапить сами файлы - дурной тон

Править домен летит Айболит. И одно только слово твердит: - DNS! DNS! DNS!
M
На сайте с 16.09.2009
Offline
278
#5
sysctl:
mysqldump конечно же, бэкапить сами файлы - дурной тон

Почему?

Если таблицы большие и достаточно интенсивно используются - лочить их

надолго mysqldump'ом - еще более дурной тон.

S
На сайте с 01.04.2008
Offline
91
#6
myhand:
Почему?

Когда понадобится срочно восстановить на другой архитектуре/системе, SQLсервере другой версии и т.п. можно получить очень неприятные грабли.

myhand:
Если таблицы большие и достаточно интенсивно используются - лочить их
надолго mysqldump'ом - еще более дурной тон.

"долго" понятие растяжимое, но если снятие дампа измеряется часами тогда надо применять другие средства типа репликации и снятия дампа уже с копии.

[umka]
На сайте с 25.05.2008
Offline
456
#7

myhand, так mysqlhotcopy тоже лочит.

Изначально товарищ собирался вообще весь мускул шатдаунить :)

Так что mysqldump по сравнению с этим — вершина технологического прогресса! )

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

Ну и из дампа удобней восстанавливать.

Иногда нужно восстановить не всю таблицу, а просто пару удалённых записей.

AU
На сайте с 03.09.2009
Offline
88
#8

Бекапим какую то базу:

mysqldump -u login -p pass _имя_базы_которую_бекапим_ | gzip > куда_сохранить.gz

Либо все базы:

mysqldump -u login -p pass --all-databases | gzip > куда_сохранить.gz

Ну и самое главное :) Зачем бекап, который непонятно как восстановить?

Восстановим:

mysql -u root -p _имя_базы_которую_хотим_восстановить_ < распакованный_файл_дампа.sql

Unix в вопросах и ответах https://unixhow.com (https://unixhow.com)
M
На сайте с 16.09.2009
Offline
278
#9

[umka], я имел в виду, скорее, lvm-бекап. Там лочится все на мизерное время.

А для больших баз - mysqlhotcopy шустрее mysqldump, естественно. У Вас же

не вся база в памяти сидит. Можно, конечно, и репликацию поднять, что более

универсальный, но и более "тяжелый" вариант.

На тему "удобно" - есть же mysql bin-log. Он иногда полезен для восстановления

небольшого числа записей.

sysctl:
Когда понадобится срочно восстановить на другой архитектуре/системе, SQLсервере другой версии и т.п. можно получить очень неприятные грабли.

Ну, такого никто и не обещал, если бекапите каталог данных физически. Зато быстро.

myhand добавил 06.02.2010 в 01:28

adm.unix:
mysqldump -u login -p pass _имя_базы_которую_бекапим_ | gzip > куда_сохранить.gz

А канал в gzip направляем специально?

Чтобы таблицы лочились подольше?

AU
На сайте с 03.09.2009
Offline
88
#10
myhand:

А канал в gzip направляем специально?
Чтобы таблицы лочились подольше?

Ну так уберите gzip

Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий