Лучший способ миграции серверов без потери данных и без простоя (?)

Question

Это методологический вопрос от фрилансера с результатом MySQL. Есть ли способ перенести с старого выделенного сервера на новый? без потери каких-либо данных между ними и без простоя? Раньше мне приходилось потерять данные MySQL между временем, когда новый сервер идет вверх (т. Е. Все файлы переданы, система вверх и готова), и когда я беру старый сервер вниз (данные все еще переносятся на старые, пока новые один берет на себя). Существует также короткий период, когда оба для DNS и т. Д. Обновляются.

Есть ли способ для MySQL/root легко переносить все данные, которые были обновлены/вставлены между определенным временным интервалом?

Answer 1

Проверьте MySQL binary log.

Answer 2

Я бы сделал извините страницу, поставил ее на старый сервер, передал все данные в новую и затем переключил DNS. Хотя будет время простоя.

Answer 3

Несомненно. Включить ведение журнала на исходном сервере. После этого создайте дамп базы данных и перенесите его на новый сервер и импортируйте. Затем, когда вы готовы сделать этот переключатель, измените DNS (пусть изменение распространяется во время работы), а затем снимите узел на обоих серверах. Скопируйте binlogs на новый сервер и запустите их снова, начиная с даты/времени дампа.

Answer 4

Что мне нравится делать, это закрыть сайт и начать перемещать БД на другой сервер, используя следующие команды: 2, а затем переместить все файлы (php ..etc) на другой сервер (если у вас есть некоторые данные о магазине или изменения файлы каждый час, например, загрузка изображения). и укажите старый сервер на новый сервер БД, пока DNS переходит на новый сервер.

Answer 5

Самый длинный простоя от коммутатора DNS - может занять несколько часов и даже дней до истечения срока действия всех кешей клиентов.

Чтобы избежать этого:

1. настроить приложение на новый сервер для доступа к БД по старому, или просто прокси запросов HTTP с Nginx к старому, в зависимости от того, что является более приемлемым.
2. затем переходит в DNS-коммутатор, некоторые клиенты переходят на ld-сервер, некоторые из них - на новый, здесь вы можете подождать 24 часа, чтобы убедиться, что все запросы перешли на новый сервер.
3. Пока DNS-коммутаторы - репетируют mysql-переход.
   • сделать страницу «извините/maintanance», есть много руководств, как это сделать, перезаписывать. В любом случае вам это понадобится
   • измерьте, как быстро вы можете сбрасывать-передавать-восстанавливать db, если время приемлемо - это самое простое, но не забудьте указать некоторый запас
   • если предыдущий слишком медленный - вы можете попробовать binlog метод, предложенный в предыдущем ответе
   • минимальный простор может быть достигнут путем создания нового сервера mysql slave на старом, под капотом он просто загружает binlog из мастера на лету, и вы сэкономите время на переносе всего журнала , скорее всего, во время минимальной нагрузки slave будет всего на несколько секунд отставать от мастера и быстро догнать, как только приложение будет снято, см. how to force slave to catch up.
4. Напишите сценарий, который выполняет весь переход для вас - включает режим обслуживания, блокирует мастер db, ждет, пока подчиненный не догонит, сделает подчиненный новый хозяин, заменит конфигурацию приложения новым db, отключит обслуживание, переключит приложение и т. Д. ,Таким образом, вы сэкономите время на вводе команд самостоятельно, протестируете в промежуточной среде, чтобы избежать возможных ошибок (также не забудьте установить более высокий тайм-аут mysql, на всякий случай, если ведомое устройство сильно отстает)
5. здесь идет сам переход, запустив скрипт из предыдущего шаг

Кроме того, если вы используете загрузку файлов в локальную файловую систему - они должны быть синхронизированы также и на большом количестве файлов, это больше боли, чем с БД, потому что даже Rsync сканирования для изменений может занять много времени.