MySQL backup

1 2345 6
N
На сайте с 06.05.2007
Offline
419
#21

PA-RISC тоже оперирует числами в стандарте IEEE 754. Содержимое файла при правильном копировании не должно меняться.Так что вопрос где вы облажались н-цать лет назад открыт.

Кстати по-поводу того, как учат DBA-шников : в оракле все равно есть штатная процедура горячего бинарного бекапа. Учат их, учат, а они все равно, сволочи, копируют без дампа. Дикие люди эти DBA.

Кнопка вызова админа ()
Lupus
На сайте с 02.11.2002
Offline
241
#22
sysctl:
Когда понадобится срочно восстановить на другой архитектуре/системе, SQLсервере другой версии и т.п. можно получить очень неприятные грабли.

Вообще-то ТС говорит про backup, а не про перенос. И приоритетом у него являются особенности именно этого процесса, а не проблемы совместимости архитектур и версий.

There are two types of people in this world: 1. Those who can extrapolate from incomplete data.
Raistlin
На сайте с 01.02.2010
Offline
247
#23

Только что пытался восстановить бекап тупо файловый (/var/lib/mysql). InnoDB не хотел работать ни в какую... Хорошо, что был старый дамп. Вот дамп залился без проблем. Правда, пришлось руками потом кучу запросов вбивать, но все же лучше, чем ничего. Та же версия MySQL, та же ОС , все идентично. Так шо желающие восстановить не всю /var/lib/mysql, а только одну базу могут забыть про файловые бекапы. Лучше сделать репликацию...

HostAce - Асы в своем деле (http://hostace.ru)
M
На сайте с 16.09.2009
Offline
278
#24

Raistlin, это потому, что делали бекап именно что "тупо файловый". Если

копируете файлы с живого mysql - тут и MyISAM не выдержит, не то что InnoDB.

Делаете нормальный файловый бекап со снапшотами LVM/ZFS, READ локами

таблиц перед созданием снапшота - все восстановится нормально.

Абонементное сопровождение серверов (Debian) Отправить личное сообщение (), написать письмо ().
Raistlin
На сайте с 01.02.2010
Offline
247
#25

бекап делался не снапшотом ФС (вы представляете, 200 Гб данных снапшотить?), а тупо остановил mysql, содрал папку, пустил майскюэль, т.к. показалось более простым в данный момент. А потом восстановить то и не смог... Так что нифига не нормально. Оно было в "анабиозе". Но InnoDB так бекапить нельзя, и я в этом убедился уже...

Т.е. бекап был как раз такой же, как у ТС. Как с MyISAM - проблем не возникло. Я понадеялся, что это будет проще сделать, было банально лень писать более длинные команды. Вот и поплатился.

Lupus
На сайте с 02.11.2002
Offline
241
#26
Raistlin:
тупо остановил mysql, содрал папку, пустил майскюэль

Хм. А монитор какой его, часом, не запустил снова, при копировании?

Все симптомы указывают на изменение таблицы во время копирования.

M
На сайте с 16.09.2009
Offline
278
#27
Raistlin:
бекап делался не снапшотом ФС (вы представляете, 200 Гб данных снапшотить?), а тупо остановил mysql, содрал папку, пустил майскюэль, т.к. показалось более простым в данный момент. А потом восстановить то и не смог... Так что нифига не нормально. Оно было в "анабиозе".

Если Вам верить - один раз у вас mysqld _нормально_ стартовал с определенным

каталогом данных (после бекапа). А второй раз - нет (абсолютно такой же каталог,

восстановленный из бекапа).

Raistlin
На сайте с 01.02.2010
Offline
247
#28

mysql другой. Аналогичный.

M
На сайте с 16.09.2009
Offline
278
#29

Raistlin, аналогичный насколько? Все-таки разные версии?

Или бекап поднимался еще и на другой платформе?

Raistlin
На сайте с 01.02.2010
Offline
247
#30

На той же платформе, та же версия MySQL. Абсолютно идентичные версии ПО, ось - CentOS 5.4, Mysql - 5.0.77. Просто скопирована вася папка /var/lib/mysql. Самое удивительное, что phpmyadmin видел 77 таблиц, но отображал только 56. Я разбираться не стал, честно говоря, просто влил дамп, мне так было проще. Правда, удивительно, таблицы удаляться не хотели даже руками О_о. Пришлось сносить базу полностью.

1 2345 6

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