Перенос базы данных MySQL (InnoDB) большого объема на другой сервер?

Question

[camradee]

Дано: MySQL БД на InnoDB, порядка 100 таблиц, используются foreign keys. Размер нескольких таблиц достигает 50Гб, но большая часть 1-5Гб. Необходимо все это добро перенести на новый сервер. При этом сервис надолго останавливать нельзя, максимум на пару-тройку часов в выходной день ночью. Ранее с такой задачей на сталкивался, на небольших проектах все далал просто через дамп, копирование по сети и восстановление, на все про все до 15мин.

Может кто расписать по шагам как такое провернуть? Кучу обрывочных рекомендаций нагуглил, но целостной картины все равно нет.

Comments

[Andrey Tsvetkov]

Можно попробовать объединить их в кластер, где старый сервер будет мастером, а новый слэйвом, по идее данные скопируются без остановки сервиса

Answer 1

[Alex McArrow]

1) Делается полный дамп - записываем дату и время дампа
2) поднимается на новом сервере
3) проверяем что все работает на новом сервере
4) отключаем от пользователей старый
5) делаем выборки по таблицам всех данных старше записанной даты (п1)
6) накатываем дельту на новый сервер
7) запускаем новый сервер.

Опыт подобного был, база около 7 гигов. Время от п4 до п7 составила не более 30 минут - при условии что как параноик все перепроврил по 3-5 раз.

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

Или хорошая идея от Andrey Tsvetkov

Comments

[camradee]

По многим сообщениям в сети, время разворачивания базы в районе 50гигов будет измеряться часами. И вторая проблема внешние ключи. Там как то их игнорить надо или типа того. А главное - сервисом пользуется огромное кол-во пользователей и админов, в разных странах. Нельзя надолго останавливать и нельзя терять новые данные.

[Alex McArrow]

camradee, ну как я понял, вы это собираетесь делать не от скуки, а по важной необходимости. ИМХО - технический простой, если о нем предупредить за 2-3 дня вещь критичная, но терпимая.
А вообще действительно посмотреть в сторону копирования методом master->slave. !!! только о безопасности не забывайте - лишние порты на хорошем сервисе тут же начинают "простукиваться"

[OKyJIucT]

camradee, разворачивал базу в 120 гигов - заняло примерно 2.5 часа.

[camradee]

OKyJIucT, а проблемы с внешними ключами были?

[OKyJIucT]

camradee, нет, перенеслось все корректно. Правда индексы включались дольше, чем база переносилась, но в итоге все было ровно.

Answer 2

[OKyJIucT]

Как настроить MySQL Master-Slave репликацию?

Answer 3

[d-stream]

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

Comments

[camradee]

Если я прав, то оригинал был у Таннебаума в Сетях, что-то типа - "иногда проще и дешевле переслать жесткие диски самолетом, чем по сети" )

Answer 4

[Swartalf]

Переливайте бинарный дамп базы.
Как раз подобным занимаюсь в текущий момент, база >500Гб

если коротко:
на мастер-сервере
innobackup --stream=xbstream | nc 9999 # порт для примера
на новом сервере:
nc -l 9999 | xstream -x
как закончится переливка данных, на новом сервере делаете
innobackupex --no-timestamp -apply-log .

затем запускаете сервер, донастраиваете мастер-слейв реплику что бы догнать данные.
Выключаете старый сервер. Работаете на новом.

Из плюсов -- даунтайм только на момент переключения аппликейшена на новую базу
из минусов -- повышеная нагрузка на сеть и диски во время переноса данных