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

Question

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

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

Answer 1

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

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

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

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

Answer 2

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

Answer 3

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

Answer 4

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

Answer 5

Проверьте двоичный журнал MySQL .