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

   Примечание.

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

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

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

   

Настройка

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Подключитесь к целевому

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

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

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

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

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

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

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

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

Итоги

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

CLI

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

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

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

• Установите Azure CLI в зависимости от операционной системы для выполнения команд CLI.
• Azure CLI можно установить из статьи " Как установить Azure CLI".
• Если Azure CLI уже установлен, проверка версию, выполнив команду az version. Для использования службы миграции версия должна быть не менее 2.56.0 или более поздней.
• После установки запустите команду az sign in. Откроется браузер по умолчанию и загружается страница входа Azure для проверки подлинности. Передайте учетные данные Azure, чтобы выполнить успешную проверку подлинности. Чтобы подписаться с помощью Azure CLI, перейдите по этой ссылке.

Настройка команд CLI для службы миграции

Все команды CLI начинаются с az postgres flexible-server migration. Существуют также инструкции справки, которые помогут вам понять различные параметры и создать правильный синтаксис для команд CLI.

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

Пример с командной строкой Windows: az login

Команды для использования со службой миграции

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

Команда справки

az postgres flexible-server migration –-help Команда предоставляет имя и соответствующие команды.

Команда create

Команда создания помогает перенести исходный сервер на целевой сервер.

Команда справки позволяет пользователям понять различные аргументы, используемые для создания и инициирования миграции az postgres flexible-server migration create --help.

az postgres flexible-server migration create --subscription 11111111-1111-1111-1111-111111111111 --resource-group my-learning-rg --name myflexibleserver --migration-name migration1 --migration-option ValidateAndMigrate --properties "C:\Users\Administrator\Documents\migrationBody.JSON" --migration-mode offline

При активации команды создания разные подстатки.

• Миграция перемещается в состояние InProgress и подстатное состояние PerformingPrequisiteSteps.

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

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

• Время завершения субстата миграции данных зависит от размера перенесенных баз данных.

• Миграция переходит в состояние "Успешно выполнено" после успешного завершения подстановки "Перенос данных". Если в подстатке миграции данных возникла проблема, миграция переходит в состояние сбоя.

Давайте рассмотрим сведения о каждом параметре, используемом в команде create.

имени параметра	Description
subscription	Идентификатор подписки гибкого сервера PostgreSQL
resource-group	Группа ресурсов гибкого сервера PostgreSQL
name	Имя гибкого сервера PostgreSQL
migration-name	Уникальный идентификатор попытки миграции в Гибкий сервер. Это поле принимает только буквенно-цифровые символы и не принимает специальные символы, кроме дефиса (-). Имя не может начинаться с -, и нет двух миграций в гибкий целевой объект сервера может иметь то же имя.
migration-mode	Этот параметр является необязательным. Значение по умолчанию: автономное. Автономная миграция включает копирование исходных баз данных в определенный момент времени на целевой сервер.
migration-option	Позволяет выполнять проверки перед активацией миграции. Значение по умолчанию — ValidateAndMigrate. Допустимые значения: "Миграция", "Проверка", "ValidateAndMigrate".
properties	Абсолютный путь к JSON-файлу с информацией о исходном сервере

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

JSON-файл содержит следующие сведения:

Имя свойства	Description
sourceDbServerResourceId	Сведения о исходном сервере в формате локальных виртуальных машин Azure (виртуальных машин), AWS — <<hostname or IP address>>:<<port>>@<<username>>
AdminCredentials	Этот параметр содержит пароли для пользователей администратора для исходного сервера и целевого гибкого сервера PostgreSQL. Эти пароли помогают выполнять проверку подлинности на исходных и целевых серверах.
targetServerUserName	Значением по умолчанию является пользователь администратора, созданный во время создания гибкого сервера, а пароль, предоставленный для проверки подлинности для этого пользователя. Если вы не используете пользователя по умолчанию, этот параметр является пользователем или ролью на целевом сервере для миграции. Этот пользователь должен быть членом azure_pg_admin, pg_read_all_settings, pg_read_all_stats и pg_stat_scan_tables ролей и должен иметь роль "Создать", "Создать атрибуты базы данных"
dbsToMigrate	Укажите список баз данных, которые требуется перенести в Гибкий сервер. Одновременно можно включить не более восьми имен баз данных. Предоставление списка DOB-объектов в формате массива.
OverwriteDBsInTarget	Если задано значение true (по умолчанию), если целевой сервер имеет существующую базу данных с тем же именем, что и при попытке перенести, средство миграции автоматически перезаписывает базу данных.
MigrationMode	Режим миграции. Поддерживаемое значение — "Автономный"
sourceType	Обязательный параметр. Значения могут быть: OnPremises, AWS, AzureVM, PostgreSQLSingleServer
sslMode	Режимы SSL для миграции. Режим SSL для PostgreSQLSingleServer — VerifyFull и Prefer/Require для других типов источников

Команда списка

Команда списка перечисляет все попытки миграции, сделанные в целевой объект База данных Azure для PostgreSQL.

az postgres flexible-server migration list [--subscription] [--resource-group][--name] [--filter]

имени параметра	Description
subscription	Идентификатор подписки для гибкого сервера PostgreSQL
resource-group	Группа ресурсов гибкого сервера PostgreSQL
name	Имя гибкого сервера PostgreSQL
filter	Для фильтрации миграций поддерживаются два значения: "Активный" и "Все"

Команда show

Команда show помогает отслеживать текущие миграции и предоставляет текущее состояние и подсостояние миграции. К этим сведениям относится информация о текущем состоянии и подсостоянии миграции.

az postgres flexible-server migration show [--subscription][--resource-group][--name][--migration-name]

имени параметра	Description
subscription	Идентификатор подписки для гибкого сервера PostgreSQL
resource-group	Группа ресурсов гибкого сервера PostgreSQL
name	Имя гибкого сервера PostgreSQL
migration-name	Уникальный идентификатор попытки миграции в Гибкий сервер. Это поле принимает только буквенно-цифровые символы и не принимает специальные символы, кроме дефиса (-). Имя не может начинаться с -, и нет двух миграций в гибкий целевой объект сервера может иметь то же имя.

Различные состояния, поддерживаемые в команде show

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

Различные вложенные состояния, поддерживаемые в команде show для миграции

SubState миграции	Description
PerformingPreRequisiteSteps	Инфраструктура настроена и предварительно настроена для миграции данных
MigratingData	Миграция данных выполняется
Completed	Миграция завершена
Failed	Сбой миграции
Validation in Progress	Проверка выполняется
CompletingMigration	Миграция находится на заключительных этапах завершения

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

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

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

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

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

Различные вложенные состояния, поддерживаемые в команде show для проверки.

SubState проверки	Description
Failed	Сбой проверки
Succeeded	Проверка выполнена успешно
Warning	Проверка находится в предупреждении. Предупреждения — это информационные сообщения, которые необходимо учитывать при планировании миграции.

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

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

az postgres flexible-server migration update cancel [--subscription][--resource-group][--name][--migration-name]

Например:

az postgres flexible-server migration update cancel --subscription 11111111-1111-1111-1111-111111111111 --resource-group my-learning-rg --name myflexibleserver --migration-name migration1"

Чтобы получить дополнительные сведения об этой команде, воспользуйтесь параметром help:

az postgres flexible-server migration update cancel -- help

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

Мы собираемся перенести "ticketdb", "inventorydb", "salesdb" на гибкий сервер База данных Azure для PostgreSQL.

Выполнение миграции с помощью интерфейса командной строки

• Откройте командную строку и войдите в Azure с помощью az login команды

  

• Измените приведенные ниже заполнители в строках << >> 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 like - "ticketdb","timedb","salesdb">>"
          ],
          "OverwriteDBsInTarget": "true",
          "MigrationMode": "Offline",
          "sourceType": "AzureVM",
          "sslMode": "Prefer"
      }
  }
  

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

  az postgres flexible-server migration list --subscription <<subscription ID>> --resource-group <<resource group name>> --name <<Name of the Flexible Server>> --filter All
  

  

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

  az postgres flexible-server migration create --subscription <<subscription ID>> --resource-group <<resource group name>> --name <<Name of the Flexible Server>> --migration-name <<Unique Migration Name>> --migration-option ValidateAndMigrate --properties "C:\migration-cli\migration_body.json"
  

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

  az postgres flexible-server migration show --subscription <<subscription ID>> --resource-group <<resource group name>> --name <<Name of the Flexible Server>> --migration-name <<Migration ID>>
  

• Состояние хода выполнения миграции отображается в интерфейсе командной строки.

  

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

  

Отмена миграции с помощью ИНТЕРФЕЙСА командной строки

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

az postgres flexible-server migration update cancel [--subscription]
                                            [--resource-group]
                                            [--name]
                                            [--migration-name]

Например:

az postgres flexible-server migration update cancel --subscription 11111111-1111-1111-1111-111111111111 --resource-group my-learning-rg --name myflexibleserver --migration-name migration1"

Чтобы получить дополнительные сведения об этой команде, воспользуйтесь параметром help:

 az postgres flexible-server migration update cancel -- help

Команда предоставляет следующие выходные данные:

---

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

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

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

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

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

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

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

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

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

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

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

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