Миграция офлайн из Amazon RDS для PostgreSQL в Базу данных Azure для PostgreSQL с помощью службы миграции

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

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

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

Предпосылки

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

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

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

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

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

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

Конфигурация целевой установки

Перед началом миграции необходимо настроить базу данных Azure для PostgreSQL в Azure.

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

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

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

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

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

Дополнительные рекомендации по работе с сетями

Чтобы упростить подключение между исходными и целевыми экземплярами PostgreSQL, важно убедиться, что сеть настроена правильно, чтобы разрешить подключение между исходными и целевыми серверами. Если исходный сервер — это служба PaaS, например Amazon RDS для PostgreSQL или Google Cloud SQL для Postgres, в них могут потребоваться настройка некоторых правил брандмауэра и управляемых параметров сети. Если исходный сервер является самостоятельно размещенным сервером, может потребоваться внести изменения в файл pg_hba.conf этого сервера. Этот файл включает проверку подлинности клиента и должен быть настроен, чтобы разрешить целевому PostgreSQL подключаться к источнику. Для изменения файла pg_hba.conf обычно требуется перезапуск исходного экземпляра PostgreSQL.

Файл pg_hba.conf находится в каталоге данных установки PostgreSQL. Этот файл следует проверить и настроить, если исходная база данных является локальным сервером PostgreSQL или сервером PostgreSQL, размещенным на виртуальной машине Azure.

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

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

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

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

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

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

• Сопоставлять значения параметров сервера из исходной базы данных 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 без проблем, связанных с ограничениями суперпользователя.

Отключите высокую доступность (надежность) и реплики чтения в целевой системе

• Отключение высокого уровня доступности (надежности) и чтение реплик в целевой среде является важным. Эти функции должны быть включены только после завершения миграции.

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

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

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

Портал

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

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

Служба миграции доступна на портале Azure и предоставляет простой процесс с использованием мастера.

Использование портала Azure:

1. Выберите ваш гибкий сервер Azure Database for PostgreSQL.

2. В меню ресурсов выберите "Миграция".

   

3. Выберите "Создать", чтобы воспользоваться мастером с несколькими вкладками для осуществления миграции на гибкий сервер из Amazon RDS для PostgreSQL.

   Замечание

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

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

   

Настройка

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

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

• Тип исходного сервера — в зависимости от источника PostgreSQL можно выбрать Amazon RDS для PostgreSQL.

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

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

Выбор параметра проверки или проверки и миграции всегда является хорошей практикой для предмиграционной проверки перед выполнением миграции.

Чтобы узнать больше о проверке premigration, посетите этот ресурс.

• Режим миграции позволяет выбрать режим миграции. Оффлайн — это параметр по умолчанию. В этом случае мы будем использовать значение по умолчанию.

Нажмите кнопку "Далее" — сервер среды выполнения.

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

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

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

Исходный сервер

На вкладке "Исходный сервер" появится запрос на предоставление сведений, связанных с источником, выбранным на вкладке "Настройка ", которая является источником баз данных.

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

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

Целевой сервер

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

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

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

Базы данных для проверки или миграции

На вкладке "Базы данных" для проверки или миграции можно выбрать список пользовательских баз данных для миграции с исходного сервера PostgreSQL.

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

Сводка

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

Отмена проверки или миграции

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

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

CLI

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

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

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

az login

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

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

• Измените приведенные ниже заполнители << >> в строках JSON и сохраните их на локальной машине, где вызывается <<filename>>.json CLI. В этом руководстве мы сохранили файл в c:/migration-CLI/migration_body.json

{
"properties": {
"SourceDBServerResourceId": "<<source-server-hostname-or-IP-address>>:<<port>>@<<username>>",
        "SecretParameters": {
            "AdminCredentials": {
                "SourceServerPassword": "<<source-server-administrator-password>>",
                "TargetServerPassword": "<<target-server-administrator-password>>"
            },
            "targetServerUserName": "<<target-server-administrator-login>>"
        },
        "DBsToMigrate": "<<comma-separated-list-of-databases-in-array-like-["ticketdb","timedb","inventorydb"]>>",
        "OverwriteDBsInTarget": "true",
        "sourceType": "AWS_RDS",
        "sslMode": "Prefer"
    }
}

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

  az postgres flexible-server migration list --subscription <subscription_id> --resource-group <resource_group> --name <target_server> --filter all
  

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

  az postgres flexible-server migration create --subscription <subscription_id> --resource-group <resource_group> --name <target_server> --migration-name <migration> --migration-mode offline --migration-option ValidateAndMigrate --properties "c:/migration-cli/migration_body.json"
  

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

  az postgres flexible-server migration show --subscription <subscription_id> --resource-group <resource_group> --name <target_server> --migration-name <migration>
  

• Ход выполнения и состояние миграции отображается в Azure CLI.

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

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

  az postgres flexible-server migration update cancel --subscription <subscription_id> --resource-group <resource_group> --name <target_server> --migration-name <migration>
  

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

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

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

Сведения о миграции

Выберите имя миграции в сетке, чтобы просмотреть связанные сведения.

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

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

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

Сведения о проверке доступны на уровне экземпляра и базы данных.

• Сведения о проверке экземпляра
  • Содержит проверки, связанные с проверкой подключения, версией источника, т. е. версией PostgreSQL >= 9.5, и проверкой параметров сервера: включены ли расширения в параметрах сервера гибкого сервера Azure Database для PostgreSQL.
• Сведения о проверке и миграции баз данных
  • В нем выполняется проверка отдельных баз данных, связанных с расширениями и колляциями, в гибком сервере Azure Database для PostgreSQL.

Состояние проверки и состояние миграции можно просмотреть на странице сведений о миграции.

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

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

Состояние	Description
В работе	Выполняется настройка инфраструктуры миграции или выполняется фактическая миграция данных.
Отменено	Миграция отменена или удалена.
Неудачно	Миграция не удалась.
Сбой проверки	Проверка не удалась.
Успешно	Миграция прошла успешно и завершена.

Подстатики миграции

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

Подстатусы валидности

Подсостояние	Description
Неудачно	Ошибка проверки.
Успешно	Проверка выполнена успешно.
Предупреждение	Проверка отображается в предупреждении.

Проверьте миграцию после завершения

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

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

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

• После проверки включите параметр высокой доступности на гибком сервере по мере необходимости.

• Измените номер SKU гибкого сервера в соответствии с потребностями приложения. Для этого изменения требуется перезапуск сервера базы данных.

• При изменении параметров сервера из значений по умолчанию в исходном экземпляре скопируйте эти значения параметров сервера на гибком сервере.

• Скопируйте другие параметры сервера, такие как теги, оповещения и правила брандмауэра (если применимо), из исходного экземпляра на гибкий сервер.

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

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

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

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