Поделиться через

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

ПРИМЕНЯЕТСЯ К: База данных Azure для PostgreSQL — отдельный сервер

Теперь Azure Database для PostgreSQL Single Server вышла из эксплуатации. В результате статьи миграции, связанные с этой службой, будут удалены в ближайшее время. Важно мигрировать на гибкий сервер базы данных Azure для PostgreSQL, чтобы обеспечить непрерывность обслуживания и поддержку. Просмотрите и завершите все необходимые миграции на гибкий сервер, прежде чем эти ресурсы больше не доступны.

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

Automigration использует службу миграции Azure PostgreSQL для обеспечения устойчивой автономной миграции во время запланированного периода миграции. Время простоя зависит от характеристик рабочей нагрузки. Тесты скорости миграции см. в статье Azure PostgreSQL Migration Speed Benchmarking. Эта миграция удаляет необходимость миграции сервера вручную. После миграции вы можете воспользоваться такими функциями гибкого сервера, как улучшенное соотношение цены и производительности, детализированное управление конфигурацией базы данных и настраиваемые периоды обслуживания.

Примечание.

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

  • Серверы с настроенными ключами, управляемыми клиентом
  • Серверы с запретом доступа к общедоступной сети, равным "Да"

Назначение отдельных серверов для автомиграции

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

Проверка готовности для автомиграции

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

  • Экземпляр одиночного сервера должен находиться в состоянии готовности во время запланированного периода миграции для автоматической миграции.

  • Экземпляр одного сервера должен иметь параметр "Запрет доступа к общедоступной сети ", настроенный на "Нет". Этот параметр можно найти на странице "Безопасность подключения" на портале Azure.

  • Для одного экземпляра сервера с включенным SSL убедитесь, что у вас есть все сертификаты (DigiCertGlobalRootG2 Root CA и DigiCertGlobalRootCA Root CA) доступны в доверенном корневом хранилище. Кроме того, если у вас есть сертификат, привязанный к строке подключения, создайте объединенный сертификат УЦ со всеми тремя сертификатами до запланированной автоматической миграции для обеспечения непрерывности бизнес-процессов после миграции.

  • Если в исходной базе данных Azure для postgresql single Server есть имена правил брандмауэра, превышающие 80 символов, переименуйте их, чтобы длина имени была меньше 80 символов. (Длина имени правила брандмауэра, поддерживаемая на гибком сервере, составляет 80 символов, в то время как на одном сервере разрешенная длина составляет 128 символов.)

Процесс автомиграции

Процесс автомиграции включает несколько ключевых этапов:

  • Создание целевого гибкого сервера — гибкий сервер создается для соответствия производительности и стоимости спецификации SKU одиночного сервера. Он наследует все правила брандмауэра от исходного отдельного сервера.

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

  • DNS-коммутатор . После миграции данных выполняется переключатель DNS, позволяющий существующей строке подключения к одному серверу легко подключаться к новому гибкому серверу. В перенесенном гибком сервере поддерживаются форматы строк подключения для однопользовательского и гибкого сервера, а также форматы имен пользователей, такие как username@server_name и username.

  • Гибкая видимость сервера . После успешной миграции данных и переключения DNS новый гибкий сервер отображается в подписке и может управляться с помощью портала Azure или ИНТЕРФЕЙСА командной строки.

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

  • Удаление одного сервера — одиночный сервер сохраняется в течение семи дней после миграции до его удаления.

Как подготовлен целевой гибкий сервер Postgresql?

Уровень вычислений и номер SKU для целевого гибкого сервера подготавливаются на основе ценовой категории исходного отдельного сервера и виртуальных ядер.

Уровень цен для отдельного сервера Виртуальные ядра однопользовательского сервера Гибкий уровень сервера Имя SKU гибкого сервера
Базовый 1 С увеличивающейся производительностью B1ms
Базовый 2 С увеличивающейся производительностью B2s
Общего назначения 2 Общего назначения Standard_D2s_v3
Общего назначения 4 Общего назначения Standard_D4s_v3
Общего назначения 8 Общего назначения Standard_D8s_v3
Общего назначения 16 Общего назначения Standard_D16s_v3
Общего назначения 32 Общего назначения Standard_D32s_v3
Общего назначения 64 Общего назначения Standard_D64s_v3
Оптимизированная память 2 ОптимизированнаяПамять Standard_E2s_v3
Оптимизированная память 4 ОптимизированнаяПамять Standard_E4s_v3
Оптимизированная память 8 ОптимизированнаяПамять Standard_E8s_v3
Оптимизированная память 16 ОптимизированнаяПамять Standard_E16s_v3
Оптимизированная память 32 ОптимизированнаяПамять Standard_E32s_v3
  • Версия postgresql, регион, строка подключения, подписка и группа ресурсов для целевого гибкого сервера остаются такими же, как и те параметры исходного отдельного сервера.
  • Для отдельных серверов с хранилищем менее 20 ГиБ размер хранилища равен 32 ГиБ, так как это является минимальным ограничением хранилища в базе данных Azure для postgresql — гибкий сервер.
  • Для одиночных серверов с большим требованием к хранилищу выделяется достаточный объем хранилища, в 1,25 раза превышающий или на 25% больше объема хранилища, чем используется в одиночном сервере. Во время начальной базовой копии данных на целевом объекте выполняются несколько инструкций вставки, которые создают WALs (журналы записи вперед). Пока эти WA-адреса не архивируются, журналы используют хранилище в целевом объекте и, следовательно, предел безопасности.
  • Оба формата имени пользователя — username@server_name (один сервер) и имя пользователя (гибкий сервер) поддерживаются на перенесенном гибком сервере.
  • Оба формата строка подключения — один сервер и гибкий сервер поддерживаются на перенесенном гибком сервере.

Автоматическая миграция между основными версиями PostgreSQL

Эта миграция может включать перемещение данных из одного сервера PostgreSQL (версии 9.5, 9.6 или 10) в PostgreSQL 11 на гибком сервере. Сообщество PostgreSQL отставило от этих предыдущих версий. Чтобы обеспечить безопасность, стабильность и производительность, рекомендуется внедрить поддерживаемые версии сообщества.

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

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

  • Тестирование приложений . Проводите тщательное тестирование приложения в PostgreSQL 11. Обратите внимание на потенциальные проблемы с запросами SQL, функциями или сторонними инструментами, так как они могут вести себя по-разному или полностью завершиться ошибкой из-за изменений в новой версии.

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

Шаги после миграции

Вот информация, которую вам нужно учесть относительно этапов после автомиграции.

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

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

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

  • Параметры управления доступом (IAM) для гибкого сервера наследуются от параметров подписки. Если вы предоставили какие-либо назначения ролей, относящиеся к одному серверу, необходимо создать эти назначения ролей на гибком сервере.

  • Скопируйте параметры страницы мониторинга (оповещения, метрики и параметры диагностики) на гибкий сервер.

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

  • Если требуется высокий уровень доступности , его можно включить с нулевым временем простоя.

  • Убедитесь, что номер SKU гибкого сервера соответствует указанному в уведомлении об автоматической миграции работоспособности службы. Если это отличается, верните его к номеру SKU, указанному в уведомлении. Это важно для обеспечения точного выставления счетов.

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

Обработка правил виртуальной сети на гибком сервере

В базе данных Azure для PostgreSQL single server правило виртуальной сети (виртуальная сеть) — это подсеть, указанная в списке управления доступом сервера (ACL). Это правило позволяет одному серверу принимать обмен данными с узлов в этой подсети. Для гибкого сервера правила виртуальной сети не поддерживаются. Вместо этого гибкий сервер позволяет создавать частные конечные точки, позволяя серверу функционировать в виртуальной сети. Частная конечная точка назначает частный IP-адрес гибкому серверу, а весь трафик между виртуальной сетью и сервером безопасно перемещается через магистральную сеть Azure, устраняя необходимость использования общедоступного Интернета.

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

Долгосрочное резервное копирование хранения

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

Как проверить, запланирован ли одноузловой сервер для автоматической миграции

Чтобы определить, выбран ли отдельный сервер для автомиграции, выполните следующие действия.

  • Уведомления о работоспособности служб - На портале Azure перейдите к событиям планового обслуживания состояния службы>. Найдите события с меткой "Уведомление о запланированной автоматической миграции в базу данных Azure для PostgreSQL с одним сервером". Уведомления отправляются за 30, 14 и 7 дней до даты переноса, а также снова на этапах переноса: в процессе, завершено и за шесть дней до вывода из эксплуатации сервера Single Server.

    Примечание.

    Эти уведомления по умолчанию не попадают в папку "Входящие". Чтобы получить их по электронной почте или SMS, необходимо настроить оповещения о состоянии службы. Дополнительные сведения см. в разделе "Настройка оповещений о работоспособности службы".

  • Страница обзора Single Server - Перейдите на портал Azure к вашему экземпляру Single Server и проверьте страницу обзора. Если запланирована автомиграция, подробности можно найти здесь.

    Примечание.

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

  • Уведомления по электронной почте Azure CXP — служба "Взаимодействие с клиентами Azure" (CXP) также отправляет прямые сообщения электронной почты классическим ролям и ролям RBAC, связанным с подпиской, содержащей отдельный сервер, предоставляя сведения о предстоящих автоматических миграциях.

Часто задаваемые вопросы (FAQ)

В. Почему выполняется автоматическая миграция?

А. Ваш экземпляр сервера Azure Database for Postgresql - Single Server подлежит автоматической миграции в наше флагманское предложение Azure Database for Postgresql - Flexible Server. Эта автоматическая миграция удаляет затраты на перенос сервера вручную. Вы можете воспользоваться преимуществами гибкого сервера, включая более высокую цену и производительность, детализированный контроль над конфигурацией базы данных и пользовательскими окнами обслуживания.

В. Как выполняется автоматическая миграция? Что выполняется миграция?

А. Гибкий сервер настраивается для тесного соответствия тем же самым виртуальным ядрам и хранилищу, как у вашего одиночного сервера. Затем исходный отдельный сервер помещается в состояние только для чтения, схема и данные копируются в целевой гибкий сервер. Переключение DNS выполняется для маршрутизации всех существующих подключений к целевому серверу, и целевой гибкий сервер подключается к сети. Автоматическая миграция переносит базы данных (включая схему, данные, пользователей и роли и привилегии). Миграция проходит в режиме оффлайн, когда время простоя составляет от нескольких минут до нескольких часов в зависимости от размера рабочей нагрузки. Тесты скорости миграции см. в статье Azure PostgreSQL Migration Speed Benchmarking.

В. Как настроить или просмотреть оповещения автомиграции?

А. Ниже приведены способы настройки оповещений.

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

В. Как отказаться от запланированной автоматической миграции единственного сервера?

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

В. Какие шаги после миграции нужно выполнить, если единственный сервер использует правила виртуальной сети?

А. Правила виртуальной сети не поддерживаются на гибком сервере. См. этот раздел

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

А. Да. См. этот раздел

В. Какое имя пользователя и строка подключения будут поддерживаться для перенесенного гибкого сервера? ​​

А. Оба формата имени пользователя — username@server_name (формат одного сервера) и имя пользователя (гибкий формат сервера) поддерживаются для перенесенного гибкого сервера, поэтому их не требуется обновлять для поддержания непрерывности приложений после миграции. Кроме того, для перенесенного гибкого сервера также поддерживаются оба формата строка подключения (одиночный и гибкий формат сервера).

В. Я вижу разницу в ценах на мой потенциальный переход с сервера PostgreSQL Basic Single на сервер PostgreSQL Flexible Server.

А. Некоторые серверы могут увидеть незначительный пересмотр цен после миграции, так как минимальный предел хранилища для обоих предложений отличается (5 ГиБ на одном сервере и 32 ГиБ на гибком сервере). Стоимость хранилища для гибкого сервера значительно выше, чем один сервер. Любое увеличение цен смещается за счет повышения пропускной способности и производительности по сравнению с одним сервером. Дополнительные сведения о ценах на гибкий сервер см. в этом документе.

В. Что происходит, если я не переносю или мой сервер не переносится автоматически к 28 марта 2025 г.

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

В. Существуют ли какие-либо предупреждения при выполнении основного обновления версий (MVU) на сервере с автоматической миграцией?

А. Да, есть одна важная предостережение, о которых следует знать. Хотя обновления основных версий до любой версии PostgreSQL, которая поддерживается на гибком сервере, полностью поддерживаются для автоматически мигрированных серверов, формат строки подключения немного изменяется после успешного обновления. В частности, формат имени пользователя "username@servername" больше не будет поддерживаться после обновления. Если приложение или скрипты в настоящее время используют этот формат в строке подключения, необходимо обновить их, чтобы использовать стандартный формат: только имя пользователя. Обязательно просмотрите и обновите все затронутые строки подключения после обновления, чтобы избежать проблем с подключением.

В. Поддерживает ли автоматическая миграция ролей, прошедших проверку подлинности Microsoft Entra?

А. Да, автомиграция поддерживает миграцию ролей, аутентифицированных с помощью Microsoft Entra. После автоматической миграции сервера на гибкий сервер необходимо использовать формат entraid@servername как имя пользователя при входе в систему с идентификатором Entra ID. Более простой формат entraid в настоящее время не поддерживается.

Пример:

Если ваш идентификатор Entra ID — это abc@xyz.com, а имя сервера — server1, то имя пользователя для входа в автоматически перенесённый гибкий сервер будет abc@xyz.com@server1. Попытка войти в систему, используя abc@xyz.com в качестве имени пользователя, не будет успешной.

Это известная проблема, и корпорация Майкрософт активно работает над ее решением в будущих обновлениях.

Связанный контент