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

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

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

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

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

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

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

   

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

   

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

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

Настройка

Первая вкладка — это вкладка установки, где пользователь инициирует миграцию, предоставляя сведения о миграции, такие как имя миграции и тип источника.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

После успешного тестового подключения нажмите кнопку Next: Select Database(s) for Migration (Выбор баз данных) для миграции

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

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

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

Итоги

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

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

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

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

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

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

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

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

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

Некоторые возможные состояния миграции:

Состояния миграции

Подэтапы миграции

Подстатки проверки

Прямая миграция

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

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

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

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

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

Отмена миграции

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

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

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

В этой статье рассматривается использование 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 hostname or IP address>>:<<port>>@<<username>>",
        "SecretParameters": {
            "AdminCredentials": {
                "SourceServerPassword": "<<Source Password>>",
                "TargetServerPassword": "<<Target Password>>"
            },
            "targetServerUserName": "<<Target username>>"
        },
        "DBsToMigrate": "<<comma separated list of databases in a array like - ["ticketdb","timedb","inventorydb"]>>",
        "OverwriteDBsInTarget": "true",
        "sourceType": "OnPremises",
        "sslMode": "Prefer"
    }
}

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

  az postgres flexible-server migration list --subscription 11111111-1111-1111-1111-111111111111 --resource-group my-learning-rg --name myflexibleserver --filter All
  

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

  az postgres flexible-server migration create --subscription 11111111-1111-1111-1111-111111111111 --resource-group my-learning-rg --name myflexibleserver --migration-name migration1 --migration-mode online --migration-option ValidateAndMigrate --properties "C:\migration-cli\migration_body.json"
  

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

  az postgres flexible-server migration show --subscription 11111111-1111-1111-1111-111111111111 --resource-group my-learning-rg --name myflexibleserver --migration-name migration1
  

• Состояние хода миграции отображается в Azure CLI.

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

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

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

Переключение

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

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

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