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

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

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

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

Использование портала Azure:

1. Выберите ваш гибкий сервер Azure Database for PostgreSQL.

2. В меню ресурсов выберите "Миграция".

   

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

   Примечание.

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

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

   

Настройка

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

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

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

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

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

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

Чтобы узнать больше о проверке premigration, посетите этот ресурс.

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

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

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

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

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

Исходный сервер

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

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

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

Целевой сервер

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

• Имя входа администратора — имя администратора целевого сервера PostgreSQL.
• Пароль — пароль для входа администратора, предоставленного для подключения к целевому серверу PostgreSQL.
• Настраиваемое полное доменное имя или IP-адрес: настраиваемое полное доменное имя или поле IP-адреса является необязательным и может использоваться, если целевой объект находится за пользовательским DNS-сервером или имеет пользовательские пространства имен DNS, что делает его доступным только через определенные полные доменные имена или IP-адреса. Например, это может включать такие записи, как production-flexible-server.example.com, 198.1.0.2 или полное доменное имя PostgreSQL, например production-flexible-server.postgres.database.azure.com, если пользовательский DNS-сервер содержит DNS-зону postgres.database.azure.com или перенаправляет запросы для этой зоны на 168.63.129.16, где полное доменное имя разрешается в общедоступной или частной зоне DNS Azure.
• Проверка подключения — выполняет проверку подключения между источником и целевым объектом. После успешного подключения перейдите на следующую вкладку. Эти тесты предназначены для выявления проблем с подключением, которые могут существовать между исходными и целевыми серверами, включая проверку подлинности с использованием предоставленных учетных данных. Установка тестового подключения занимает несколько секунд.

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

Базы данных для проверки или миграции

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

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

Итоги

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

Отмена проверки или миграции

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

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

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

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

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

После установки CLI, откройте командную строку и авторизуйтесь в учетной записи Azure с помощью следующей команды.

az login

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

Чтобы начать миграцию, создайте JSON-файл с подробными сведениями о миграции. JSON-файл содержит следующие сведения:

• Измените заполнители << >> в строках JSON ниже и сохраните их на локальном компьютере, где вызывается <<filename>>.json CLI. В этом руководстве мы сохранили файл в c:/migration-CLI/migration_body.json

{
"properties": {
"SourceDBServerResourceId": "<<source-server-hostname-or-IP-address>>:<<port>>@<<username>>",
        "SecretParameters": {
            "AdminCredentials": {
                "SourceServerPassword": "<<source-server-administrator-password>>",
                "TargetServerPassword": "<<target-server-administrator-password>>"
            },
            "targetServerUserName": "<<target-server-administrator-login>>"
        },
        "DBsToMigrate": "<<comma-separated-list-of-databases-in-array-like-["ticketdb","timedb","inventorydb"]>>",
        "OverwriteDBsInTarget": "true",
        "sourceType": "OnPremises",
        "sslMode": "Prefer"
    }
}

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

  az postgres flexible-server migration list --subscription <subscription_id> --resource-group <resource_group> --name <target_server> --filter all
  

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

  az postgres flexible-server migration create --subscription <subscription_id> --resource-group <resource_group> --name <target_server> --migration-name <migration> --migration-mode offline --migration-option ValidateAndMigrate --properties "c:/migration-cli/migration_body.json"
  

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

  az postgres flexible-server migration show --subscription <subscription_id> --resource-group <resource_group> --name <target_server> --migration-name <migration>
  

• Ход выполнения и состояние миграции отображается в Azure CLI.

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

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

  az postgres flexible-server migration update cancel --subscription <subscription_id> --resource-group <resource_group> --name <target_server> --migration-name <migration>
  

Для опции проверки и миграции завершение онлайн-миграции требует от пользователя выполнения дополнительного шага, для чего нужно инициировать действие переключения. После завершения копирования или клонирования базовых данных миграция переходит в Waiting for user action статус и Waiting for cutover trigger подстатус. В этом состоянии пользователь может активировать переход на портале, выбрав миграцию.

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

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

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

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

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

Для опции проверки и миграции завершение онлайн-миграции требует от пользователя выполнения дополнительного шага, для чего нужно инициировать действие переключения. После завершения копирования или клонирования базовых данных миграция переходит в Waiting for user action статус и Waiting for cutover trigger подстатус. В этом состоянии пользователь может запустить переключение с помощью команд CLI, приведенной ниже. Переключение также можно активировать на портале, выбрав имя миграции в сетке миграции.

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

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

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

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

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

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

az postgres flexible-server migration update --subscription <subscription_id> --resource-group <resource_group> --name <server> --migration-name <migration> --cutover