Руководство по миграции из Amazon RDS для PostgreSQL в базу данных Azure для PostgreSQL с использованием предварительной версии службы миграции.

В этой статье описывается, как перенести базу данных PostgreSQL из Amazon RDS для PostgreSQL в База данных Azure для PostgreSQL в Интернете.

Служба миграции в База данных Azure для PostgreSQL — это полностью управляемая служба, интегрированная в портал Azure и Azure CLI. Он предназначен для упрощения перехода на сервер База данных Azure для PostgreSQL.

• Предварительные условия
• Выполните миграцию
• Отслеживайте ход миграции.
• Cutover
• Проверьте миграцию после завершения

Предварительные условия

Чтобы завершить миграцию, вам потребуется следующее:

Перед началом миграции с помощью службы миграции База данных Azure для PostgreSQL важно выполнить следующие предварительные требования, специально предназначенные для сценариев миграции через Интернет.

• Проверка исходной версии
• Установка test_decoding — исходная настройка
• Configure target setup
• Включение CDC в качестве источника
• Настройка настройки сети
• Включение расширений
• Проверка параметров сервера
• Проверка пользователей и ролей

Проверка исходной версии

Исходная версия сервера PostgreSQL должна быть 9.5 или более поздней.

Если исходная версия PostgreSQL меньше 9.5, перед началом миграции обновите ее до версии 9.5 или более поздней.

Установка test_decoding — настройка источника

• test_decoding получает WAL через логический механизм декодирования и декодирует его в текстовые представления выполненных операций.
• In Amazon RDS for PostgreSQL, the test_decoding plugin is preinstalled and ready for logical replication. Это позволяет легко настраивать слоты логической репликации и выполнять потоковую передачу изменений WAL, облегчая использование таких вариантов, как запись измененных данных (CDC) или репликация во внешние системы.
• Дополнительные сведения о подключаемом модуле для декодирования тестов см. в документации по PostgreSQL.

Configure target setup

• Перед миграцией необходимо создать сервер базы данных Azure для PostgreSQL — гибкий.
• SKU provisioned for Azure Database for PostgreSQL – Flexible server should match with the source.
• Чтобы создать новую базу данных Azure для PostgreSQL, посетите гибкий сервер базы данных Azure для PostgreSQL.

Включение CDC в качестве источника

• test_decoding Плагин логического декодирования фиксирует изменённые данные из источника.
• Чтобы разрешить пользователю миграции доступ к привилегиям репликации, выполните следующую команду:

GRANT rds_replication TO <<username>>;

• В исходном экземпляре PostgreSQL измените следующие параметры, создав новую группу параметров:

  • Задайте значение rds.logical_replication = 1.
  • Задайте max_replication_slots значение больше одного; значение должно быть больше числа баз данных, выбранных для миграции.
  • Set max_wal_senders to a value greater than one. It should be at least the same as max_replication_slots, plus the number of senders already used on your instance.
  • Параметр wal_sender_timeout завершает неактивные подключения репликации, которые продолжаются дольше, чем указанное число миллисекунд. Значение по умолчанию для экземпляра AWS RDS для PostgreSQL — это 30000 milliseconds (30 seconds). Установка значения 0 (ноль) отключает механизм времени ожидания и является допустимым параметром для миграции.

• На целевом гибком сервере, чтобы предотвратить нехватку места для хранения журналов в процессе онлайн миграции, убедитесь, что у вас достаточно пространства табличного пространства, используя предварительно настроенный управляемый диск. Чтобы добиться этого, отключите параметр azure.enable_temp_tablespaces_on_local_ssd сервера в течение срока миграции и восстановите его в исходном состоянии после миграции.

Настройка настройки сети

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

Для получения информации о настройке сети посетите Руководство по сети для службы миграции.

Включение расширений

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

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

Дополнительные сведения см. в разделе "Расширения" в База данных Azure для PostgreSQL.

Примечание

При внесении изменений в shared_preload_libraries параметр требуется перезапуск.

Проверка параметров сервера

Эти параметры не переносятся автоматически в целевую среду и должны быть настроены вручную.

• Сопоставьте значения параметров сервера из исходной базы данных PostgreSQL с базой данных Azure для PostgreSQL, войдя в раздел "Параметры сервера" в портале Azure и вручную обновите значения соответственно.

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

Проверка пользователей и ролей

При миграции в База данных Azure для PostgreSQL важно решить проблему миграции пользователей и ролей отдельно, так как им требуется ручное вмешательство:

• Миграция пользователей и ролей вручную. Пользователи и связанные с ними роли должны быть перенесены вручную в База данных Azure для PostgreSQL. Чтобы упростить этот процесс, можно использовать pg_dumpall служебную программу с флагом --globals-only для экспорта глобальных объектов, таких как роли и учетные записи пользователей. Выполните следующую команду, заменив <<username>> фактическое имя пользователя и <<filename>> требуемое имя выходного файла:

  pg_dumpall --globals-only -U <<username>> -f <<filename>>.sql
  

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

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

Disable high availability (reliability) and read replicas in the target

• Disabling high availability (reliability) and reading replicas in the target environment is essential. Эти функции должны быть включены только после завершения миграции.

• By following these guidelines, you can help ensure a smooth migration process without the added variables introduced by HA and Read Replicas. После завершения миграции и стабильной базы данных вы можете включить эти функции для повышения доступности и масштабируемости среды базы данных в Azure.

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

Вы можете перенести данные, используя портал Azure или Azure CLI.

Портал

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

Чтобы выполнить миграцию с помощью портал Azure, сначала настройте задачу миграции, подключитесь к источнику и целевому объекту, а затем выполните миграцию.

Настройка задачи миграции

The migration service comes with a simple, wizard-based experience on the Azure portal. Вот как начать работу:

1. Откройте веб-браузер и перейдите на портал. Введите свои учетные данные для входа. Панель мониторинга службы является представлением по умолчанию.

2. Go to your Azure Database for PostgreSQL Flexible Server target.

3. На вкладке "Обзор гибкого сервера" в меню слева прокрутите страницу вниз до раздела "Миграция" и выберите его.

   

4. Нажмите кнопку "Создать ", чтобы перейти с Amazon RDS для PostgreSQL на гибкий сервер Базы данных Azure для PostgreSQL. Если вы впервые используете службу миграции, пустая сетка появится с запросом на начало первой миграции.

   

   If you've already created migrations to your Azure Database for PostgreSQL target, the grid contains information about attempted migrations.

5. Выберите кнопку Создать. Then, you go through a wizard-based series of tabs to create a migration into this Azure Database for PostgreSQL target from the PostgreSQL source instance.

Настройка

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

• Имя миграции — это уникальный идентификатор для каждой операции миграции в этот целевой объект в рамках Гибкого сервера. Это поле принимает только буквенно-цифровые символы и не принимает специальные символы, кроме дефиса (-). Имя не может начинаться с дефиса и должно быть уникальным для целевого сервера. Две операции миграции в один и тот же целевой объект в рамках Гибкого сервера не могут иметь одинаковые имена.

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

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

  • Проверка. Проверяет готовность сервера и базы данных к миграции в целевой объект.
  • Миграция — пропускает проверки и запускает миграцию.
  • Проверка и миграция— выполняет проверку перед активацией миграции. Миграция активируется только в том случае, если нет сбоев проверки.

Выбор параметра Проверить или Проверить и Мигрировать всегда является хорошей практикой при выполнении проверок предварительной миграции перед началом миграции. To learn more about the premigration validation, refer to this documentation.

• Режим миграции позволяет выбрать режим миграции. Offline is the default option.

Нажмите кнопку «Далее: Подключение к источнику».

Выбор сервера среды выполнения

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

For more information about the Runtime Server, visit the Migration Runtime Server.

Подключение к источнику

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

• Имя сервера— укажите имя узла или IP-адрес исходного экземпляра PostgreSQL.
• Порт — номер порта исходного сервера
• Имя входа администратора сервера — имя пользователя исходного сервера PostgreSQL
• Пароль — пароль исходного сервера PostgreSQL
• Режим SSL— поддерживаемые значения предпочтительнее и обязательны. Если SSL на сервере Source PostgreSQL имеет значение OFF, используйте SSLMODE=prefer. Если SSL на исходном сервере имеет значение ON, используйте SSLMODE=require. Значения SSL можно определить в файле Postgresql.conf.
• Проверка подключения— выполняет тест подключения между целевым объектом и источником. После успешного подключения пользователи смогут продолжить следующий шаг. В противном случае необходимо определить сетевые проблемы между целевым объектом и источником и проверить имя пользователя или пароль для источника. Установка тестового подключения занимает несколько минут.

После успешного тестового подключения нажмите кнопку "Далее: выбрать целевой объект миграции"

Выбор целевого объекта миграции

На вкладке "Выбор целевого объекта миграции" отображаются метаданные для целевого объекта гибкого сервера, например имя подписки, группа ресурсов, имя сервера, расположение и версия PostgreSQL.

• Имя администратора — имя администратора целевого сервера PostgreSQL
• Пароль — пароль целевого сервера PostgreSQL
• Настраиваемое полное доменное имя или IP-адрес (необязательно): настраиваемое полное доменное имя/IP-адрес является необязательным и может использоваться, если целевой объект находится за пользовательским DNS-сервером или имеет пользовательские пространства имен DNS, что делает его доступным только через определенные полные доменные имена или IP-адреса. Например, это может включать такие записи, как flexibleserver.example.com, 198.1.0.2, или полное доменное имя PostgreSQL, например flexibleserver.postgres.database.azure.com, если пользовательский DNS-сервер содержит зону DNS postgres.database.azure.com или перенаправляет запросы для этой зоны к 168.63.129.16, где полное доменное имя разрешается в общедоступной или частной зоне DNS Azure.
• Проверка подключения — выполняет тест подключения между целевым объектом и источником. После успешного подключения пользователи смогут продолжить следующий шаг. В противном случае необходимо определить сетевые проблемы между целевым объектом и источником и проверить имя пользователя или пароль для целевого объекта. Проверка подключения занимает несколько минут, чтобы установить соединение между целевым объектом и источником.

После успешного тестового подключения нажмите кнопку Next: Select Database(s) for Migration (Выбор баз данных) для миграции

Выбор баз данных для миграции

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

После выбора баз данных нажмите кнопку "Далее: Сводка"

Итоги

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

Отслеживайте ход миграции.

После нажатия кнопки "Пуск" появится уведомление через несколько секунд, указывающее, что проверка или создание миграции успешно выполнено. Затем вы будете автоматически перенаправлены на страницу Migration Flexible Server, где содержится новая запись для недавно созданной проверки или миграции.

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

When the validation or migration is created, it moves to the InProgress state and PerformingPreRequisiteSteps substrate. Рабочий процесс занимает 2–3 минуты, чтобы настроить инфраструктуру миграции и сетевые подключения.

Сведения о переносе

На вкладке "Настройка" выбран параметр миграции в качестве "Миграция" и "Проверка". В этом сценарии проверки выполняются сначала перед началом миграции. После завершения подстатуса PerformingPreRequisiteSteps рабочий процесс переходит в подстатус Проверка в процессе.

• Если проверка имеет ошибки, миграция переходит в состояние сбоя .
• Если проверка завершается без ошибок, начинается миграция и рабочий процесс переходит в подстаток миграции данных.

Результаты проверки и миграции можно просмотреть на уровне экземпляра и базы данных.

Некоторые возможные состояния миграции:

Состояния миграции

Государство	Описание
InProgress	Выполняется настройка инфраструктуры миграции или выполняется фактическая миграция данных.
Отменено	The migration is canceled or deleted.
Неудачно	The migration has failed.
Сбой проверки	Проверка не удалась.
Успешно	Миграция прошла успешно и завершена.
WaitingForUserAction	Применимо только для миграции через Интернет. Waiting for user action to perform cutover.

Migration substates

Substate	Описание
Выполнение предварительных шагов	Настройка инфраструктуры выполняется для миграции данных.
Проверка в процессе выполнения	Проверка выполняется.
Перемещающиеся данные	Выполняется миграция данных.
Завершение миграции	Миграция находится на заключительных этапах завершения.
Завершено	Миграция завершена.
Неудачно	Migration has failed.

Validation substates

Substate	Описание
Неудачно	Validation has failed.
Успешно	Проверка выполнена успешно.
Предупреждения	Validation is in warning.

Cutover

If there are both Migrate and Validate and Migrate, completing the Online migration requires another step—the user must take a Cutover action. После завершения копирования и клонирования базовых данных миграция переходит в состояние WaitingForUserAction и подстояние WaitingForCutoverTrigger. In this state, the user can trigger the cutover from the portal by selecting the migration.

Прежде чем инициировать переключение, важно убедиться в том, что:

• Записи в источник остановлены — Latency значение равно 0 или близко к 0. Сведения Latency можно получить на экране сведений о миграции, как показано ниже:

• latency Значение уменьшается до 0 или близко к 0

• Значение latency указывает, когда целевой объект последний раз синхронизирован с источником. At this point, writing to the Source can be stopped, and cutover can be initiated. В случае, если в источнике большой трафик, рекомендуется сначала остановить записи, чтобы Latency приблизилось к 0, а затем начать перенос. The Cutover operation applies all pending changes from the Source to the Target and completes the migration. If you trigger a "Cutover" even with nonzero Latency, the replication stops until that point in time. All the data is on the Source until the cutover point is applied to the target. Предположим, что задержка составила 15 минут в точке переключение, поэтому все измененные данные за последние 15 минут применяются к целевому объекту. Время зависит от накопленных изменений, происходящих за последние 15 минут. Поэтому рекомендуется, чтобы задержка была до нуля или почти нуля, прежде чем начать переключение.

  

• The migration moves to the Succeeded state when the Migrating Data substate or the cutover (in Online migration) finishes successfully. If there's a problem at the Migrating Data substate, the migration moves into a Failed state.

  

CLI

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

Дополнительные сведения об использовании Azure CLI в службе миграции см. в статье "Настройка Azure CLI для службы миграции".

После установки командной строки (CLI) откройте терминал и войдите в учетную запись Azure с помощью следующей команды.

az login

Настройка задачи миграции

Чтобы начать миграцию, необходимо создать JSON-файл с подробными сведениями о миграции. JSON-файл содержит следующие сведения:

• Edit the below placeholders << >> in the JSON lines and store them in the local machine as <<filename>>.json where the CLI is being invoked. В этом руководстве мы сохранили файл в C:\migration-CLI\migration_body.json

{
    "properties": {
        "SourceDBServerResourceId": "<<source hostname or IP address>>:<<port>>@<<username>>",
        "SecretParameters": {
            "AdminCredentials": {
                "SourceServerPassword": "<<Source Password>>",
                "TargetServerPassword": "<<Target Password>>"
            },
            "targetServerUserName": "<<Target username>>"
        },
        "DBsToMigrate": "<<comma separated list of databases in a array like - ["ticketdb","timedb","inventorydb"]>>",
        "OverwriteDBsInTarget": "true",
        "sourceType": "AWS_RDS",
        "sslMode": "Require"
    }
}

• Выполните следующую команду, чтобы проверить, выполняются ли миграции. The migration name is unique across the migrations within the Azure Database for PostgreSQL flexible server target.

  az postgres flexible-server migration list --subscription 11111111-1111-1111-1111-111111111111 --resource-group my-learning-rg --name myflexibleserver --filter All
  

• В приведенных выше шагах нет операций миграции, поэтому мы начнем с новой миграции, выполнив следующую команду.

  az postgres flexible-server migration create --subscription 11111111-1111-1111-1111-111111111111 --resource-group my-learning-rg --name myflexibleserver --migration-name migration1 --migration-mode online --migration-option ValidateAndMigrate --properties "C:\migration-cli\migration_body.json"
  

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

  az postgres flexible-server migration show --subscription 11111111-1111-1111-1111-111111111111 --resource-group my-learning-rg --name myflexibleserver --migration-name migration1
  

• Состояние хода миграции отображается в Azure CLI.

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

• Вы можете отменить любые текущие попытки миграции с помощью cancel команды. Эта команда останавливает конкретную попытку миграции и откатывает все изменения на целевом сервере. Вот команда CLI для удаления миграции:

  az postgres flexible-server migration update cancel --subscription 11111111-1111-1111-1111-111111111111 --resource-group my-learning-rg --name myflexibleserver --migration-name migration1
  

Cutover

• After the base data migration is complete in online migrations, the migration task moves to the WaitingForCutoverTrigger substate. В этом состоянии пользователь может активировать переход через командную строку с помощью следующей команды. The cutover can also be triggered from the portal by selecting the migration name in the migration grid.

• Вы также можете инициировать переход из портала Azure.

  az postgres flexible-server migration update --subscription 11111111-1111-1111-1111-111111111111 --resource-group my-learning-rg --name myflexibleserver --migration-name migration1 --cutover
  

Проверьте миграцию, когда она завершится

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

После миграции можно выполнить следующие задачи:

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

Связанный контент

• Перенос данных из Amazon RDS для PostgreSQL в автономном режиме
• Служба миграции
• Известные проблемы и ограничения