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

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

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

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

Портал

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

Автономный режим

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

   

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

   

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

5. Нажмите кнопку Перенести из Отдельного сервера. Чтобы создать миграцию на этот гибкий целевой сервер с любого исходного отдельного сервера, перейдите через ряд вкладок на основе мастера.

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

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

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

   

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

   

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

   

После развертывания гибкого сервера выполните действия 3–5 в разделе "Настройка задачи миграции".

Вкладка "Настройка"

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

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

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

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

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

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

Если выбрана предварительная версия миграции в Интернете, в исходном отдельном сервере должна быть включена логическая реплика. Если она не включена, служба миграции автоматически включает логическую реплика на исходном отдельном сервере. Репликация также может быть настроена вручную на вкладке "Репликация" на панели "Один сервер", задав уровень поддержки поддержки azure реплика tion логическому. Любой подход перезапускает исходный отдельный сервер.

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

Вкладка Источник

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

После выбора подписки и группы ресурсов в раскрывающемся списке имен серверов отобразятся Отдельные серверы в этой группе ресурсов в разных регионах. Выберите источник, из которого хотите перенести базы данных. Базы данных можно перенести с одного сервера на целевой гибкий сервер в одном регионе. Миграция между регионами включается только для серверов Индии, Китая и ОАЭ.

После выбора источника одного сервера поля "Расположение", "PostgreSQL" и "Имя входа администратора сервера" заполняются автоматически. Имя входа администратора сервера — это имя администратора, используемое для создания отдельного сервера. В поле "Пароль" введите пароль для этого администратора. Служба миграции переносит базы данных одного сервера в качестве пользователя администратора.

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

Нажмите кнопку "Далее". Нажмите кнопку "Цель миграции", чтобы продолжить.

Вкладка "Целевой объект"

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

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

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

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

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

Нажмите кнопку "Далее", чтобы просмотреть сведения.

Итоги

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

Мониторинг портала миграции

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

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

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

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

Давайте рассмотрим, как отслеживать миграцию для каждого варианта миграции.

Проверить

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

Проверка перемещается в состояние "Успешно", если все проверки находятся в состоянии "Успешно" или "Предупреждение".

Сетка проверки имеет

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

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

Миграция

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

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

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

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

Проверка и миграция

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

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

После завершения операции вы увидите результаты проверки и миграции .

Online (предварительная версия)

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

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

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

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

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

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

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

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

Настройка параметров миграции через Интернет

Для миграции в Интернете для поддержки реплика следует задать значение "Логический" в разделе параметров реплика tion исходного сервера PostgreSQL. Кроме того, параметры max_wal_senders и max_replication_slots значения сервера должны быть равны количеству баз данных, которые необходимо перенести. Их также можно настроить в командной строке с помощью следующих команд:

• ALTER SYSTEM SET wal_level = логический;
• ALTER SYSTEM SET max_wal_senders = number of databases to migrate;
• ALTER SYSTEM SET max_реплика tion_slots = number of databases to migrate;

После завершения всех предварительных требований для миграции через Интернет необходимо перезапустить исходный сервер PostgreSQL.

Примечание.

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

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

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

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

• 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. Этот параметр указывает набор библиотек расширений, предварительно загруженных при перезапуске сервера.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

   

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

   

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

5. Нажмите кнопку Перенести из Отдельного сервера. Чтобы создать миграцию на этот гибкий целевой сервер с любого исходного отдельного сервера, перейдите через ряд вкладок на основе мастера.

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

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

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

   

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

   

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

   

После развертывания гибкого сервера выполните действия 3–5 в разделе "Настройка задачи миграции".

Вкладка "Настройка"

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

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

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

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

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

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

Если выбрана предварительная версия миграции в Интернете, в исходном отдельном сервере должна быть включена логическая реплика. Если она не включена, служба миграции автоматически включает логическую реплика на исходном отдельном сервере. Репликация также может быть настроена вручную на вкладке "Репликация" на панели "Один сервер", задав уровень поддержки поддержки azure реплика tion логическому. Любой подход перезапускает исходный отдельный сервер.

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

Вкладка Источник

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

После выбора подписки и группы ресурсов в раскрывающемся списке имен серверов отобразятся Отдельные серверы в этой группе ресурсов в разных регионах. Выберите источник, из которого хотите перенести базы данных. Базы данных можно перенести с одного сервера на целевой гибкий сервер в одном регионе. Миграция между регионами включается только для серверов Индии, Китая и ОАЭ.

После выбора источника одного сервера поля "Расположение", "PostgreSQL" и "Имя входа администратора сервера" заполняются автоматически. Имя входа администратора сервера — это имя администратора, используемое для создания отдельного сервера. В поле "Пароль" введите пароль для этого администратора. Служба миграции переносит базы данных одного сервера в качестве пользователя администратора.

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

Нажмите кнопку "Далее". Нажмите кнопку "Цель миграции", чтобы продолжить.

Вкладка "Целевой объект"

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

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

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

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

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

Нажмите кнопку "Далее", чтобы просмотреть сведения.

Итоги

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

Мониторинг миграции с помощью портал Azure

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

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

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

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

Давайте рассмотрим, как отслеживать миграцию для каждого варианта миграции.

Проверить

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

Проверка перемещается в состояние "Успешно", если все проверки находятся в состоянии "Успешно" или "Предупреждение".

Сетка проверки имеет

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

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

Миграция

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

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

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

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

Проверка и миграция

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

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

После завершения операции вы увидите результаты проверки и миграции .

Переключение миграции

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

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

• Записи в источник остановлены:Latency (minutes) параметр равен 0 или близко к 0. Сведения Latency (minutes) можно получить на экране сведений о миграции, как показано ниже:

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

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

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

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

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

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

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

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

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

CLI

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

Автономный режим

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

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

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

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

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

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

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

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

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

Начать

1. Если вы не знакомы с Microsoft Azure, создайте учетную запись для оценки предложений.

2. Установите последнюю версию Azure CLI для своей операционной системы на странице установки Azure CLI.

   Если Azure CLI уже установлен, проверьте версию с помощью команды az version. Для использования команд ИНТЕРФЕЙСА командной строки миграции должна быть версия 2.50.0 или более поздней. Если это не так, обновите свою версию Azure CLI.

3. Выполните команду az login.

   az login
   

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

Команды ИНТЕРФЕЙСА командной строки миграции (автономный режим)

Служба миграции поставляется с простыми командами ИНТЕРФЕЙСА командной строки для выполнения задач, связанных с миграцией. Все команды CLI начинаются с az postgres flexible-server migration. Перед началом миграции важно разрешить список расширений.

Параметр help поможет получить представление о параметрах, связанных с командой, и правильно оформить синтаксис:

az postgres flexible-server migration --help

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

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

Создание миграции с помощью Azure CLI

Команда create помогает создать миграцию с исходного сервера на целевой:

az postgres flexible-server migration create -- help

Приведенная выше команда дает следующий результат:

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

az postgres flexible-server migration create [--subscription]
                                            [--resource-group]
                                            [--name]
                                            [--migration-name]
                                            [--migration-mode]
                                            [--properties]

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

Например:

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

Аргументmigration-name, используемый в create команде, используется в других командах CLI, таких как updatedelete, и show. однозначно определяет попытку миграции в соответствующих действиях во всех этих командах.

Наконец, команда create должна передавать JSON-файл как часть его properties аргумента.

Структура JSON:

{
"properties": {
 "sourceDbServerResourceId":"/subscriptions/<subscriptionid>/resourceGroups/<src_ rg_name>/providers/Microsoft.DBforPostgreSQL/servers/<source server name>",
"secretParameters": {
    "adminCredentials":
    {
      "sourceServerPassword": "<password>",
      "targetServerPassword": "<password>"
    },
   "sourceServerUserName": "<username>@<servername>",
   "targetServerUserName": "<username>"
},

"dbsToMigrate":
   [
   "<db1>","<db2>"
   ],

"overwriteDbsInTarget":"true"

}
}

Параметры create , которые входят в формат JSON-файла, как показано ниже:

Параметр	Тип	Описание
sourceDbServerResourceId	Обязательное поле	Этот параметр является идентификатором ресурса источника отдельного сервера и является обязательным.
adminCredentials	Обязательное поле	Этот параметр содержит пароли для пользователей администратора как для источника одного сервера, так и для целевого объекта гибкого сервера. Эти пароли помогают выполнять проверку подлинности для исходного и целевого серверов.
sourceServerUserName	Обязательное поле	Значением по умолчанию является пользователь администратора, созданный во время создания одного сервера, и пароль, предоставленный для проверки подлинности для этого пользователя. Если вы не используете пользователя по умолчанию, этот параметр является пользователем или ролью на исходном сервере для выполнения миграции. Этот пользователь должен иметь необходимые привилегии и владение объектами базы данных, участвующими в миграции, и должен быть членом роли azure_pg_admin .
targetServerUserName	Обязательное поле	Значением по умолчанию является пользователь администратора, созданный во время создания гибкого сервера, а пароль, предоставленный для проверки подлинности для этого пользователя. Если вы не используете пользователя по умолчанию, этот параметр является пользователем или ролью на целевом сервере, используемом для выполнения миграции. Этот пользователь должен быть членом azure_pg_admin, pg_read_all_settings, pg_read_all_stats,pg_stat_scan_tables ролей и должен иметь роль create, Create DB attributes.
dbsToMigrate	Обязательное поле	Укажите список баз данных, которые требуется перенести в Гибкий сервер. Переносятся только пользовательские базы данных. Системные базы данных или базы данных шаблонов, такие как template0 и template1, не будут перенесены.
overwriteDbsInTarget	Обязательное поле	Если задано значение true, если целевой сервер имеет существующее имя базы данных с тем же именем, что и при попытке перенести, служба миграции автоматически перезаписывает базу данных.
SetupLogicalReplicationOnSourceDBIfNeeded	Необязательно	Вы можете автоматически включить логическую реплика на исходном сервере, задав для этого свойства значение true. Для этого изменения параметров сервера требуется перезапуск сервера с двумя до трех минут простоя.
SourceDBServerFullyQualifiedDomainName	Необязательно	Используйте этот параметр, если пользовательский сервер доменных имен используется для разрешения имен для виртуальной сети. Укажите FQDN источника в рамках Отдельного сервера в соответствии с пользовательским DNS-сервером для этого свойства.
TargetDBServerFullyQualifiedDomainName	Необязательно	Используйте этот параметр, если пользовательский сервер доменных имен используется для разрешения имен внутри виртуальной сети. Укажите FQDN целевого объекта в рамках Гибкого сервера в соответствии с пользовательским DNS-сервером. SourceDBServerFullyQualifiedDomainName и TargetDBServerFullyQualifiedDomainName включаются в состав JSON только в редких случаях, когда пользовательский DNS-сервер используется для разрешения имен вместо DNS, предоставленного Azure. В противном случае не включайте эти параметры в JSON-файл.

Обратите внимание на следующие важные моменты для ответа команды:

• create При активации команды миграция перемещается в InProgress состояние и PerformingPreRequisiteSteps подложку. Рабочий процесс миграции занимает несколько минут, чтобы развернуть инфраструктуру миграции и настроить подключения между источником и целевым объектом.
• PerformingPreRequisiteSteps После завершения подстатирования миграция перемещается в подложку, в Migrating Data, которой происходит клонирование и копирование баз данных.
• Каждая база данных, перенесенная, имеет собственный раздел со всеми сведениями о миграции, такими как количество таблиц, добавочные вставки, удаления и ожидающие байты.
• Migrating Data Время завершения субстата зависит от размера перенесенных баз данных.
• Миграция перемещается Succeeded в состояние сразу после успешного Migrating Data завершения подстатирования. Если в подсостоянии возникла проблема Migrating Data, миграция переходит в состояние Failed.

Настройка репликации

Если выбрана предварительная версия миграции в Интернете, в исходном отдельном сервере должна быть включена логическая реплика. Если она не включена, служба миграции автоматически включает логическую реплика на исходном отдельном сервере при SetupLogicalReplicationOnSourceDBIfNeeded передаче параметра со значением true в сопровождающем JSON-файле. Репликация также может быть настроена вручную в источнике после запуска миграции с помощью следующей команды. Любой подход включения логической реплика tion перезапускает исходный отдельный сервер.

Например:

az postgres flexible-server migration update --subscription 11111111-1111-1111-1111-111111111111 --resource-group my-learning-rg --name myflexibleserver --migration-name CLIMigrationExample --setup-replication

Эта команда необходима для продвижения миграции при ожидании гибкого WaitingForLogicalReplicationSetupRequestOnSourceDB сервера в состоянии.

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

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

Перечисление миграций

Команда list перечисляет все попытки миграции, выполненные в целевой объект гибкого сервера:

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

Параметр filter имеет два варианта:

• Active: выводит список текущих активных попыток миграции (выполняется) на целевом сервере. Он не включает миграции, которые завершились сбоем, отменены или выполнены успешно.
• All: выводит список всех попыток миграции на целевой сервер. Сюда входят как активные, так и предыдущие миграции, независимо от состояния.

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

az postgres flexible-server migration list -- help

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

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

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

Параметр migration_name — это имя, назначенное миграции при выполнении команды create. Ниже приведен моментальный снимок примера ответа на команду CLI для отображения сведений:

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

 az postgres flexible-server migration show -- help

В следующих таблицах описаны состояния и подсостояния миграции.

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

Подсостояние миграции	Description
PerformingPreRequisiteSteps	Инфраструктура настроена и предварительно настроена для миграции данных.
MigratingData	Выполняется миграция данных.
CompletingMigration	Выполняется прямая миграция.
Completed	переход был успешным, и миграция завершена.

Online (предварительная версия)

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

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

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

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

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

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

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

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

Настройка параметров миграции через Интернет

Для миграции в Интернете для поддержки реплика следует задать значение "Логический" в разделе параметров реплика tion исходного сервера PostgreSQL. Кроме того, параметры max_wal_senders и max_replication_slots значения сервера должны быть равны количеству баз данных, которые необходимо перенести. Их также можно настроить в командной строке с помощью следующих команд:

• ALTER SYSTEM SET wal_level = логический;
• ALTER SYSTEM SET max_wal_senders = number of databases to migrate;
• ALTER SYSTEM SET max_реплика tion_slots = number of databases to migrate;

После завершения всех предварительных требований для миграции через Интернет необходимо перезапустить исходный сервер PostgreSQL.

Примечание.

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

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

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

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

• 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. Этот параметр указывает набор библиотек расширений, предварительно загруженных при перезапуске сервера.

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

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

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

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

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

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

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

Начать

1. Если вы не знакомы с Microsoft Azure, создайте учетную запись для оценки предложений.

2. Установите последнюю версию Azure CLI для своей операционной системы на странице установки Azure CLI.

   Если Azure CLI уже установлен, проверьте версию с помощью команды az version. Для использования команд ИНТЕРФЕЙСА командной строки миграции должна быть версия 2.50.0 или более поздней. Если это не так, обновите свою версию Azure CLI.

3. Выполните команду az login.

   az login
   

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

Команды ИНТЕРФЕЙСА командной строки миграции (в сети)

Служба миграции поставляется с простыми командами ИНТЕРФЕЙСА командной строки для выполнения задач, связанных с миграцией. Все команды CLI начинаются с az postgres flexible-server migration. Перед началом миграции важно разрешить список расширений.

Параметр help поможет получить представление о параметрах, связанных с командой, и правильно оформить синтаксис:

az postgres flexible-server migration --help

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

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

Создание миграции с помощью Azure CLI

Команда create помогает создать миграцию с исходного сервера на целевой:

az postgres flexible-server migration create -- help

Приведенная выше команда дает следующий результат:

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

az postgres flexible-server migration create [--subscription]
                                            [--resource-group]
                                            [--name]
                                            [--migration-name]
                                            [--migration-mode]
                                            [--properties]

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

Например:

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

Аргументmigration-name, используемый в create команде, используется в других командах CLI, таких как updatedelete, и show. однозначно определяет попытку миграции в соответствующих действиях во всех этих командах.

Наконец, команда create должна передавать JSON-файл как часть его properties аргумента.

Структура JSON:

{
"properties": {
 "sourceDbServerResourceId":"/subscriptions/<subscriptionid>/resourceGroups/<src_ rg_name>/providers/Microsoft.DBforPostgreSQL/servers/<source server name>",
"secretParameters": {
    "adminCredentials":
    {
      "sourceServerPassword": "<password>",
      "targetServerPassword": "<password>"
    },
   "sourceServerUserName": "<username>@<servername>",
   "targetServerUserName": "<username>"
},

"dbsToMigrate":
   [
   "<db1>","<db2>"
   ],

"overwriteDbsInTarget":"true"

}
}

Параметры create , которые входят в формат JSON-файла, как показано ниже:

Параметр	Тип	Описание
sourceDbServerResourceId	Обязательное поле	Этот параметр является идентификатором ресурса источника отдельного сервера и является обязательным.
adminCredentials	Обязательное поле	Этот параметр содержит пароли для пользователей администратора как для источника одного сервера, так и для целевого объекта гибкого сервера. Эти пароли помогают выполнять проверку подлинности для исходного и целевого серверов.
sourceServerUserName	Обязательное поле	Значением по умолчанию является пользователь администратора, созданный во время создания одного сервера, и пароль, предоставленный для проверки подлинности для этого пользователя. Если вы не используете пользователя по умолчанию, этот параметр является пользователем или ролью на исходном сервере для выполнения миграции. Этот пользователь должен иметь необходимые привилегии и владение объектами базы данных, участвующими в миграции, и должен быть членом роли azure_pg_admin .
targetServerUserName	Обязательное поле	Значением по умолчанию является пользователь администратора, созданный во время создания гибкого сервера, а пароль, предоставленный для проверки подлинности для этого пользователя. Если вы не используете пользователя по умолчанию, этот параметр является пользователем или ролью на целевом сервере, используемом для выполнения миграции. Этот пользователь должен быть членом azure_pg_admin, pg_read_all_settings, pg_read_all_stats,pg_stat_scan_tables ролей и должен иметь роль create, Create DB attributes.
dbsToMigrate	Обязательное поле	Укажите список баз данных, которые требуется перенести в Гибкий сервер. Переносятся только пользовательские базы данных. Системные базы данных или базы данных шаблонов, такие как template0 и template1, не будут перенесены.
overwriteDbsInTarget	Обязательное поле	Если задано значение true, если целевой сервер имеет существующее имя базы данных с тем же именем, что и при попытке перенести, служба миграции автоматически перезаписывает базу данных.
SetupLogicalReplicationOnSourceDBIfNeeded	Необязательно	Вы можете автоматически включить логическую реплика на исходном сервере, задав для этого свойства значение true. Для этого изменения параметров сервера требуется перезапуск сервера с двумя до трех минут простоя.
SourceDBServerFullyQualifiedDomainName	Необязательно	Используйте этот параметр, если пользовательский сервер доменных имен используется для разрешения имен для виртуальной сети. Укажите FQDN источника в рамках Отдельного сервера в соответствии с пользовательским DNS-сервером для этого свойства.
TargetDBServerFullyQualifiedDomainName	Необязательно	Используйте этот параметр, если пользовательский сервер доменных имен используется для разрешения имен внутри виртуальной сети. Укажите FQDN целевого объекта в рамках Гибкого сервера в соответствии с пользовательским DNS-сервером. SourceDBServerFullyQualifiedDomainName и TargetDBServerFullyQualifiedDomainName включаются в состав JSON только в редких случаях, когда пользовательский DNS-сервер используется для разрешения имен вместо DNS, предоставленного Azure. В противном случае не включайте эти параметры в JSON-файл.

Обратите внимание на следующие важные моменты для ответа команды:

• create При активации команды миграция перемещается в InProgress состояние и PerformingPreRequisiteSteps подложку. Рабочий процесс миграции занимает несколько минут, чтобы развернуть инфраструктуру миграции и настроить подключения между источником и целевым объектом.
• PerformingPreRequisiteSteps После завершения подстатирования миграция перемещается в подложку, в Migrating Data, которой происходит клонирование и копирование баз данных.
• Каждая база данных, перенесенная, имеет собственный раздел со всеми сведениями о миграции, такими как количество таблиц, добавочные вставки, удаления и ожидающие байты.
• Migrating Data Время завершения субстата зависит от размера перенесенных баз данных.
• Миграция перемещается Succeeded в состояние сразу после успешного Migrating Data завершения подстатирования. Если в подсостоянии возникла проблема Migrating Data, миграция переходит в состояние Failed.

Настройка репликации

Если выбрана предварительная версия миграции в Интернете, в исходном отдельном сервере должна быть включена логическая реплика. Если она не включена, служба миграции автоматически включает логическую реплика на исходном отдельном сервере при SetupLogicalReplicationOnSourceDBIfNeeded передаче параметра со значением true в сопровождающем JSON-файле. Репликация также может быть настроена вручную в источнике после запуска миграции с помощью следующей команды. Любой подход включения логической реплика tion перезапускает исходный отдельный сервер.

Например:

az postgres flexible-server migration update --subscription 11111111-1111-1111-1111-111111111111 --resource-group my-learning-rg --name myflexibleserver --migration-name CLIMigrationExample --setup-replication

Эта команда необходима для продвижения миграции при ожидании гибкого WaitingForLogicalReplicationSetupRequestOnSourceDB сервера в состоянии.

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

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

Перечисление миграций

Команда list перечисляет все попытки миграции, выполненные в целевой объект гибкого сервера:

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

Параметр filter имеет два варианта:

• Active: выводит список текущих активных попыток миграции (выполняется) на целевом сервере. Он не включает миграции, которые завершились сбоем, отменены или выполнены успешно.
• All: выводит список всех попыток миграции на целевой сервер. Сюда входят как активные, так и предыдущие миграции, независимо от состояния.

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

az postgres flexible-server migration list -- help

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

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

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

Параметр migration_name — это имя, назначенное миграции при выполнении команды create. Ниже приведен моментальный снимок примера ответа на команду CLI для отображения сведений:

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

 az postgres flexible-server migration show -- help

В следующих таблицах описаны состояния и подсостояния миграции.

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

Подсостояние миграции	Description
PerformingPreRequisiteSteps	Инфраструктура настроена и предварительно настроена для миграции данных.
MigratingData	Выполняется миграция данных.
CompletingMigration	Выполняется прямая миграция.
Completed	переход был успешным, и миграция завершена.

Переключение миграции

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

Например:

az postgres flexible-server migration update --subscription 11111111-1111-1111-1111-111111111111 --resource-group my-learning-rg --name myflexibleserver --migration-name CLIMigrationExample --cutover

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

• Запись в источник остановлена.latency Параметр уменьшается до 0 или близко к 0

latency параметр указывает, когда целевой объект последний раз синхронизируется с источником. Например, здесь 201 и 202 для двух баз данных, как показано на рисунке ниже. Это означает, что изменения, произошедшие за последние около 200 секунд в источнике, пока не синхронизированы с целевым объектом. На этом этапе записи в источник можно остановить и начать переключение. В случае, если в источнике большой трафик, рекомендуется сначала остановить запись, чтобы Latency приблизиться к 0, а затем начать переключение. Операция переключение применяет все ожидающие изменения из источника к целевому объекту и завершает миграцию. Если вы активируете "Cutover" даже с ненулевойLatency, реплика tion останавливается до этого момента времени. Все данные источника до тех пор, пока точка переключа не будет применена к целевому объекту. Предположим, что задержка составила 15 минут в точке переключение, поэтому все данные об изменениях за последние 15 минут применяются к целевому объекту. Время, затраченное на последние 15 минут, зависит от невыполненной работы изменений. Поэтому рекомендуется, чтобы задержка была равна нулю или почти нулю, прежде чем активировать переключение. Сведения latency можно получить с помощью команды шоу миграции. Ниже приведен моментальный снимок миграции перед началом перехода:

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

Если переключение не выполнено, миграция перемещается в Failed состояние.

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

 az postgres flexible-server migration update -- help

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

Вы можете отменить все текущие попытки миграции с помощью 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
• Рекомендации
• Известные проблемы и ограничения
• Настройка сети
• Проверки предварительной подготовки