Поделиться через


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

Область применения: гибкий сервер Базы данных Azure для PostgreSQL

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

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

  • Настройка гибкого сервера База данных Azure для PostgreSQL
  • Настройка задачи миграции
  • Отслеживайте ход миграции.
  • Отмена миграции
  • После миграции

Предварительные требования (в автономном режиме)

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

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

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

Целевая настройка

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

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

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

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

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

Требования к сети для миграции:

  • ExpressRoute/IPsec VPN/VPN-туннелирование. При подключении локального источника или AWS к Azure может потребоваться настроить expressRoute, IPsec VPN или VPN-туннелирование для упрощения безопасной передачи данных.

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

Сценарии подключения:

В следующей таблице можно настроить сеть между источником и целевым объектом.

Оригинал Target Советы по подключению
Общедоступный Общедоступный Никаких других действий не требуется, если источник включен в список разрешений в правилах брандмауэра целевого объекта.
Private Public Эта конфигурация не поддерживается; используйте pg_dump/pg_restore для передачи данных.
Общедоступные Личные Никаких других действий не требуется, если источник включен в список разрешений в правилах брандмауэра целевого объекта.
Private Private Установите пиринг expressRoute, IPsec VPN, VPN-туннелирование или пиринг между источником и целевым объектом.
Private Частная конечная точка Эта конфигурация не поддерживается; обратитесь в службу поддержки Майкрософт.

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

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

Примечание.

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

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

Расширения

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

  • Используйте команду select в источнике для перечисления всех используемых расширений. select extname,extversion from pg_extension;

  • Найдите параметр сервера azure.extensions на странице параметров сервера на База данных Azure для PostgreSQL. Включите расширения, найденные в источнике в PostgreSQL.

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

    Снимок экрана: расширения.

  • Проверьте, содержит ли список любой из следующих расширений:

    • PG_CRON
    • PG_HINT_PLAN
    • PG_PARTMAN_BGW
    • PG_PREWARM
    • PG_STAT_STATEMENTS
    • PG_AUDIT
    • PGLOGICAL
    • WAL2JSON

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

Пользователи и роли

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

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

    pg_dumpall --globals-only -U <<username>> -f <<filename>>.sql
    
  • Ограничение на роли суперпользователя: База данных Azure для PostgreSQL не поддерживает роли суперпользователя. Таким образом, перед миграцией пользователям с привилегиями суперпользователя должны быть удалены эти привилегии. Убедитесь, что разрешения и роли настроены соответствующим образом.

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

Параметры сервера

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

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

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

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

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

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

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

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

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

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

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

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

    Снимок экрана: выбор миграции.

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

    Примечание.

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

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

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

    Снимок экрана: страница создания миграции.

Настройка

Первая вкладка — это вкладка установки.

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

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

  • Тип исходного сервера— в зависимости от источника PostgreSQL можно выбрать AWS RDS для 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.
После выбора баз данных нажмите кнопку Next:Summary

Снимок экрана: страница миграции fetchDB.

Итоги

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

Снимок экрана: страница сводной миграции.

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

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

Снимок экрана: страница миграции монитора.

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

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

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

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

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

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

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

  • Проверка на уровне экземпляра

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

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

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

Снимок экрана: сведения о проверке и миграции.

Возможные состояния миграции включают:

  • InProgress: выполняется настройка инфраструктуры миграции или фактическая миграция данных.
  • Отменено: миграция отменена или удалена.
  • Failed — миграция завершилась с ошибкой.
  • Сбой проверки: проверка завершилась ошибкой.
  • Succeeded — миграция прошла успешно и завершена.
  • WaitForUserAction: применимо только для миграции через Интернет. Ожидание действия пользователя для выполнения переключение.

Возможные подсостояния миграции:

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

Возможные подстатки проверки включают:

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

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

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

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

После миграции

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

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

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

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

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

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

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

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

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