Не стоит недооценивать сложность этой миграции.
При 100 ГБ можно предположить, что большинство строк в ваших таблицах не получают UPDATEd или DELETEd.
Чтобы мое предложение сработало, вам потребуется способ
SELECT * FROM table WHERE (the rows are new or updated since a certain date)
Некоторые таблицы только для INSERT будут иметь автоинкрементные значения идентификаторов. В этом случае вы можете определить значение отсечения идентификатора между старым и новым. Другие таблицы могут быть ОБНОВЛЕНЫ. Если у этих таблиц нет временных отметок, указывающих, когда они были обновлены, вам будет сложно выяснить это. Вы должны понимать свои данные, чтобы сделать это. Ничего страшного, если ваша WHERE (new or updated) операция займет несколько дополнительных строк, которые старше. Это не нормально, если пропущены строки INSERTed или UPDATEd.
Как только вы знаете, как это сделать для каждой большой таблицы, вы можете начать миграцию.
Массовая миграция Сохранение ваших Старая система в сети и активна, вы можете использовать mysqldump для переноса ваших данных на новый сервер. Вы можете занять столько времени, сколько вам потребуется. Прочитайте это для некоторых предложений. получение Потерянного соединения с mysql при использовании mysqldump даже с параметром max_allowed_packet
Тогда у вас будет устаревшая копия данных на новом сервере. Убедитесь, что индексы построены правильно. Возможно, вы захотите использовать OPTIMIZE TABLE во вновь загруженных таблицах.
Обновление миграции Затем вы можете использовать ваши запросы WHERE (the rows are new or updated) для переноса строк, которые изменились с момента переноса всей таблицы. , Опять же, вы можете занять столько времени, сколько хотите, сохраняя свою старую систему в сети. Это должно занять гораздо меньше времени, чем ваша первая миграция, поскольку она будет обрабатывать гораздо меньше строк.
Окончательная миграция, автономный режим Наконец, вы можете перевести систему в автономный режим и перенести оставшиеся строки. те, которые изменились со времени вашей последней миграции. И перенести ваши маленькие столы во всей их полноте, снова. Затем запустите вашу новую систему.
Да, но вы говорите, как я узнаю, что я все сделал правильно?
Для достижения наилучших результатов вы должны написать сценарий перехода, и использовать сценарии. Таким образом, ваш последний шаг миграции будет быстро go.
Вы можете отрепетировать этот процесс на локальном сервере в вашем офисе. Хотя размер базы данных составляет 100 ГБ, это не слишком большой объем дискового пространства на компьютере с настольным компьютером или серверной.
Сохраните очень большие извлеченные файлы из шага массовой миграции, чтобы вы могли можете повторно использовать их, когда вы набрасываете свои первые попытки загрузить их. Таким образом вы сохраните повторную загрузку извлечения в вашей старой системе.
Вы должны поставить промежуточную копию перенесенной базы данных (у вашего нового облачного провайдера) и протестировать ее с промежуточная копия вашей заявки. Вы можете сделать это с небольшим подмножеством ваших строк. Но проверьте этот последний шаг миграции с этой копией, чтобы убедиться, что она работает.
Будьте готовы к быстрому откату к старой системе, если новая выйдет из строя.
И, возможно, это возможность удалить старые данные перед миграцией. Этот вид миграции достаточно сложен, чтобы вы могли найти экономическое обоснование для извлечения, а затем удаления старых строк со старого сервера перед началом миграции.