MySQL backup

На практике все переносится. Теоретически конечно может и не перенесется на какую-нибудь хитрую платформу. Я даже не знаю, какие еще доступные процессоры хранят FLOAT в формате отличном от IEEE 754 ? Целочисленные данные в innodb и myisam нормально переносятся. Возможны проблемы при переносе с unix на windows из-за регистров букв в именах файлов, но разумные разработчики такого не накодируют никогда.

Я вот отказался от mysqlhotcopy - на больших базах от 2 гб он иногда исходные базы рушил. По крайней мере в двух инсталляциях у меня. Вообще, этот скрипт не особо популярный. В mysql6 будут новые родные средства бекапа.

Пока что способ со снапшотами файловой системы самый быстрый.

Штука в том, что разработчики этого не гарантируют. В том числе,

для разных версий MySQL на одной платформе.

Для VPS, где варианта со снапшотами нет - либо он, либо

аналог, написанный руками на shell (обернуть cp/scp локами таблиц, от rsync

проку мало). А mysqldump с основного mysql-сервера - не вариант при больших базах.

Да, забыл сказать, у меня объем гдето 30 GB баз данных, и естественно хочется минимизировать простой сервера.

luxs, тогда точно - либо снапшоты - либо делать репликацию и mysqldump со slave.

Я не говорил про теорию, это неоднократные случаи практики, если вы еще с этим не сталкивлись, еще не значит что такого не бывает.

Снапшоты с lvm тоже хорошо, но блокировка все же будет, правда кратковременная, а при репликация и дампа с копии, у вас добавится еще и отказоустойчивость, т.к. можно резервный mysql очень быстро сделать основным.

вот с этого места давайте подробнее. как именно и что именно вы сломали и какие выводы сделали? вы что там на бабаяновском эльбрусе запускали mysql ?

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

Изменение в содержимом файла в зависимости от размера кластера файловой системы ? Сисадминские поверья какие-то рассказываете. Где конкретика? Я хочу это воспроизвести и сделать выводы.

Вы там случайно не innodb файлы отдельно от словаря копировать пытались ? - так это просто лажа.

К слову о бекапах, встречал я и такой "бекап". Innodb следует копировать только полностью все файлы снимком или при остановленном сервере.

Тривиальный случай смены бинарного формата myisam описан в документации по 5.0. Формат изменился и 4.0 не поймет данные от 5.0, хотя 5.0 все поймет.

Но неужели такие люди, которые догадаются даунгрейдить сервер до совсем тухлой версии действительно есть ?

Ну и если совсем уж все плохо, все побилось и никаких других бэкапов не было, хотя звучит действительно сомнительно, не понятно, что помешало поставить ось (?)/версию mysql, что была на старом сервере.

Для этого вам как минимум придется обзавестись PA-RISC архитектурой, установить HP-UX, а после чего погрузить меня в гипнотическое состояние дабы узнать конкретику типа номеров версий и последовательность событий произошедших ннцать лет назад.

Наверно вы администрируете попивая чаек сидя в креслице, а ваш ПК как и сервер подключены к хорошим каналам интернет, так вот в жизни бывают и другие условия администрирования я бы даже сказал иногда экстремальные, с выездами/вылетами на объекты, где бывают закрытые сети и выражение "надо сделать кровь из носа", но и это еще не самое страшное, хуже когда на все работы катастрофически мало времени, а в распоряжении ноут, голова и руки, а дальше как получится, эдакий админский квест в риалтайме с реальными последствиями :)

А вообще господа, я никого пардон "за яйца не тяну", в смысле не призываю, ну если нравится бэкапить файлы - на здоровье и удачи.