Автоматическая миграция из Базы данных Azure для Postgresql — отдельный сервер на гибкий сервер
ОБЛАСТЬ ПРИМЕНЕНИЯ: 
База данных Azure для PostgreSQL — отдельный сервер
Автоматическая миграция из База данных Azure для PostgreSQL — единый сервер на гибкий сервер — это миграция, инициируемая службой, которая происходит во время запланированного периода простоя для одного сервера, отдельно от периода исправления или обслуживания. Служба определяет подходящие серверы и отправляет предварительные уведомления с подробными инструкциями по процессу автомиграции. При необходимости можно просмотреть и настроить расписание миграции или отправить запрос на поддержку, чтобы отказаться от автоматической миграции для серверов.
Автоматическая миграция использует службу миграции Azure PostgreSQL для обеспечения устойчивой автономной миграции во время запланированного периода миграции. Время простоя зависит от характеристик рабочей нагрузки, при этом более крупные рабочие нагрузки могут потребовать до 20 минут. Тесты скорости миграции см. в статье Azure PostgreSQL Migration Speed Benchmarking. Эта миграция устраняет необходимость ручной миграции сервера, что позволяет воспользоваться функциями гибкого сервера после миграции, включая повышение производительности цен, детализированное управление конфигурацией базы данных и пользовательские периоды обслуживания.
Примечание.
Служба автомиграции выбирает один сервер для миграции на основе следующих критериев:
- Отдельный сервер версии 11
- Серверы без сложных функций, таких как CMK, идентификатор Microsoft Entra, реплика чтения и частная конечная точка
- Размер данных <= 10 ГБ
- Общедоступный доступ включен
Процесс автомиграции
Процесс автомиграции включает несколько ключевых этапов:
Создание гибкого сервера — гибкий сервер создается для соответствия производительности и стоимости номера SKU одного сервера. Он наследует все правила брандмауэра от исходного отдельного сервера.
Миграция данных — миграция данных происходит во время указанного окна миграции, обычно запланированного вне рабочих часов для региона размещения сервера (если окно выбрано службой). Исходный отдельный сервер имеет значение только для чтения, а все данные, схемы, роли пользователей, привилегии и владение объектами базы данных переносятся на гибкий сервер.
Параметр DNS. После миграции данных выполняется переключатель DNS, что позволяет существующему отдельному серверу строка подключения легко подключаться к новому гибкому серверу. На перенесенном гибком сервере поддерживаются форматы отдельных и гибких серверов строка подключения, а также форматы имен пользователей (username@server_name и имя пользователя).
Гибкая видимость сервера. После успешной миграции данных и переключения DNS новый гибкий сервер отображается в подписке и может управляться с помощью портал Azure или ИНТЕРФЕЙСА командной строки.
Обновленные строки подключения к одному серверу. Обновленные строка подключения для устаревшего отдельного сервера отправляются с помощью уведомлений о работоспособности служб на портал Azure. Они также доступны на странице портала с одним сервером в разделе "Параметры "> Строки подключения".
Удаление одного сервера — одиночный сервер сохраняется в течение семи дней после миграции перед удалением.
Назначение отдельных серверов для автомиграции
Процесс выдвижения предназначен для пользователей, которые хотят добровольно быстро отслеживать миграцию на гибкий сервер. Если вы владеете рабочей нагрузкой одного сервера, теперь вы можете назначить себя (если она еще не запланирована службой) для автоматической миграции. Отправьте сведения о сервере с помощью этой формы.
Как проверить, запланирован ли отдельный сервер для автомиграции
Чтобы определить, выбран ли отдельный сервер для автомиграции, выполните следующие действия.
- Уведомления о работоспособности > служб . В портал Azure перейдите к событиям планового обслуживания службы. Найдите события с меткой "Уведомление о запланированной автоматической миграции на База данных Azure для PostgreSQL отдельный сервер". Уведомления отправляются 30, 14 и 7 дней до даты миграции и снова во время этапов миграции: выполняется, завершено и шесть дней до вывода одного сервера.
Примечание.
Эти уведомления по умолчанию не приземлились в папке "Входящие". Чтобы получить их по электронной почте или SMS, необходимо настроить оповещения работоспособности служб, выполнив действия, описанные ниже.
- Страница обзора одного сервера. Перейдите к экземпляру одного сервера в портал Azure и проверьте страницу обзора. Если оно запланировано для автомиграции, вы найдете здесь подробные сведения, включая возможность отложить миграцию на один месяц в течение одного месяца или перепланировать в течение текущего месяца.
Примечание.
Расписание миграции будет заблокировано через 7 дней до запланированного периода миграции, в течение которого вы не сможете перепланировать расписание.
- Azure CXP Уведомления по электронной почте — Интерфейс клиента Azure (CXP) также отправляет прямые сообщения электронной почты классическим ролям и ролям RBAC, связанным с подпиской, содержащей отдельный сервер, предоставляя сведения о предстоящих автоматической миграции.
Проверка готовности для автомиграции
Проверьте следующие предварительные требования, чтобы обеспечить успешную автоматическую настройку:
- Экземпляр одного сервера должен находиться в состоянии готовности во время запланированного периода миграции для автоматической миграции.
- Для одного экземпляра сервера с включенным SSL убедитесь, что у вас есть все сертификаты (DigiCertGlobalRootG2 Root CA и DigiCertGlobalRootCA Root CA) доступны в доверенном корневом хранилище. Кроме того, если у вас есть сертификат, закрепленный на строка подключения создайте объединенный сертификат ЦС со всеми тремя сертификатами до запланированной автоматической миграции, чтобы обеспечить непрерывность бизнес-процессов после миграции.
- Если в исходной базе данных Azure для postgresql single Server есть имена правил брандмауэра, превышающие 80 символов, переименуйте их, чтобы длина имени была меньше 80 символов. (Длина имени правила брандмауэра, поддерживаемая на гибком сервере, составляет 80 символов, в то время как на одном сервере разрешенная длина составляет 128 символов.)
Как подготовлен целевой гибкий сервер 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 (один сервер) и имя пользователя (гибкий сервер) поддерживаются на перенесенном гибком сервере.
- Оба формата строка подключения — один сервер и гибкий сервер поддерживаются на перенесенном гибком сервере.
Шаги после миграции
Ниже приведены сведения, которые необходимо знать после автомиграции:
- Параметры сервера в гибком сервере настраиваются на стандарты сообщества. Если вы хотите сохранить те же значения параметров сервера, что и отдельный сервер, вы можете войти в систему с помощью PowerShell и запустить скрипт здесь , чтобы скопировать значения параметров.
- Чтобы включить аналитику запросов perf, необходимо включить хранилище запросов на гибком сервере, который не включен по умолчанию.
- Если требуется высокий уровень доступности, его можно включить с нулевым временем простоя .
Обработка правил виртуальной сети на гибком сервере
В База данных Azure для PostgreSQL отдельном сервере правило виртуальной сети — это подсеть, указанная в списке управления доступом сервера (ACL). Это правило позволяет одному серверу принимать обмен данными с узлов в этой подсети. Для гибкого сервера правила виртуальной сети не поддерживаются. Вместо этого гибкий сервер позволяет создавать частные конечные точки, позволяя серверу функционировать в виртуальной сети. Частная конечная точка назначает частный IP-адрес гибкому серверу, а весь трафик между виртуальной сетью и сервером безопасно перемещается через магистральную сеть Azure, устраняя необходимость использования общедоступного Интернета.
После миграции необходимо добавить частную конечную точку на гибкий сервер для всех подсетей, ранее охваченных правилами виртуальной сети на одном сервере. Этот процесс можно выполнить с помощью портал Azure или Azure CLI. После завершения этого шага сетевое подключение останется неизменным на гибком сервере после миграции с одного сервера.
Часто задаваемые вопросы (FAQ)
В. Почему выполняется автоматическая миграция?
А. База данных Azure для Postgresql — отдельный экземпляр сервера имеет право на автоматическую миграцию в наш флагманский предложение Базы данных Azure для Postgresql — гибкий сервер. Эта автоматическая миграция приведет к удалению дополнительных расходов на перенос сервера вручную. Вы можете воспользоваться преимуществами гибкого сервера, включая более высокую цену и производительность, детализированный контроль над конфигурацией базы данных и пользовательскими окнами обслуживания.
В. Как выполняется автоматическая миграция? Что выполняется миграция?
А. Гибкий сервер подготавливается для тесного соответствия тем же виртуальным ядрам и хранилищу, что и одиночный сервер. Затем исходный отдельный сервер помещается в состояние только для чтения, схема и данные копируются в целевой гибкий сервер. Переключение DNS выполняется для маршрутизации всех существующих подключений к целевому серверу, и целевой гибкий сервер подключается к сети. Автоматическая миграция переносит базы данных (включая схему, данные, пользователей и роли и привилегии). Миграция находится в автономном режиме, когда время простоя составляет до 20 минут.
В. Как настроить или просмотреть оповещения автомиграции?
А. Ниже приведены способы настройки оповещений.
- Настройте оповещения о работоспособности службы, чтобы получать уведомления о расписании автоматической миграции и ход выполнения с помощью электронной почты или SMS, выполнив следующие действия.
- Проверьте уведомление об автомиграции на портал Azure, выполнив следующие действия.
В. Как отложить запланированную миграцию отдельного сервера?
А. Вы можете просмотреть расписание миграции, перейдя на страницу обзора экземпляра одного сервера. Если вы хотите отложить миграцию, вы можете отложить на месяц больше всего, перейдя на страницу обзора одного экземпляра сервера на портал Azure. Вы можете перепланировать миграцию, выбрав другое окно миграции в течение месяца. Сведения о миграции будут заблокированы семь дней до запланированного окна миграции, после которого не удается перепланировать. Эта автоматическая миграция может быть отложена ежемесячно до 30 марта 2025 года.
В. Как отказаться от запланированной автоматической обработки одного сервера?
А. Если вы хотите отказаться от автомиграции, вы можете вызвать запрос в службу поддержки для этой цели.
В. Какое имя пользователя и строка подключения будут поддерживаться для перенесенного гибкого сервера?
А. Оба формата имени пользователя — username@server_name (формат одного сервера) и имя пользователя (гибкий формат сервера) поддерживаются для перенесенного гибкого сервера, поэтому их не требуется обновлять для поддержания непрерывности приложений после миграции. Кроме того, для перенесенного гибкого сервера также поддерживаются оба формата строка подключения (одиночный и гибкий формат сервера).
В. Я вижу разницу в ценах на мой потенциальный переход с postgresql Basic Single Server на гибкий сервер postgresql??
А. Некоторые серверы могут увидеть незначительный пересмотр цен после миграции, так как минимальный предел хранилища для обоих предложений отличается (5 ГиБ на одном сервере и 32 ГиБ на гибком сервере). Стоимость хранилища для гибкого сервера значительно выше, чем один сервер. Любое увеличение цен смещается за счет повышения пропускной способности и производительности по сравнению с одним сервером. Дополнительные сведения о ценах на гибкий сервер см. в этом документе .