Самый быстрый способ перенести базу данных MySQL в новую систему с минимальным временем простоя?

Я бы посоветовал:

1. Создание снимка при кратковременном блокировке чтения с FLUSH TABLES WITH READ LOCK;.
2. Загрузите этот набор данных на свой вторичный компьютер и проверьте согласованность.
3. Настройте репликацию со старой машины на новую.

Затем в точке переключения:

1. Отключите клиента, обращенного к IP, на старой машине (у вас ведь отдельный, правда?).
2. Проблема FLUSH LOGS; на старой машине.
3. Убедитесь, что новый компьютер синхронизирован. 0 секунд позади.
4. Остановите старую машину и дважды проверьте размер последнего бинарного журнала относительно положения новой машины.
5. Проблема STOP SLAVE; RESET MASTER; на новой машине.
6. Подключите клиента к IP на новой машине и убедитесь, что клиенты его видят.

Есть несколько более тонких деталей, например, являетесь ли вы активным пользователем InnoDB. Но это общая суть.

Почему бы не настроить второй сервер MYSQL в качестве подчиненного, реплицировать, а затем перенастроить подчиненный сервер в качестве главного?

Дэн Си прав, но я хотел бы уточнить первые 3 шага.

Ради скорости, и чтобы избежать бедствий, сделайте все это в клиенте mysql CLI следующим образом:

sudo mysql -e "FLUSH TABLES; FLUSH TABLES WITH READ LOCK; SYSTEM ec2-create-snapshot vol-4d826724; UNLOCK TABLES;"

Я полагаюсь на следующие моменты:

1. Получение блокировки чтения может занять некоторое время, если выполняется длительная команда UPDATE, DELETE или INSERT. Выдаю подготовительный ТАБЛИЦЫ ПРОМЫВКИ чтобы свести к минимуму время блокировки любых таблиц.
2. Клиент mysql может передавать команды в ОС хоста с СИСТЕМА команда, и делает это как пользователь, запускающий клиент mysql. (Вот почему я использовал sudo)
3. Когда вы сказали, что используете ESB на EC2, чего я никогда не использовал, я посмотрел эта документация для вас. Вы должны посмотреть, что поставить для "vol-XXXXXXXX"
4. Сделайте себе жизнь немного проще и поставьте пароль в ~ root / .my.cnf

Я вижу это описание двусмысленно, или явно неправ по всему интернету! В документации четко сказано: "Если клиентское соединение разрывается, сервер снимает блокировки таблицы, удерживаемые клиентом.". Так что вы не может открыть клиент mysql, сбросить + заблокировать, выйти из клиента, сделать снимок, открыть клиент mysql, разблокировать таблицы. В результате вы получите противоречивый снимок.

Некоторые сверхточные считыватели правильно определят, что "РАЗБЛОКИРОВАТЬ ТАБЛИЦЫ" не нужны, потому что клиентское соединение все равно закрывается в конце. Я положил его туда, потому что так людям удобнее.

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

Сначала убедитесь, что бинлоги включены. Сделайте снимок уровня файловой системы (например, LVM или аналогичный) каталога mysql под глобальной блокировкой чтения (FLUSH TABLES WITH READ LOCK). Используйте этот снимок для настройки нового сервера и настройки репликации в старую систему (вы можете выяснить имя и положение binlog (master_log_file/master_log_pos), посмотрев на размер новейшего бинлога в снимке).

Когда вы будете готовы к переходу, остановите все записи (read_only=true, уничтожьте все соединения) на старом сервере и дождитесь, пока новый сервер не догонит репликацию. Затем сделайте новый сервер доступным для записи и отключите старый.

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