переезд mysql из физической машины в контейнер openvz

[zCirill]

Добрый день.

Занимаюсь миграцией debian6  x64 в контейнер openvz
На сервере живет php-apache2-nginx mysql

Собсно вопрос в том, как переехать mysql с минимальными задержками. Вариант с репликой и переключением - страшно и скила нет )
Задуманная стратегия в  том, чтобы перенести сначала мало изменяемые данные (меняются раз в полгода) и составляют 90 процентов от общей массы, потом стопнуть мускул и перенести остальное.

С данными все понятно, но как перенести базу mysql ?

Кошерно ли будет выполнить на физическом сервере FLUSH TABLES WITH READ LOCK, скопировать содержимое папки myqsl (в моем случае это /db-store/mysql/mysql/) и UNLOCK TABLES;
Запустить потом mysql в контейнере и восстановить из бэкапа те самые 90 процентов, потом восстановить остальные таблы и переключится на использование mysql в контейнере.

ЗЫ Нужно ли еще забирать performance_schema ?
ЗЫЫ Нужно ли перестраивать индексы?

[gardarea51]

Я конечно не специалист, но копировать БД путем копирования файлов нельзя. Только средствами БД, как вариант - dump/restore. И не забудьте про конфиг, он тоже может быть не дефолтный.

[zCirill]

Я конечно не специалист, но копировать БД путем копирования файлов нельзя. Только средствами БД, как вариант - dump/restore. И не забудьте про конфиг, он тоже может быть не дефолтный.

конфиг переедет, придется еще параметры под память переписывать, но это история другая.

копировать на ходу - нельзя. копировать залоченые базы можно - http://dev.mysql.com/doc/refman/5.1/en/backup-methods.html "Making Backups Using a File System Snapshot"
на этом основан метод mysql lvm snapshot (c чем я не хотел бы заморачиваться)

еще раз хочу отметить. локаю ВСЕ таблицы, копирую ТОЛЬКО файлы базы mysql (где хранится всякая служебная инфа, врде пользователей, бд. таблиц, прав и тд) весит 3.6 мб - все остальные части базы будут перенесены через dump/restore ибо слишком объемны.

[gardarea51]

Хотел еще написать про то, что мигрировать можно банально путем клонирования системы с lvm-снапшота )) если есть LVM. Как вы и написали - перед созданием снапшота нужно либо остановить сервис mysql, либо залочить таблицы. Но актуальность БД на таком снапшоте потеряется сразу после старта базы (либо "разморозки" таблиц). Насчет остановок других сервисов перед созданием снапшота - индивидуально, можно ничего не останавливать, тогда снимок системы будет чем-то вроде состояния компьютера после внеплановой перезагрузки.

А в деле миграции БД я совсем не спец, использовал там, где можно было позволить и часовой простой базы.

[zCirill]

благополучно переехал в контейнер.

rsync скопировал всю систему, кроме баз mysql и логов
в my.cnf поправил лимиты памяти

dpkg-reconfigure mysql-server для переконфигурации

восстановление mysql db из дампа сделанного на железном сервере
восстановление структуры таблиц
дамп и восстановление самых толстых и редко обновляемых данных, часов 10 ушло на все.
остановка доступа к базе "извне"
дамп и восстановление неперенесенных таблиц.
выключение физического сервера
назначение ip от физического сервера в контейнер, рестарт и ура, все работает.

PS во время восстановления 20 гигов редко обновляемых даных узнал много нового про лимиты в openvz ))