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

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

  • Статья

ОБЛАСТЬ ПРИМЕНЕНИЯ: База данных Azure для PostgreSQL — гибкий сервер

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

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

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

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

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

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

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

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

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

Установка test_decoding — исходная настройка

  • test_decoding получает WAL через логический механизм декодирования и декодирует его в текстовые представления выполненных операций.

  • Дополнительные сведения о подключаемом модуле для декодирования тестов см. в документации по PostgreSQL.

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

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

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

  • test_decoding Подключаемый модуль логического декодирования записывает измененные записи из источника.
  • В исходном экземпляре PostgreSQL задайте следующие параметры и значения в файле конфигурации postgresql.conf:
    • Set wal_level = logical
    • Set max_replication_slots значение больше 1, значение должно быть больше количества баз данных, выбранных для миграции.
    • Set max_wal_senders значение больше 1, должно иметь значение по крайней мере то же, что и max_replication_slots, а также число отправителей, уже используемых экземпляром.
    • Параметр wal_sender_timeout заканчивает подключения репликации, которые неактивны до указанного числа миллисекунда. По умолчанию для локальной базы данных PostgreSQL используется 60000 миллисекунд (60 секунд). Установка значения 0 (ноль) отключает механизм времени ожидания и является допустимым параметром для миграции.

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

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

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

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

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

Примечание.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  5. Выберите кнопку Создать. Затем перейдите к серии вкладок на основе мастера, чтобы создать миграцию в этот гибкий целевой сервер с исходного сервера PostgreSQL.

Настройка

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Снимок экрана: Connectsourcemigration.

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

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

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

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

Снимок экрана: Connecttargetmigration.

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

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

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

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

Снимок экрана: FetchDBmigration.

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

Итоги

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

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

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

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

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

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

При создании проверки или миграции он перемещается в состояние InProgress и подстатное значение PerformingPreRequisiteSteps . Рабочий процесс занимает от 2 до 3 минут, чтобы настроить инфраструктуру миграции и сетевые подключения.

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

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

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

Результаты проверки отображаются на вкладке "Проверка ", а миграция отслеживается на вкладке "Миграция ".

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

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

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

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

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

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

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

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

Прямая миграция

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

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

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

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

  • Миграция перемещается в Succeeded состояние, когда Migrating Data подстат или переключение (в режиме миграции через Интернет) успешно завершается. Если в подсостоянии возникла проблема Migrating Data, миграция переходит в состояние Failed.

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

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

Отмена проверки останавливает любое дальнейшее действие проверки, а проверка переходит в состояние "Отменено ".

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

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

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

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

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

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