Мастер миграции (миграция данных/схемы)

Вы переносите данные/схему. Миграция однородная или разнородная и какова допустимость простоя? Спланируйте шаг за шагом: оценка → миграция → проверка. Сначала отрепетируйте cutover здесь.

Откуда и куда вы выполняете миграцию?

Гомогенная: тот же движок базы данных (например, Oracle 19 → Oracle 23 или PostgreSQL на другой сервер). Гетерогенная: другой движок (например, Oracle → PostgreSQL, MySQL → SQL Server). Гетерогенные миграции требуют гораздо больше работы по совместимости (типы данных, функции, PL/SQL).

• Тот же движок, новый сервер/версия (гомогенная)
• На другой движок (гетерогенная)
• Я на этапе планирования; с чего начать?

Какой простой допустим?

Это определяет метод миграции. Если есть окно обслуживания, самый простой путь — dump/restore. Если нужен почти нулевой простой, вы загружаете начальные данные, поддерживаете синхронизацию непрерывной репликацией (CDC) и выполняете короткий cutover.

• Есть окно обслуживания (простой допустим)
• Нужен почти нулевой простой

Оценили ли вы совместимость схемы и типов?

В разнородной миграции основная работа — не копирование данных, а устранение различий: типы данных (VARCHAR2↔TEXT), функции (NVL↔COALESCE), значения автоинкремента, PL/SQL ↔ PL/pgSQL, удалённые/отличающиеся возможности.

• Я сопоставил различия схемы/типов
• Я ещё не оценивал их

Сначала оцените совместимость

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

Офлайн-миграция (dump / restore)

Самый простой и надёжный однородный метод: сделайте согласованный бэкап, загрузите его в цель, проверьте, переключитесь.

Минимальный простой (CDC / репликация)

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

Разнородная миграция (на другую СУБД)

Конвертируйте схему, перенесите данные, адаптируйте логику, проверьте. Двигайтесь поэтапно; не переносите всё за один раз.