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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    Примечание.

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

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

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

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

Настройка

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • Имя сервера— укажите имя узла или IP-адрес исходного экземпляра PostgreSQL.
  • Порт — номер порта исходного сервера
  • Имя входа администратора сервера — имя пользователя исходного сервера PostgreSQL
  • Пароль — пароль исходного сервера PostgreSQL
  • Режим SSL. Поддерживаемые значения предпочтительны и обязательны. Если SSL на исходном сервере PostgreSQL имеет значение OFF, используйте SSLMODE=prefer. Если ssl на исходном сервере включен, используйте 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 (Выбор баз данных) для миграции

Снимок экрана: страница миграции целевого объекта подключения.

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

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

Скриншот страницы миграции fetchDB.

Итоги

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • Проверка на уровне базы данных

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

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

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

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

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

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

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

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

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

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

Отмена миграции

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

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

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

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

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

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

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