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

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

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

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

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

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

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

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

Поле настраиваемого полного доменного имени или IP-адреса является необязательным и может использоваться, если источник находится за пользовательским DNS-сервером или имеет пользовательские пространства имен DNS, что делает его доступным только через определенные полные доменные имена или IP-адреса. Например, это может включать такие записи, как singleserver.example.com198.1.0.2, или полное доменное имя PostgreSQL, напримерsingleserver.postgres.database.azure.com, если пользовательский DNS-сервер содержит зону postgres.database.azure.com DNS или пересылает запросы для этой зоны168.63.129.16, где полное доменное имя разрешается в общедоступной или частной зоне DNS Azure.

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

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

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

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

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

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

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

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

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

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

Итоги

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

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

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

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

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

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

При создании проверки или миграции он перемещается в состояние 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.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.

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

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

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

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

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

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

• Записи в источник остановлены: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: миграция находится на заключительных этапах завершения.
• Завершено: миграция успешно завершена.

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

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

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

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

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

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

• Сопоставлять значения параметров сервера из исходной базы данных 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]

Например:

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-файла, как показано ниже:

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

• 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

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

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

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

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

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

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

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

• Сопоставлять значения параметров сервера из исходной базы данных 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]

Например:

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-файла, как показано ниже:

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

• 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

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

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

После завершения миграции базовых данных задача миграции перемещается в 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