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