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

Что такое миграция базы данных

Под такой миграцией понимают два типа процессов:

1. Однократное перемещение базы данных между системами с прекращением поддержки той системы, из которой осуществляется перенос.
2. Преобразование базы данных, меняющее версию и затрагивающее схему (см. раздел «Основные понятия»). Это преобразование может быть как в виде апгрейда, так и отката, если возникает такая необходимость.

Для чего нужна миграция в базах данных

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

И для того, чтобы надежно защитить конфиденциальность информации, хранящейся в этих базах данных, как раз и проводят их миграцию. Миграция баз данных (БД) дает возможность избавиться от ограничений поддержки, поскольку БД переводятся под управление современных систем. Еще один случай, когда эта процедура также необходима — контроль версий ПО, если это ПО разрабатывается несколькими разработчиками. Если коротко, то миграция БД выполняется для:

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

Теперь давайте рассмотрим, как грамотно провести миграцию БД, но перед этим расшифруем несколько важных терминов для начинающих.

Основные понятия

• База данных (БД). Это набор однородных или разнородных данных, хранящихся по определенной схеме. Под схемой понимается структура с описанием содержимого БД. Схема представляется графически в виде таблиц, связей, индексов и ряда других элементов. 
• Система управления базами данных (СУБД). Программное обеспечение, позволяющее создавать и управлять базами данных.
• Информационная система (ИС). Это система, объединяющая функции поиска, хранения и обработки данных, а также ПО, которое обеспечивает такую работу.

Далее для экономии места будем использовать следующие сокращения: БД, СУБД и ИС. Это главные понятия, но лучшее понимание темы обеспечит знание этих двух терминов:

• Источник — старая БД, подлежащая переносу.
• Приемник — новая БД, в которую переносятся данные из источника.

Также отметим, что данные часто хранятся в табличном виде (это зависит от СУБД). Выгружаются они из источника в виде файлов xls — это универсальный формат, который читается большинством систем. А загружаются в приемник с использованием шаблонов, представляющих собой файлы описания.

Виды миграции данных

Существует несколько разновидностей миграции данных. Часть из них относятся к хранимым данным и приложениям. Такие виды миграции связаны либо с преобразованием хранимых данных в новый формат, либо с модернизацией ПО. А миграция БД осуществляется одним из двух способов:

• Полная. Перенос всей БД из источника в приемник (чаще всего из локальной среды в облако).
• Версионная. Обновление БД до последней версии для достижения совместимости ПО.

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

Полная миграция БД

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

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

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

Технологические моменты включают следующее:

• Подготовка шаблонов загрузки данных, в которых содержатся технические описания. Это, например, поля и правила их заполнения в том случае, если выполняется миграция между разнородными системами.
• Определение списка источников выгрузки данных в случае, если их несколько. Это позволит избежать несогласованности при переносе.
• Выгрузка данных. Скорость процесса зависит от разных факторов, и чем дольше выполняется выгрузка, тем больше рисков. Поэтому стоит заранее позаботиться о том, чтобы этот процесс прошел безболезненно. Для этого перед выгрузкой проводятся тесты.
• Сопоставление исходных и загрузочных данных или Data mapping. Этот процесс нередко занимает по объему до половины от всего процесса переноса. Также в рамках мэппинга создаются правила преобразования данных, подлежащих миграции. Эти правила пишутся в виде скриптов.
• Далее данные выгружаются из источника, трансформируются и загружаются в приемник. Причем для начала лучше провести тестовые процедуры и при необходимости внести коррективы еще до реального переноса.
• Завершающий этап — сверка данных для проверки их работоспособности. Впрочем, как мы уже отметили выше, проверять данные желательно на каждом этапе миграции.

Версионная миграция БД

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

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

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

Миграция базы данных в популярных системах

Теперь рассмотрим, как выполняется миграция БД в нескольких распространенных системах. И для начала руководство по переносу в облако БД на PostgreSQL.

Миграция базы данных PostgreSQL

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

• Для этого используется команда ALTER ROLE <name> WITH REPLICATION, где вместо <name> указывается имя пользователя.
• Теперь открываем postgresql.conf и выставляем там следующее значение: wal_level = logical.
• Далее выполняется настройка аутентификации в pg_hba.conf в строчках host следующим образом:

host  all              all <host> md5
host  replication all <host> md5

• <host> здесь нужно заменить на IP или DNS приемника;
• перезапускаем СУБД инструкцией systemctl restart postgresql.

Теперь выполняем перенос схемы БД. Здесь соблюдаем следующее условие: схемы БД в источнике и приемнике должны быть одинаковыми. А для переноса используются специальные утилиты под названием pg_dump и pg_restore.

Последний этап — создание публикации в источнике и подписки в приемнике. Создать публикацию можно только с правами superuser, а делается это при помощи следующей инструкции: CREATE PUBLICATION <name> FOR ALL TABLES, где вместо <name> указывают название публикации. Для создания подписки в приемнике потребуется доступ администратора dbaas_admin. Подписка создается инструкцией CREATE SUBSCRIPTION <name> CONNECTION, где вместо <name> указывают название подписки.

Заметим, что репликация последовательностей (sequences) невозможна, так что потребуется предварительно восстановить в приемнике дамп с ними. Кроме того, в приемнике еще и понадобится заранее сбросить подписку, что делается командой DROP SUBSCRIPTION.

Для создания дампа используют уже упомянутые выше утилиты pg_dump и pg_restore, а дамп в приемнике восстанавливают при помощи еще одной утилиты под названием psql. Добавим, что дамп БД PostgreSQL создают как в формате SQL, так и в кастомном, если нужно восстановить отдельные элементы БД (например, схему или некоторые таблицы).

Миграция базы данных Django

В Django для решения задач по миграции БД используются инструкции, которые, как и сам фреймворк, работают в коде на Python. Главные инструкции следующие:

• makemigrations — создает файл миграции, содержащий код схемы;
• migrate — создает таблицу по схеме из файла миграции;
• sqlmigrate — отображает необработанные SQL-запросы выполненной миграции;
• showmigrations — перечисляет миграции с указанием их статуса.

Эти инструкции имеют такой вид:

$ python3 manage.py migrate

Заключительные моменты

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

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

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