Миграция локальной базы данных PostgreSQL в Azure

  • 19 мин

После принятия решения о переходе на Базу данных Azure для PostgreSQL необходимо спланировать процесс переноса локальных баз данных и выбрать средства для перемещения данных.

Вы ознакомились с возможностями Базы данных Azure для PostgreSQL по поддержке и масштабированию PostgreSQL в Azure, и теперь вам нужно подумать о переносе существующих локальных баз данных.

На этом занятии вы узнаете, как создать экземпляр Базы данных Azure для PostgreSQL с помощью портала Azure. Если необходимо создать несколько экземпляров этой службы, можно воспользоваться интерфейсом командной строки Azure и написать соответствующий скрипт для этого процесса.

Создание гибких серверов База данных Azure для PostgreSQL

В портал Azure введите гибкие серверы База данных Azure для PostgreSQL в поле поиска и выберите База данных Azure для PostgreSQL гибкие серверы.

Screenshot showing the Azure Database for PostgreSQL flexible servers item in the Azure portal.

В колонке "Гибкий сервер" введите сведения о службе. Они могут включать:

  • Группа ресурсов. Группа ресурсов для сервера.

  • Имя сервера. Должно быть уникальным именем длиной от 3 до 63 символов, содержащим только строчные буквы, цифры и дефисы.

  • Регион. Регион сервера.

  • Версия PostgreSQL: выберите версию, соответствующую локальной базе данных, которую вы переносите.

  • Тип рабочей нагрузки. Выберите параметр на основе рабочей нагрузки.

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

  • Имя администратора. Имя учетной записи пользователя, которая будет создана с правами администратора. Azure создает некоторые учетные записи для собственного использования. Нельзя использования имена azure_superuser, azure_pg_admin, admin, administrator, root, guest, public или любые другие, начинающиеся с pg_.

  • Пароль. Должен иметь длину от 8 до 128 символов. Пароль должен состоять из прописных и строчных букв, цифр и символов, отличных от алфавитно-цифровых.

Screenshot showing a sample configuration for Azure Database for PostgreSQL flexible server in the Azure portal.

Щелкните Проверить и создать, чтобы развернуть службу. Развертывание может занять несколько минут.

После развертывания службы выберите параметр Безопасность подключения и добавьте соответствующие правила брандмауэра, чтобы разрешить подключение клиентов, как описано в разделе Подключение клиентов на занятии 1. Также необходимо выбрать параметр Разрешить доступ к службам Azure.

Создание экземпляра Базы данных Azure для PostgreSQL с помощью Azure CLI

Создать экземпляр Базы данных Azure для PostgreSQL можно с помощью команды az postgres flexible-server create. В приведенной ниже инструкции показан пример создания гибкого экземпляра сервера. Большинство параметров не требуют пояснений, за исключением следующих.

  • sku-name. Создается на основе сочетания следующих характеристик: ценовая категория (B — "Стандартная", GP — "Общего назначения" и MO — "Оптимизированная для операций в памяти"), поколение вычислительных ресурсов (4-е или 5-е поколения) и количество виртуальных ядер ЦП. В приведенном ниже примере сервер создается с использованием ценовой категории "Общего назначения" с четырьмя ядрами ЦП 5-го поколения.
  • storage-size. Это необходимый объем дискового пространства, указанный в мегабайтах. В следующем примере выделяется 10 гигабайт: 
    az postgres flexible-server create \
--location northeurope --resource-group testGroup \
--name testserver --admin-user username --admin-password password \
--sku-name Standard_B1ms --tier Burstable --public-access 153.24.26.117 --storage-size 128 \
--tags "key=value" --version 13 --high-availability Enabled --zone 1 \
--standby-zone 3

Выполнение миграции по сети

С помощью службы Azure Database Migration Service можно выполнить миграцию по сети из локальной установки PostgreSQL в Базу данных Azure для PostgreSQL.

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

Настройка исходного сервера и экспорт схемы

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

wal_level = logical
max_replication_slots = 5
max_wal_senders = 10

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

pg_dump -o -h [server host] -U [user name] -d [database name] -s > db_schema.sql

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

SELECT *
FROM pg_extension;

Создание целевой базы данных и импорт схемы

На следующем этапе необходимо создать целевую базу данных в Базе данных Azure для PostgreSQL. Для подключения к серверу используется привычный инструмент, например pgAdmin. Либо можно воспользоваться Azure CLI, как показано в следующем примере.

az postgres db create \
  --name [database name] \
  --server-name [server name] \
  --resource-group [azure resource group]

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

Импортируйте схему в целевую базу данных. На компьютере, на котором находится файл db_schema.sql, выполните следующую команду:

psql -h [Azure Database for PostgreSQL host] -U [user name] -d [database name] -f db_schema.sql

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

SELECT Queries.tablename
       ,concat('alter table ', Queries.tablename, ' ', STRING_AGG(concat('DROP CONSTRAINT ', Queries.foreignkey), ',')) as DropQuery
            ,concat('alter table ', Queries.tablename, ' ',
                                            STRING_AGG(concat('ADD CONSTRAINT ', Queries.foreignkey, ' FOREIGN KEY (', column_name, ')', 'REFERENCES ', foreign_table_name, '(', foreign_column_name, ')' ), ',')) as AddQuery
    FROM
    (SELECT
    tc.table_schema,
    tc.constraint_name as foreignkey,
    tc.table_name as tableName,
    kcu.column_name,
    ccu.table_schema AS foreign_table_schema,
    ccu.table_name AS foreign_table_name,
    ccu.column_name AS foreign_column_name
FROM
    information_schema.table_constraints AS tc
    JOIN information_schema.key_column_usage AS kcu
      ON tc.constraint_name = kcu.constraint_name
      AND tc.table_schema = kcu.table_schema
    JOIN information_schema.constraint_column_usage AS ccu
      ON ccu.constraint_name = tc.constraint_name
      AND ccu.table_schema = tc.table_schema
WHERE constraint_type = 'FOREIGN KEY') Queries
  GROUP BY Queries.tablename;

Отключите все триггеры в целевой базе данных. Для этого есть две причины.

  • Это помогает оптимизировать процесс миграции по мере копирования данных.
  • Триггеры часто используются для реализации сложных форм ссылочной целостности, и по причинам, описанным выше, этот тип проверки целостности может завершиться ошибкой во время передачи данных. Используйте следующую инструкцию SQL, чтобы найти все триггеры в базе данных и создать скрипт, который отключает их: 
    SELECT concat ('alter table ', event_object_table, ' disable trigger ', trigger_name)
FROM information_schema.triggers;

Примечание.

Текст для триггера можно найти с помощью команды \df+ в psql.

Создание экземпляра Azure Database Migration Service

Теперь на портале Azure можно создать экземпляр Azure Database Migration Service.

Перед созданием экземпляра Azure Database Migration Service необходимо зарегистрировать поставщик ресурсов Microsoft.DataMigration в подписке. Это можно сделать следующим образом:

  1. На портале Azure в меню слева выберите пункт Все службы.
  2. На странице Все службы выберите Подписки.
  3. На странице Подписки выберите свою подписку.
  4. На странице подписки в разделе Параметры выберите Поставщики ресурсов.
  5. В поле Фильтровать по имени введите DataMigration, а затем выберите Microsoft.DataMigration.
  6. Щелкните Зарегистрировать и дождитесь изменения значения в поле Состояние на Зарегистрировано. Чтобы узнать, обновилось ли состояние, может потребоваться нажать кнопку Обновить.
    Image showing the Resource providers page. The user is registering the Microsoft.DataMigration resource provider

После завершения регистрации поставщика ресурсов можно создать службу. Выберите команду Создать ресурс в левой строке меню и выполните поиск Azure Database Migration Service.

Image showing the initial page when creating the Azure Database Migration Service

На странице Создание Migration Service введите имя своего экземпляра службы, укажите подписку (это должна быть та же подписка,в которой зарегистрирован поставщик ресурсов), группу ресурсов и расположение. Кроме того, необходимо указать виртуальную сеть, так как Database Migration Service зависит от брандмауэра, созданного для этой виртуальной сети и предназначенного для обеспечения необходимой защиты. Если вы выполняете миграцию баз данных из виртуальных машин Azure, вы сможете разместить Database Migration Service в той же виртуальной сети, которую используют эти виртуальные машины. Ценовая категория определяет количество ядер виртуальных процессоров, доступных для службы. Чтобы выполнить миграцию по сети, необходимо выбрать ценовую категорию Премиум. Категория Стандартный поддерживает только автономную миграцию.

Image showing the configuration for the Azure Database Migration Service. The user has selected the Premium pricing tier

Прежде чем продолжить, дождитесь завершения развертывания службы. Это займет несколько минут.

Создание проекта миграции с помощью Azure Database Migration Service

Теперь экземпляр Database Migration Service можно использовать для выполнения миграции по сети. Для этого необходимо создать новый проект миграции базы данных. Перейдите на страницу экземпляра службы миграции и выберите Новый проект миграции.

Image showing the newly created Azure Database Migration Service.

На странице Новый проект миграции задайте параметру "Тип исходного сервера" значение PostgreSQL, задайте параметру "Тип целевого сервера" значение База данных Azure для PostgreSQL и в качестве типа действия выберите Миграция данных по сети. На странице Тип действия перечислены действия, которые необходимо выполнить на исходном сервере, чтобы включить миграцию по сети. В нижней части страницы Новый проект миграции описывается процесс переноса схемы в целевой объект.

Image showing the migration project properties and instructions.

Обязательно выполните эти действия, а затем нажмите кнопку Создать и запустить действие.

Создание и запуск действия миграции

Новый проект миграции запускает мастер с пошаговой инструкцией. Укажите следующие данные:

  • На странице Добавление сведений об источнике укажите адрес исходного сервера, исходную базу данных и учетную запись, которая может подключаться к этой базе данных и получать данные. Для выполнения миграции учетная запись должна иметь привилегии суперпользователя.
  • На странице Сведения о целевом объекте укажите адрес Базы данных Azure для PostgreSQL, базу данных, в которую необходимо перенести данные, и сведения об учетной записи с правами администратора.
  • На странице Сопоставление с целевыми базами данных выберите исходную и целевую базы данных. Можно перенести одну базу данных или несколько.
  • На странице Параметры миграции укажите дополнительные параметры, которые необходимо настроить, например максимальное число таблиц для параллельной загрузки.
  • На странице Сводка по миграции введите имя действия, а затем выберите Запустить миграцию.
    Image showing the migration summary page.

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

Image showing the activity status page for the migration activity. The migration has transferred all the current data, and is ready to cutover to the new database.

Возобновление использования внешних ключей и триггеров

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

Прямая миграция на новую базу данных

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

Image showing the statistics for the migration activity.

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

Image of the Complete cutover page.

Выполнение автономной миграции

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

Существует как минимум два варианта автономной миграции в Базу данных Azure для PostgreSQL или на сервер PostgreSQL, работающий, к примеру, на виртуальной машине Azure.

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

Примечание.

Сейчас служба Azure Database Migration Service не поддерживает выполнение автономной миграции Базы данных PostgreSQL.

Миграция с помощью экспорта и импорта

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

  1. Экспортируйте схему, выполнив команду pg_dump в командной строке Bash:

    pg_dump -o -h [source database server] -U [user name] -d [database] -s > db_schema.sql

  2. Экспортируйте данные в другой файл с помощью команды pg_dump:

    pg_dump -o -h [source database server] -U [user name] -d [database] -a > db_data.sql

    На этом этапе db_schema.sql и db_data.sql представляют собой скрипты SQL, которые можно изменить с помощью текстового редактора.

  3. Создайте целевую базу данных в Базе данных Azure для PostgreSQL. Это можно сделать с помощью интерфейса командной строки Azure:

    az postgres db create \
    --name [database name] \
    --server-name [server name] \
    --resource-group [azure resource group]

  4. Импортируйте схему в целевую базу данных с помощью команды psql:

    psql -d [target database name] -h [server name in Azure Database for PostgreSQL] -U [user name] -f db_schema.sql

  5. Импортируйте данные в целевую базу данных с помощью команды psql:

    psql -d [target database name] -h [server name in Azure Database for PostgreSQL] -U [user name] -f db_data.sql

Миграция с помощью резервного копирования и восстановления

Далее приводятся действия по миграции базы данных с помощью резервного копирования и восстановления.

  1. Создайте резервную копию базы данных: в командной строке Bash выполните следующую команду. Укажите имя пользователя, имеющего необходимые права для создания резервной копии базы данных:

    pg_dump [database name] -h [source database server] -U [user name] -Fc > database_backup.bak

  2. Создайте целевую базу данных в Базе данных Azure для PostgreSQL.

    az postgres db create \
    --name [database name] \
    --server-name [server name] \
    --resource-group [azure resource group] \

  3. Восстановите резервную копию в новую базу данных, выполнив команду pg_restore из командной строки Bash. Укажите имя пользователя с правами администратора в Базе данных Azure для PostgreSQL:

    pg_restore -d [target database name] -h [server name in Azure Database for PostgreSQL] -Fc -U [user name] database_backup.bak