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

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

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

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

Необходимые компоненты

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

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

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

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

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

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

Настройка целевой установки

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

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

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

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

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

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

pg_hba.conf Configuration: чтобы упростить подключение между исходными и целевыми экземплярами PostgreSQL, необходимо проверить и потенциально изменить файл pg_hba.conf. Этот файл включает проверку подлинности клиента и должен быть настроен, чтобы разрешить целевому PostgreSQL подключаться к источнику. Для изменения файла pg_hba.conf обычно требуется перезапуск исходного экземпляра PostgreSQL.

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

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

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

Включите поддерживаемые расширения, определенные в исходном экземпляре PostgreSQL на целевом База данных Azure для 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 без возникновения проблем, связанных с ограничениями суперпользователя.

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

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

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

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

Вы можете перенести с помощью портал Azure или Azure CLI.

Портал

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

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

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

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

2. Перейдите к базе данных Azure для гибкого сервера PostgreSQL.

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

   

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

   Примечание.

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

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

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

   

Настройка

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

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

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

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

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

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

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

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

Нажмите кнопку "Далее: подключиться к источнику ".

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

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

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

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

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

• Имя сервера— укажите имя узла или IP-адрес исходного экземпляра PostgreSQL.

• Порт — номер порта исходного сервера

• Имя входа администратора сервера — имя пользователя исходного сервера PostgreSQL

• Пароль — пароль исходного сервера PostgreSQL

• Режим SSL. Поддерживаемые значения предпочтительны и обязательны. Если SSL на исходном сервере PostgreSQL имеет значение OFF, используйте SSLMODE=prefer. Если ssl на исходном сервере включен, используйте SSLMODE=require. Значения SSL можно определить в файле postgresql.conf.

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

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

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

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

• Имя администратора — имя администратора целевого сервера PostgreSQL

• Пароль — пароль целевого сервера PostgreSQL

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

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

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

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

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

Итоги

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Подсостояния миграции

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

Подстатки проверки

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

Отмена миграции с помощью портала

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

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

CLI

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

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

После установки ИНТЕРФЕЙСА командной строки откройте командную строку и войдите в учетную запись Azure с помощью следующей команды.

az login

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

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

• Измените приведенные ниже заполнители в строках << >> JSON и сохраните их на локальном компьютере, где <<filename>>.json вызывается CLI. В этом руководстве мы сохранили файл в 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": "OnPremises",
        "sslMode": "Prefer"
    }
}

Примечание.

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

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

  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 offline --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
  

Проверка миграции при завершении

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

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

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

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

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

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

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

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

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

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

• Служба миграции
• Миграция из AWS RDS
• Рекомендации
• Известные проблемы и ограничения
• Настройка сети
• Проверки предварительной подготовки