Перенос базы часто выглядит простой задачей: сделать дамп, загрузить его на новую машину и заменить адрес в настройках сайта. На тестовом стенде такая последовательность может сработать. На работающем магазине между началом копирования и переключением продолжают появляться заказы, меняются остатки и приходят ответы платёжной системы.
Поэтому главный вопрос переезда — как сохранить согласованное состояние и понять, куда в каждый момент записываются данные. Размер дампа влияет на длительность операции, но не описывает весь риск. Нужны репетиция, контрольные проверки и заранее выбранный способ завершить перенос либо вернуться к прежнему месту работы.
Снимите исходные параметры
Запишите СУБД, версию, объём данных, кодировки, расширения и режимы работы. Уточните, какие приложения подключаются к базе помимо сайта: обмен с учётной системой, отчёты, фоновые задания, отдельные скрипты. После переноса забытый обработчик может продолжить записывать данные на старый сервер.
Проверьте пользователей и права. Учётная запись приложения не должна получать административные полномочия только потому, что так проще выполнить импорт. Отдельно сохраните сведения о служебных объектах, заданиях и настройках, которые выбранная процедура дампа не включает автоматически. Секреты передают защищённым способом, а не в общем документе с планом работ.
Проверьте совместимость на копии
Версии сервера и клиента должны поддерживать выбранный маршрут переноса. Нельзя рассчитывать, что любая более новая база загрузит старую без изменений или что дамп новой версии подойдёт для старой. Различия кодировок, правил сравнения и SQL-режимов способны проявиться только на отдельных операциях приложения.
Восстановите пробную копию и выполните типовые действия: вход, поиск, изменение карточки, создание заказа и выполнение фонового задания. Отключите реальные письма, платежи и внешние обмены. Успешная главная страница не проверяет запись, права и редкие запросы. Организацию безопасной площадки можно сверить со статьёй о тестовой копии сайта.
Измерьте время и нагрузку
Репетиция даёт практические цифры: сколько занимает создание копии, передача, восстановление, построение индексов и запуск проверок. Для активной базы важна и нагрузка на исходный сервер. Метод, который подходит небольшой базе, может оказаться слишком долгим при большом объёме.
Сравните время выполнения характерных запросов, число соединений, память и задержку сети между приложением и новым сервером. Если раньше они находились на одной машине, дополнительная сеть меняет условия работы. Не принимайте улучшение синтетического теста диска за доказательство ускорения магазина: нужен тот же пользовательский сценарий и сопоставимая нагрузка.
Определите границу переключения записи
Для небольшого проекта может подойти согласованное окно обслуживания с остановкой записи. В него входят не только формы на сайте, но и обработчики очередей, обмены и служебные процессы. Посетителю нужно показывать понятное состояние, а новые уведомления внешних систем — обрабатывать по заранее проверенному порядку.
При более сложных требованиях рассматривают репликацию и контролируемое переключение. Она требует совместимости, наблюдения за отставанием и процедуры назначения нового основного узла. Одна лишь включённая репликация не гарантирует перенос без потерь. Конкретную схему выбирают по допустимому перерыву и возможностям приложения, а не по обещанию «без простоя».
В плане должны быть явно указаны:
- момент прекращения записи на старую базу;
- проверка полноты перенесённых изменений;
- переключение всех клиентов и фоновых процессов;
- разрешение записи на новом месте;
- ответственный за проверку и решение о продолжении.
Подготовьте возврат с учётом новых данных
До первой записи в новую базу возврат обычно проще. После неё прежняя база уже отстаёт. Простая замена адреса обратно может спрятать созданные заказы и привести к повторной обработке операций. Нужно заранее решить, как будут сохраняться и переноситься изменения после переключения.
Определите признаки, при которых переезд останавливают: ошибки записи, потерянные связи, недопустимая задержка или нарушение важного обмена. Для каждого случая требуется конкретное действие. Общий порядок безопасного возврата описан в статье об откате изменений, но для базы его дополняют планом работы с новыми записями.
Завершите перенос проверкой бизнеса
Сопоставьте контрольные заказы, пользователей, вложения и последние изменения. Проверьте журналы ошибок, фоновые задачи и внешние подключения. Убедитесь, что резервирование теперь работает с новой базой и его действительно можно восстановить. Старый сервер сохраняют на согласованный срок с ограниченным доступом и без случайной записи.
Отдельно проверьте время на обеих машинах и поведение полей с датами. Перенос может совпасть с изменением часового пояса окружения и проявиться в отчётах, расписании или сортировке заказов. Выберите записи с известным временем и сравните их в базе и интерфейсе. Не исправляйте все значения массово до выяснения, где именно выполняется преобразование и какой формат считался исходным в прежней конфигурации.
После завершения обновите схему подключения в документации и перечень разрешённых адресов. Старые реквизиты отзывают после подтверждения, что забытых клиентов больше нет. Это отдельный шаг закрытия работ, а не часть первоначального переключения.
Если вы готовите перенос базы, напишите в HOMEWEB. Разберу зависимости сайта, помогу провести репетицию и составить порядок переключения с понятными контрольными точками.
