В статье подробно рассмотрим процесс миграции баз данных в облачную инфраструктуру. Но сначала поговорим о том, что это такое и зачем выполнять эту процедуру.
Под такой миграцией понимают два типа процессов:
Почти каждая компания, работающая на рынке не первый год, накапливает немалый объем информации, причем достаточно разнородной. И, как правило, такая информация хранится в разных базах данных. В определенный момент у персонала возникают трудности с сопровождением, к тому же большинство из этих информационных систем устаревают, что накладывает ряд технических ограничений на их поддержку.
И для того, чтобы надежно защитить конфиденциальность информации, хранящейся в этих базах данных, как раз и проводят их миграцию. Миграция баз данных (БД) дает возможность избавиться от ограничений поддержки, поскольку БД переводятся под управление современных систем. Еще один случай, когда эта процедура также необходима — контроль версий ПО, если это ПО разрабатывается несколькими разработчиками. Если коротко, то миграция БД выполняется для:
Теперь давайте рассмотрим, как грамотно провести миграцию БД, но перед этим расшифруем несколько важных терминов для начинающих.
Далее для экономии места будем использовать следующие сокращения: БД, СУБД и ИС. Это главные понятия, но лучшее понимание темы обеспечит знание этих двух терминов:
Также отметим, что данные часто хранятся в табличном виде (это зависит от СУБД). Выгружаются они из источника в виде файлов xls — это универсальный формат, который читается большинством систем. А загружаются в приемник с использованием шаблонов, представляющих собой файлы описания.
Существует несколько разновидностей миграции данных. Часть из них относятся к хранимым данным и приложениям. Такие виды миграции связаны либо с преобразованием хранимых данных в новый формат, либо с модернизацией ПО. А миграция БД осуществляется одним из двух способов:
Миграция БД выполняется ручным способом или автоматически. Выбор зависит от текущих условий. Так, если в компании используется старая СУБД, поддержка которой давно прекращена, трудности при переносе неизбежны, поэтому мигрировать почти наверняка придется вручную. Теперь давайте рассмотрим подготовку к полной и версионной миграции БД.
Организационные моменты включают выбор технологий переноса, определение правил настройки доступа для участвующих в процессе. Также важно продумать, как будет выполняться постмиграционное тестирование и исправление ошибок, которые возникают даже в тех случаях, когда всё выполнено, вроде бы, идеально.
В рабочую группу входят две команды IT-специалистов, которые разбираются в источнике и приемнике (каждая команда в своей СУБД). В обязанности отдельных сотрудников входит мониторинг процесса. Причем мониторинг желательно проводить вне зависимости от того, будет ли проведена миграция вручную или автоматически.
Следующий момент — определение объема данных, подлежащих переносу, и их состава. Также в рамках подготовки важно предусмотреть, что делать в случае возникновения нештатных ситуаций. Например, если случились сбои или ошибки (например, была нарушена целостность и корректность хранимых данных), у команды должны быть предусмотрены методы безболезненного отката БД к исходному состоянию.
Технологические моменты включают следующее:
Версионная миграция БД — распространенная процедура, когда необходим контроль версий ПО, которое разрабатывается несколькими разработчиками. Она позволяет избежать рассинхронизации при отправке новых версий ПО в продакшн. Этот процесс имеет свою специфику: важно при версионной миграции БД соблюдать последовательность переноса данных и сделать так, чтобы каждый SQL-запрос выполнялся однократно. В противном случае возможны потери данных, и тогда придется задействовать бэкап для восстановления.
Версионная миграция БД выполняется по-разному. Это, например, методы инкрементных и идемпотентных изменений или уподобление структуры БД исходному коду. Для каждого из этих методов предусмотрен набор инструментов, позволяющих автоматизировать процесс и свести к минимуму количество ошибок. Выбор метода определяется рядом принципов:
Теперь рассмотрим, как выполняется миграция БД в нескольких распространенных системах. И для начала руководство по переносу в облако БД на 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 для решения задач по миграции БД используются инструкции, которые, как и сам фреймворк, работают в коде на Python. Главные инструкции следующие:
makemigrations
— создает файл миграции, содержащий код схемы;migrate
— создает таблицу по схеме из файла миграции;sqlmigrate
— отображает необработанные SQL-запросы выполненной миграции;showmigrations
— перечисляет миграции с указанием их статуса.Эти инструкции имеют такой вид:
$ python3 manage.py migrate
Чтобы обеспечить непрерывность миграции и избежать ошибок, требуется составить план переноса БД из источника в приемник. Отсутствие продуманной логики нередко приводит к нарушению бизнес-логики и дополнительным расходам, а то и к потерям корпоративных данных, что также влечет за собой финансовые, а иногда и репутационные потери.
План предусматривает также и аудит БД, в процессе которого проводится анализ формата данных и изучаются возможные проблемы сохранения конфиденциальности при миграции. Не менее важно решить вопросы с резервным копированием при переносе и установить временные рамки.
Также продумывается связность команд, налаживается беспроблемное общение между сотрудниками. Если все указанные выше моменты учитываются, шансы на успешную миграцию повышаются, а риски, наоборот, становятся минимальными.