Руководство по миграции с База данных 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 см. по следующей ссылке: краткое руководство. Создание сервера.

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

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

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

Включение расширений

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

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

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

Примечание.

При наличии изменений в 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 отдельный сервер, который является тем, который мы заинтересованы в этом сценарии.

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

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

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

   

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

   

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

   

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

Настройка

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Нажмите кнопку "Далее" для просмотра сведений.

Итоги

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

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

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

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

С помощью кнопки "Обновить" можно обновить состояние проверки или миграции.

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

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

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

Проверить

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

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

В сетке проверки содержатся следующие сведения:

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

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

Миграция

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

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

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

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

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

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

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

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

В сети

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

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

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

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

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

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

• ALTER SYSTEM SET wal_level = логический;
• ALTER SYSTEM SET max_wal_senders = number of databases to migrate + 1;
• ALTER SYSTEM SET max_replication_slots = number of databases to migrate + 1;

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

Примечание.

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

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

Настройка целевого объекта

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

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

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

• Параметр max_replication_slots сервера должен превышать количество баз данных, которые необходимо перенести. Его можно задать в портал Azure в разделе "Параметры сервера>" или в командной строке с помощью следующей команды:

• ALTER SYSTEM SET max_replication_slots = number of databases to migrate + 1;

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

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

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

Включение расширений

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

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

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

Примечание.

При наличии изменений в 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 отдельный сервер, который является тем, который мы заинтересованы в этом сценарии.

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

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

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

   

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

   

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

   

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

Настройка

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

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

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

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

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

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

Режим миграции позволяет выбирать между интернетом и автономной миграцией, в этом случае он должен иметь значение Online.

При выборе режима миграции в сети логическая репликация должна быть включена на исходном отдельном сервере. Если она не включена, служба миграции автоматически включает логическую репликацию на исходном отдельном сервере. Репликация также можно настроить вручную, выбрав элемент репликации в разделе "Параметры" в меню ресурсов отдельного сервера и установив поддержку репликации Azure для ЛОГИЧЕСКОГО. Любой подход перезапускает исходный отдельный сервер.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Нажмите кнопку "Далее" для просмотра сведений.

Итоги

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

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

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

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

С помощью кнопки "Обновить" можно обновить состояние проверки или миграции.

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

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

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

Проверить

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

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

В сетке проверки содержатся следующие сведения:

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

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

Миграция

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• 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 см. по следующей ссылке: краткое руководство. Создание сервера.

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

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

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

Включение расширений

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

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

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

Примечание.

При наличии изменений в 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 "./migrationBody.json" --migration-mode offline

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

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

Структура JSON:

{
  "properties": {
    "sourceDbServerResourceId": "/subscriptions/<subscriptionid>/resourceGroups/<sourceServerResourceGroup>/providers/Microsoft.DBforPostgreSQL/servers/<sourceServer>",
    "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.

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

Команда 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	Миграция прошла успешно и завершена.
ValidationFailed	Миграция завершилась сбоем во время предварительной проверки миграции.

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

В сети

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

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

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

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

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

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

• ALTER SYSTEM SET wal_level = логический;
• ALTER SYSTEM SET max_wal_senders = number of databases to migrate + 1;
• ALTER SYSTEM SET max_replication_slots = number of databases to migrate + 1;

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

Примечание.

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

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

Настройка целевого объекта

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

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

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

• Параметр max_replication_slots сервера должен превышать количество баз данных, которые необходимо перенести. Его можно задать в портал Azure в разделе "Параметры сервера>" или в командной строке с помощью следующей команды:

• ALTER SYSTEM SET max_replication_slots = number of databases to migrate + 1;

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

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

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

Включение расширений

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

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

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

Примечание.

При наличии изменений в 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	Этот параметр является необязательным. Значение по умолчанию: Offline. Для миграций через Интернет необходимо пройти Online.
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 "./migrationBody.json" --migration-mode online

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

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

Структура JSON:

{
  "properties": {
    "sourceDbServerResourceId": "/subscriptions/<subscriptionid>/resourceGroups/<sourceServerResourceGroup>/providers/Microsoft.DBforPostgreSQL/servers/<sourceServer>",
    "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-файле. Репликация также может быть настроена вручную в источнике после запуска миграции с помощью следующей команды. Любой из способов включения логической репликации перезапускает исходный отдельный сервер.

Например:

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 "./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	Миграция прошла успешно и завершена.
ValidationFailed	Миграция завершилась сбоем во время предварительной проверки миграции.

Подсостояние миграции	Description
PerformingPreRequisiteSteps	Инфраструктура настроена и подготовлена к миграции данных.
MigratingData	Выполняется миграция данных.
WaitingForCutoverTrigger	Задача миграции данных завершена и ожидает, что пользователь будет запускать переключение.
CompletingMigration	Завершение процесса миграции.
Completed	Миграция завершена, независимо от того, выполняется ли успешное состояние.
CancelingRequestedDBMigrations	Отмена миграции.
ValidationInProgress	Проверка выполняется.

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

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