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

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

  • Статья

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

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

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

Примечание.

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

  • Серверы без сложных функций, таких как CMK, Microsoft Entra ID, реплика чтения и частная конечная точка.
  • Размер данных <= 100 ГБ
  • Общедоступный доступ включен

Примечание.

В случае использования любой из этих функций, таких как CMK, идентификатор Microsoft Entra ID, реплика чтения и частная конечная точка, потребуется дополнительное планирование. Укажите подробности в приведенной ниже форме номинации, и мы будем связаться с вами.

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

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

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

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

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

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

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

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

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

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

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

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

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

  • Гибкая видимость сервера. После успешной миграции данных и переключения 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 MemoryOptimized Standard_E2s_v3
С оптимизацией для операций в памяти 4 MemoryOptimized Standard_E4s_v3
С оптимизацией для операций в памяти 8 MemoryOptimized Standard_E8s_v3
С оптимизацией для операций в памяти 16 MemoryOptimized Standard_E16s_v3
С оптимизацией для операций в памяти 32 MemoryOptimized 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 отдельном сервере правило виртуальной сети — это подсеть, указанная в списке управления доступом сервера (ACL). Это правило позволяет одному серверу принимать обмен данными с узлов в этой подсети. Для гибкого сервера правила виртуальной сети не поддерживаются. Вместо этого гибкий сервер поддерживает создание частных конечных точек, чтобы функционировать в виртуальной сети. Частная конечная точка назначает частный IP-адрес гибкому серверу, а весь трафик между виртуальной сетью и сервером безопасно перемещается через магистральную сеть Azure, устраняя необходимость использования общедоступного Интернета.

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

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

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

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

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

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

    Примечание.

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

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

    Примечание.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

В. Я вижу разницу в ценах на мой потенциальный переход с postgresql Basic Single Server на гибкий сервер postgresql??

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

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

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

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