Я подумываю о переходе на нового хостинг-провайдера и хотел бы знать, возможно ли осуществить миграцию базы данных (MySQL 5.6) без огромного простоя (= время для копирования десятков ГБ файлов БД с одного хостинга на другой хостинг).
Итак, можно ли настроить текущую живую базу данных MySQL как ведущую, а новую машину как ведомую в каком-либо режиме, который ведущий не будет ждать с новыми вставками данных или обновлениями для подтверждения ведомого устройства, и ведомое устройство будет медленно (т.е. не будет потреблять слишком много ресурсов главной машины БД) попытайтесь синхронизировать себя, т.е. для полной синхронизации потребуется целый день или, может быть, пара дней (полное копирование файла займет около 4 часов).
Тем временем я бы настроил веб-сервер и другие службы на новом компьютере, а затем просто переключил бы DNS и переключил ведомое устройство в режим единственного ведущего и отключил старую машину. Я ожидаю (и меня это устраивает) потеря некоторых данных во время фактического переключения DNS (некоторые клиенты со старой записью DNS будут иметь доступ к старому серверу, и эти изменения не будут реплицироваться на новый компьютер), но для большинства посетителей это окно будет 15 минут или около того.
Итак, возможно ли что-то подобное и легко ли сделать? Альтернативой является примерно 4 часа простоя, скопируйте все файлы на новый сервер и просто запустите его, но я не очень доволен таким длительным временем простоя.
Я не против перезапуска службы / демона БД пару раз во время этого процесса, чтобы переключить его на новую конфигурацию.
Я не хочу выполнять эту миграцию с использованием дампов, когда мне приходится вручную синхронизировать таблицы.
Что вы можете! Единственное, что вы должны знать, что ваши серверы mysql должны «видеть» друг друга, а пропускной способности вашей сети должно быть достаточно для репликации всех ваших изменений. Вы должны установить percona-xtrabackup, сделать резервную копию вашего текущего запущенного экземпляра mysql, скопировать все файлы в каталог данных mysql-сервера другого хостинга, запустить экземпляр, настроить репликацию (изменить master на ...) и запустить slave. Подчиненное устройство скопирует все недостающие данные. На этом этапе вы должны знать о кратковременном простое, сделать ведущее устройство только для чтения (установить global read_only = 1) и после отсутствия записи направить ваше приложение на ведомое устройство. Когда новые записи появляются на ведомом устройстве, остановите репликацию (STOP SLAVE, RESET SLAVE), и вы можете закрыть старый экземпляр mysql.
вы можете обойтись без дампов снимков:
включить log-bin и сделать mysqldump --master-data=1 --all-databases на мастере - это сохранит позиции бин-журнала в дамп. в зависимости от ваших типов БД (только innodb может использовать --single-transaction), это приведет к блокировке чтения БД на максимум на время дампа. на самом деле никаких дополнительных действий с мастером не требуется.
залить раб с дампом, а после CHANGE MASTER TO ...; SLAVE START; он должен начать догонять бегущего мастера. как только он синхронизируется, вы можете переключиться.
вы также можете сделать iptables Перенаправление порта DNAT на подчиненное устройство, чтобы избежать задержек на основе DNS.
В целях миграции я бы не использовал репликацию.
Я делал это раньше через:
rsync копировать /var/lib/mysql/ с текущей системы на новую; текущая система может продолжить работу в обычном режиме. Сделайте это за день или около того до запланированной миграции.rsync очередной разrsync очередной раз. Это не займет много времени из-за относительно небольшого количества выполняемых обновлений.Конечно, вы должны учитывать, что клиентское приложение должно использовать новый сервер, поэтому при использовании DNS-имен учитывайте TTL (кеширование) DNS, в противном случае убедитесь, что используется правильный IP-адрес; но это выходит за рамки этого вопроса.