Миграция через Интернет с сервера Google Cloud SQL для PostgreSQL в Базу данных Azure для PostgreSQL с помощью службы миграции

В этой статье описано, как использовать портал Azure для переноса базы данных PostgreSQL с сервера Google Cloud SQL для 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 для службы миграции.

После установки интерфейса командной строки откройте терминал и войдите в свою учетную запись 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