Миграция базы данных: для чего нужна, примеры использования и как сделать
В статье подробно рассмотрим процесс миграции баз данных в облачную инфраструктуру. Но сначала поговорим о том, что это такое и зачем выполнять эту процедуру.
Что такое миграция базы данных
Под такой миграцией понимают два типа процессов:
- Однократное перемещение базы данных между системами с прекращением поддержки той системы, из которой осуществляется перенос.
- Преобразование базы данных, меняющее версию и затрагивающее схему (см. раздел «Основные понятия»). Это преобразование может быть как в виде апгрейда, так и отката, если возникает такая необходимость.
Для чего нужна миграция в базах данных
Почти каждая компания, работающая на рынке не первый год, накапливает немалый объем информации, причем достаточно разнородной. И, как правило, такая информация хранится в разных базах данных. В определенный момент у персонала возникают трудности с сопровождением, к тому же большинство из этих информационных систем устаревают, что накладывает ряд технических ограничений на их поддержку.
И для того, чтобы надежно защитить конфиденциальность информации, хранящейся в этих базах данных, как раз и проводят их миграцию. Миграция баз данных (БД) дает возможность избавиться от ограничений поддержки, поскольку БД переводятся под управление современных систем. Еще один случай, когда эта процедура также необходима — контроль версий ПО, если это ПО разрабатывается несколькими разработчиками. Если коротко, то миграция БД выполняется для:
- обеспечения безопасности и конфиденциальности данных;
- синхронизации кода и контроля версий при коллективной разработке приложений;
- облегчения масштабирования приложений и сайтов;
- повышения стабильности при работе с данными;
- импортозамещения СУБД;
- сокращения расходов по сопровождению ИС;
- полноценной работы с современными технологиями (большие данные, искусственный интеллект);
- увеличения производительности систем хранения данных.
Теперь давайте рассмотрим, как грамотно провести миграцию БД, но перед этим расшифруем несколько важных терминов для начинающих.
Основные понятия
- База данных (БД). Это набор однородных или разнородных данных, хранящихся по определенной схеме. Под схемой понимается структура с описанием содержимого БД. Схема представляется графически в виде таблиц, связей, индексов и ряда других элементов.
- Система управления базами данных (СУБД). Программное обеспечение, позволяющее создавать и управлять базами данных.
- Информационная система (ИС). Это система, объединяющая функции поиска, хранения и обработки данных, а также ПО, которое обеспечивает такую работу.
Далее для экономии места будем использовать следующие сокращения: БД, СУБД и ИС. Это главные понятия, но лучшее понимание темы обеспечит знание этих двух терминов:
- Источник — старая БД, подлежащая переносу.
- Приемник — новая БД, в которую переносятся данные из источника.
Также отметим, что данные часто хранятся в табличном виде (это зависит от СУБД). Выгружаются они из источника в виде файлов 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
Заключительные моменты
Чтобы обеспечить непрерывность миграции и избежать ошибок, требуется составить план переноса БД из источника в приемник. Отсутствие продуманной логики нередко приводит к нарушению бизнес-логики и дополнительным расходам, а то и к потерям корпоративных данных, что также влечет за собой финансовые, а иногда и репутационные потери.
План предусматривает также и аудит БД, в процессе которого проводится анализ формата данных и изучаются возможные проблемы сохранения конфиденциальности при миграции. Не менее важно решить вопросы с резервным копированием при переносе и установить временные рамки.
Также продумывается связность команд, налаживается беспроблемное общение между сотрудниками. Если все указанные выше моменты учитываются, шансы на успешную миграцию повышаются, а риски, наоборот, становятся минимальными.