Переезд базы данных без простоя: репликация, переключение, откат

Задача и критерии успеха: что считаем простоем

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

Фраза «переезд базы данных без простоя» на практике означает не «ничего не меняется», а «пользователи продолжают выполнять критичные операции, а риски потери данных и времени восстановления заранее ограничены». Иногда допустима небольшая деградация: отчеты работают медленнее, фоновые задачи временно стоят, витрины данных обновляются с задержкой. Но список того, что нельзя отключать ни при каких условиях, лучше закрепить сразу (например, прием платежей, оформление заказов, запись пациентов, авторизация).

До старта миграции перечислите, какие системы затрагиваются: основное приложение и API, отчеты и BI, интеграции и очереди (например, обмен с 1С, ESB, внешними партнерами), фоновые задания, админ-панели и мониторинг.

Критерии успеха удобно описывать через RPO и RTO простыми словами:

• RPO (Recovery Point Objective) - сколько данных вы готовы потерять в худшем случае. Например: «не больше 30 секунд изменений» или «потерь быть не должно».
• RTO (Recovery Time Objective) - как быстро система должна вернуться к нормальной работе после переключения или сбоя. Например: «все ключевые операции доступны за 5 минут».

Если эти цифры согласованы с владельцем процесса и ИТ, дальше проще выбрать репликацию, окна для проверок и честно оценить, получится ли переключение без заметного влияния на пользователей.

Инвентаризация: что нужно собрать до начала

Переезд базы данных без простоя начинается не с репликации, а с точных исходных данных. Если вы не знаете, что переносите и как это используется, вы не сможете ни рассчитать риски, ни выбрать способ переключения.

Соберите список баз и их параметры: движок и версия, размер на диске, количество таблиц, крупные объекты (индексы, партиции, LOB), а также темпы роста за последние 3-6 месяцев. Отдельно отметьте, что растет быстрее всего: данные, индексы, журналы транзакций, временные файлы.

Зафиксируйте профиль нагрузки в цифрах, а не общими словами. Обычно нужны пиковые RPS/QPS, доля чтений и записей, самые тяжелые запросы, средняя задержка и 95-й перцентиль. Если система работает 24/7, часто выясняется, что «тихого» времени нет, и это влияет и на момент свитча, и на настройки репликации.

Дальше - зависимости. База редко живет одна: приложения, фоновые воркеры, очереди, ETL, отчеты, интеграции с внешними сервисами. Полезно составить короткий реестр, чтобы не забыть «невидимого» потребителя, который отвалится в день миграции.

Минимум, который стоит оформить в одном документе:

• базы и версии, размеры, рост, требования к дискам;
• пики нагрузки и критичные запросы;
• зависимости и точки подключения (строки соединения, сервисные аккаунты);
• резервные копии: типы, расписание, где хранятся, как быстро восстанавливаются;
• ограничения: окна изменений, доступы, регуляторные требования и аудит.

Отдельно проверьте текущие точки отказа и реальную готовность бэкапов. Простая проверка: выбрать одну базу и выполнить тестовое восстановление на отдельный стенд с замером времени.

В конце уточните организационные ограничения: кто дает доступы на прод, кто согласует изменения, сколько времени занимает выпуск сертификатов или открытие портов. Именно такие мелочи чаще всего сдвигают график.

Выбор подхода: репликация и стратегия переключения

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

Физическая репликация копирует базу на уровне файлов и журнала транзакций. Она обычно проще и быстрее, хорошо подходит для больших объемов данных и стандартных сценариев высокой доступности, но чаще требует близких версий СУБД и одинакового типа хранилища.

Логическая репликация переносит изменения на уровне таблиц и операций. Она гибче при апгрейде версии, частичном переносе или изменениях схемы, но сложнее в настройке и чувствительнее к «краевым» случаям (триггеры, последовательности, DDL).

По направлению репликация бывает однонаправленной и двунаправленной. Однонаправленная проще и безопаснее для миграции: один источник истины и одна целевая копия. Двунаправленная помогает, когда нужно временно писать в оба места, но резко усложняет конфликты. Отдельный вариант - чтение с реплик: приложение читает с реплики, а пишет на мастер. Это снижает нагрузку на источник, но на время миграции важно учитывать задержку репликации.

Перед выбором подхода ответьте на практичные вопросы:

• нужно ли менять версию СУБД или тип хранилища (локальные диски, SAN, разные классы SSD);
• есть ли тяжелые записи (батчи, отчеты), которые создают пики на журнал;
• допустима ли задержка чтения на репликах (секунды) для пользователей;
• реально ли обеспечить одинаковую конфигурацию, включая кодировки, collation и настройки времени.

Сеть часто становится скрытым ограничением. Для стабильной репликации нужны предсказуемая задержка, достаточная пропускная способность и шифрование трафика. Если перенос идет между площадками, заранее измеряют RTT, проверяют MTU, настраивают приоритеты и убеждаются, что окно обслуживания не съедается ретраями.

Сложность свитча удобно оценивать по деталям:

• сколько приложений и интеграций держат прямые подключения к БД, и можно ли быстро поменять параметры;
• есть ли фоновые задания и очереди, которые нельзя запускать дважды;
• как быстро можно остановить запись и дождаться, пока реплика догонит (RPO близко к нулю);
• можно ли сделать пробный свитч в тесте с похожей нагрузкой.

Практика: если вы готовите новую площадку и параллельно обновляете версию СУБД, чаще выбирают логическую репликацию или смешанный подход. Если версии совпадают и важна скорость, физическая репликация обычно дает самый короткий и понятный свитч.

Пошаговый план переезда: от подготовки до готовности к свитчу

Начните с целевой среды. Она должна выдержать ту же нагрузку, что и текущая база: CPU, память, диск (IOPS и задержки), сеть, резервное копирование, мониторинг. Отдельно проверьте права: учетные записи приложений, доступ к секретам, правила фаервола, роли администраторов и то, кто имеет право делать финальное переключение.

Дальше настраивается репликация и выполняется начальная синхронизация. Заранее решите, какой режим нужен: асинхронный (обычно проще на расстояниях и при высокой нагрузке) или синхронный (меньше риск потери данных, но выше требования к сети). На первичной заливке следите, чтобы не забить диск журналами и не просадить производительность основной системы.

Когда репликация догонит текущую базу, переходите к параллельному прогону. Идеальный вариант - дать новой базе «тень» нагрузки: перенести часть чтений, повторять типовые операции через тестовый контур или, если архитектура позволяет, дублировать запись на уровне приложения. Цель простая: поймать проблемы с индексами, блокировками, настройками памяти и временем ответов.

Перед готовностью к свитчу закройте вопросы согласованности. Проверьте схему, версии расширений, настройки collation/таймзоны, наличие всех нужных job-ов, триггеров и прав. Для данных используйте контрольные суммы по ключевым таблицам и выборочные сверки бизнес-показателей (например, остатки, статусы заказов, баланс).

К этому моменту у вас должен быть короткий план ролей:

• кто ведет командный канал и фиксирует время событий;
• кто отвечает за репликацию и лаг;
• кто проверяет приложение и ключевые сценарии;
• кто принимает go/no-go и объявляет начало свитча;
• кто следит за метриками и ошибками.

Если инфраструктура работает 24/7, полезно заранее согласовать «окно повышенного внимания» и список людей на связи (включая поддержку и владельца продукта). Это снижает риск паузы уже в день переключения.

Тесты перед переключением: работоспособность и скорость

Перед свитчем нужно доказать две вещи: на новой базе все работает так же, как на старой, и система не станет медленнее. Если цель - переезд базы данных без простоя, времени на разбор полетов почти не будет.

Функциональные тесты: что должно пройти

Начните с самых частых и самых дорогих по ошибке операций. Проверяйте не все подряд, а то, что реально бьет по бизнесу: вход пользователей, создание и изменение ключевых документов, закрытие периода, печать и выгрузки, фоновые задания.

Хорошая практика - прогнать один и тот же набор действий на старой базе и на реплике, сравнить результат (числа, статусы, суммы) и зафиксировать расхождения. Если есть отчеты, проверьте хотя бы 2-3 «эталонных» отчета на одинаковом срезе данных.

Тесты производительности: метрики и пороги

Производительность проще оценивать понятными метриками, а не «ощущениями». Заранее договоритесь о порогах, после которых свитч запрещен:

• время ответа 5-10 ключевых запросов и операций;
• p95 времени ответа в час пик (например, из логов приложения);
• нагрузка CPU и диска на сервере БД под тестом;
• рост очередей, блокировок или ожиданий (если вы их измеряете);
• пропускная способность сети между приложением и БД.

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

Нужен и короткий тест отказоустойчивости: имитируйте падение узла (или остановку сервиса) и посмотрите, как быстро восстановится репликация и что увидит приложение. Лучше делать это на стенде, максимально похожем на прод.

В конце зафиксируйте результаты и подпишите готовность:

• список тестов и фактические цифры;
• согласованные пороги и факт их прохождения;
• текущий лаг репликации и оценка RPO/RTO;
• известные ограничения (что не проверяли и почему);
• решение «можно переключать» и кто за него отвечает.

Переключение без простоя: порядок действий и контроль

Переключение (switch) - короткий момент, когда основная работа начинает идти на новую базу. Чтобы переезд базы данных без простоя не превратился в серию сюрпризов, заранее зафиксируйте критерии успеха и то, что считается допустимым изменением в период свитча.

Самое важное - ввести режим «заморозки» изменений. Обычно это не полный запрет, а управляемое окно: вы временно останавливаете рискованные операции (массовые загрузки, тяжелые отчеты, миграции схемы), фиксируете версии приложений и ограничиваете ручные правки в админках.

Порядок действий при свитче

Логика простая: сначала защищаем запись, потом переводим чтение, и только после этого возвращаем фон.

• Переведите приложения в контролируемый режим: остановите фоновые задания, очереди и интеграции, которые пишут в БД.
• Дайте репликации догнать источник до нулевого лага и зафиксируйте момент (время, LSN/GTID, номер лога - что принято в вашей СУБД).
• Переведите запись на новую БД (или назначьте новый primary) и проверьте, что новые транзакции появляются только там.
• Переключите чтение: read-only сервисы, отчеты, прогрев кэша, затем пользовательские запросы.
• Включайте фоновые задачи по одной, начиная с самых безопасных, и следите за ростом нагрузки.

Перенастройка соединений должна быть предсказуемой: DNS/виртуальный IP, единая строка подключения, одинаковые учетные записи и права. Если используете пул соединений, заранее настройте короткий TTL и убедитесь, что приложение переподключается без ручного перезапуска.

Контроль первых часов

Первые 1-2 часа проверяйте метрики каждые 15 минут и фиксируйте их в журнале смены.

• Ошибки приложений: рост 5xx, timeouts, ошибки транзакций и блокировок.
• Производительность БД: p95/p99 задержек, длина очередей, CPU/IO, конкуренция за блокировки.
• Целостность данных: счетчики ключевых сущностей, свежесть критичных таблиц, корректность фоновых обработок.
• Репликация/резерв: статус репликации в обратную сторону (если включена), актуальность бэкапа.

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

План отката: что делаем, если что-то пошло не так

Откат - это не «провал», а заранее согласованный способ быстро вернуть систему в стабильное состояние. Хороший план отката работает только тогда, когда у него есть четкие триггеры, понятный владелец решения и короткий путь назад.

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

«Обратный свитч» продумайте так же тщательно, как основной. Чаще всего он сводится к переключению точки записи (конфиг приложения, балансировщик, DNS, флаг в настройках) и немедленной блокировке записи в новую БД, чтобы не получить двойную запись.

Если откат неизбежен, главный вопрос - что делать с изменениями, которые уже попали в новую базу. Базовые варианты:

• временно заморозить критичные операции (например, создание документов), чтобы остановить рост расхождений;
• сохранить изменения из новой БД в отдельный журнал (таблица, экспорт, очередь сообщений) для последующего дозалива;
• зафиксировать точку времени/LSN и сохранить логи, чтобы потом аккуратно восстановить события.

Решение об откате должен принимать один ответственный человек (дежурный руководитель смены). Статус фиксируют сразу: время, причина, текущая точка переключения, что уже сделано и что команде запрещено делать (например, запуск миграций схемы).

После отката нужна отдельная проверка корректности. Минимум: приложение снова пишет в старую БД, ключевые пользовательские сценарии проходят, фоновые задачи работают, метрики вернулись к норме, а данные за окно переключения либо отсутствуют, либо учтены в журнале для последующего переноса.

Типичные ошибки и ловушки при миграции БД

Даже если репликация настроена и свитч выглядит простым, проблемы часто появляются не в самой БД, а вокруг нее. При переезде базы данных без простоя мелкая недоговоренность или «потом проверим» легко превращается в инцидент.

Частые ошибки:

• Забывают про зависимости: очереди, планировщики задач, отчеты, внешние интеграции, кэш, файловые хранилища. В итоге «приложение работает», но платежи не проходят или отчеты не строятся.
• Делают свитч, не измеряя задержку репликации. Если отставание было 30-60 секунд, вы теряете последние записи или получаете расхождения.
• Тестируют «на глаз», но не под пиковыми нагрузками. На новом сервере все быстро утром, а в 11:00 начинаются таймауты, блокировки и очереди.
• Слишком поздно проверяют доступы: права пользователя приложения, доступ из подсетей, сертификаты, правила firewall, DNS, параметры шифрования. Правки в последний час обычно самые рискованные.
• Не назначают ответственных и не продумывают коммуникации. Когда что-то идет не так, нет ясности, кто останавливает свитч, кто откатывает, кто сообщает бизнесу.

Хороший способ поймать эти ловушки - короткая репетиция «дня Х» на тестовом контуре: измерить лаг репликации, прогнать типовые операции пользователей и обязательно имитировать пик (параллельные запросы, отчеты, ночные джобы). Даже если инфраструктуру поставляет производитель, это не отменяет проверок сети, доступов и реального нагрузочного профиля.

Чтобы снизить риск, держите набор простых правил: зафиксируйте зависимости и владельцев интеграций, перед свитчем снимите метрики репликации и согласуйте допустимый максимум, проведите нагрузочный тест на новом контуре, а доступы и сертификаты проверьте за несколько дней, а не в день работ.

Короткий чек-лист перед днем переключения

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

Сначала зафиксируйте ожидания бизнеса. RPO и RTO должны быть конкретными числами и письменно согласованными: сколько данных можно потерять и сколько времени система может работать в режиме переключения.

Дальше проверьте организационную часть: у каждой зависимости должен быть владелец и понятный способ связи. Нередко «мелочь» вроде отчета, который ходит в старую БД раз в час, срывает весь план.

Перед днем переключения отметьте как выполненные:

• согласованы RPO и RTO, окно работ и правила коммуникации;
• собран список зависимостей (приложения, интеграции, отчеты, планировщики), владельцы назначены и доступны в день свитча;
• мониторинг и алерты включены заранее на обеих сторонах: лаг репликации, ошибки, нагрузка, свободное место, время ответа;
• тесты производительности проведены на целевой стороне, пороги зафиксированы (например, «вход в систему до 2 секунд», «отчет до 30 секунд»);
• план отката описан и отрепетирован на тестовой среде.

Последняя проверка - «сухой прогон» сценария на 10-15 минут: команда вслух проговаривает порядок действий и точки контроля. Кто подтверждает, что реплика догнала, кто переключает приложение, кто смотрит метрики после свитча, кто держит связь с пользователями.

Пример сценария: переезд БД для системы 24/7

Представим компанию, у которой CRM и биллинг работают круглосуточно. Днем идут продажи и обращения в поддержку, а основной пик операций по счетам и оплатам приходится на вечер. Остановить базу даже на 15 минут нельзя: за это время копятся ошибки в интеграциях и растет очередь задач.

Выбирают подход с репликацией: поднимают новую БД на целевом сервере и настраивают постоянную передачу изменений с текущей базы. Затем идет параллельное тестирование, пока пользователи продолжают работать на старой системе. Переключение планируют на ночь, когда нагрузка минимальна, но команда на связи.

Как тестировать копию и не мешать пользователям

Тесты проводят на копии новой БД (или на реплике в режиме read-only), чтобы не создавать лишнюю нагрузку на рабочую базу. Для реалистичности берут свежий срез данных и прогоняют типичные цепочки: поиск клиента, создание сделки, выставление счета, проведение оплаты, выгрузки отчетов.

Чтобы убрать риск неожиданностей, обычно:

• запускают нагрузочные прогоны в окна низкой активности;
• проверяют самые тяжелые отчеты и фоновые задания;
• сравнивают результаты ключевых запросов: время ответа и число блокировок;
• тестируют интеграции: платежный шлюз, телефония, почта, обмен с бухгалтерией.

Решение о переключении по метрикам

Решение о свитче принимают не по ощущениям, а по цифрам. Например: задержка репликации держится в пределах нескольких секунд, время ответа на критические операции не хуже текущего, ошибок в логах нет, а ночной прогон нагрузки показывает запас по CPU, диску и сети.

Перед самым переключением делают короткую паузу на запись (обычно минуты): временно блокируют операции, которые меняют данные, дожидаются полного догоняния реплики и фиксируют контрольные метрики (количество записей в ключевых таблицах, контрольные суммы, статусы очередей).

Откат выглядит так же конкретно: если после свитча растут ошибки или резко падает скорость, приложение возвращают на старую БД, а новую отключают от записи. В хорошо подготовленном плане это занимает 10-20 минут: вернуть конфиги подключения, убедиться, что пользователи снова пишут в старую базу, и зафиксировать, какие данные успели попасть в новую систему.

Следующие шаги: как подготовить проект и инфраструктуру

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

Дальше соберите рабочую группу и договоритесь о правилах общения на время работ: один канал, один ответственный за решения, фиксация изменений по ходу. Обычно нужны DBA, инфраструктура, разработка, эксплуатация/поддержка и бизнес-владелец.

Затем подготовьте один общий документ, который живет до и после свитча: расписание по минутам, точки контроля, критерии «можно переключаться», метрики (лаг репликации, число ошибок, время ответа ключевых операций) и план отката с порогами «откатываемся без обсуждений». Если откат сложнее переключения, план еще сырой.

Первый опыт не переносите сразу на прод. Запланируйте репетицию на тестовом контуре: прогоните полный сценарий, включая смену конфигураций приложений, проверку прав, прогрев кэшей и возврат назад.

Инфраструктуру подбирайте по целевой нагрузке и росту на 12-24 месяца: CPU, память, диски по IOPS и задержкам, сеть, отдельные каналы для репликации, резервное копирование и восстановление. Если вы собираете новую площадку под критичные сервисы, бывает удобно закрыть и «железо», и интеграцию в одном месте - например, через GSE.kz (gse.kz), который в Казахстане производит серверы и оказывает услуги системной интеграции и поддержки 24/7.