Что происходит с База данных Azure для PostgreSQL — отдельный сервер после объявления о выходе на пенсию?
ОБЛАСТЬ ПРИМЕНЕНИЯ: 
База данных Azure для PostgreSQL — отдельный сервер
**База данных Azure для PostgreSQL — отдельный сервер находится на пути выхода на пенсию и планируется выйти из эксплуатации к 28 марта 2025 года.
База данных Azure для PostgreSQL — единый сервер, как правило, стал доступен в 2018 году. Учитывая отзывы клиентов и новые улучшения в вычислениях, доступности, масштабируемости и производительности базы данных Azure, предложение с одним сервером должно быть прекращено и обновлено с помощью новой архитектуры. База данных Azure для PostgreSQL . Гибкий сервер — это следующее поколение службы и предоставляет лучшую платформу базы данных с открытым кодом Azure.
В рамках этого выхода на пенсию мы больше не будем поддерживать создание новых экземпляров одного сервера с портал Azure начала 30 ноября 2023 года. Однако если вам нужно создать экземпляры одного сервера для удовлетворения потребностей непрерывности бизнес-процессов, вы можете продолжать использовать Azure CLI до марта 2025 года.
Если в настоящее время у вас есть База данных Azure для PostgreSQL — односерверная служба, на котором размещены рабочие серверы, мы рады сообщить вам, что вы можете перенести База данных Azure для PostgreSQL - один сервер на База данных Azure для PostgreSQL — гибкий сервер.
База данных Azure для PostgreSQL . Гибкий сервер — это полностью управляемая служба базы данных, готовая к работе с рабочей средой, предназначенная для более детального управления и гибкости функций управления базами данных и параметров конфигурации. Дополнительные сведения об этом см. в База данных Azure для PostgreSQL — гибкий сервер.
Миграция с База данных Azure для PostgreSQL — отдельный сервер на База данных Azure для PostgreSQL — гибкий сервер
Узнайте, как перейти с База данных Azure для PostgreSQL — отдельный сервер на База данных Azure для PostgreSQL — гибкий сервер с помощью службы миграции PostgreSQL.
Часто задаваемые вопросы (FAQ)
В. Почему База данных Azure для PostgreSQL— отдельный сервер отменяется?
А. База данных Azure для PostgreSQL — единый сервер, как правило, стал доступен в 2018 году. Учитывая отзывы клиентов и новые улучшения в вычислениях, доступности, масштабируемости и производительности базы данных Azure, предложение с одним сервером должно быть прекращено и обновлено с помощью новой архитектуры. База данных Azure для PostgreSQL . Гибкий сервер — это следующее поколение службы и предоставляет лучшую платформу базы данных с открытым кодом Azure.
В. Почему мне предлагается перейти на База данных Azure для PostgreSQL — гибкий сервер?
A. База данных Azure для PostgreSQL. Гибкий сервер — это оптимальная платформа для выполнения всех рабочих нагрузок PostgreSQL с открытым исходным кодом в Azure. База данных Azure для PostgreSQL . Гибкий сервер экономичен, обеспечивает более высокую производительность на всех уровнях служб и предоставляет более удобные способы управления затратами на более дешевое и быстрое аварийное восстановление. К другим улучшениям гибкого сервера относятся следующие:
- Поддержка Postgres версии 11 и более поздних версий, а также встроенных улучшений безопасности
- Улучшенная производительность цен с поддержкой высокоуровневых вычислительных параметров.
- Улучшено время простоя, настроив горячий режим ожидания в той же или другой зоне доступности и управляемых пользователем периодах обслуживания.
- Упрощенный интерфейс разработчика для высокопроизводительных рабочих нагрузок данных.
В. Как скоро необходимо перенести отдельный сервер на гибкий сервер?
А. База данных Azure для PostgreSQL — единый сервер планируется выйти на пенсию к 28 марта 2025 г., поэтому настоятельно рекомендуется перенести отдельный сервер на гибкий сервер в самый ранний момент, чтобы обеспечить достаточное время для выполнения жизненного цикла миграции и использования преимуществ, предлагаемых гибким сервером.
В. Что происходит с существующими База данных Azure для PostgreSQL — экземпляры одного сервера?
А. Существующие База данных Azure для PostgreSQL — рабочие нагрузки с одним сервером поддерживаются до марта 2025 г.
В. Можно ли создать новую версию 11 База данных Azure для PostgreSQL — отдельный сервер после даты EOL сообщества в ноябре 2023 г.?
А. Начиная с 30 ноября 2023 г. вы больше не сможете создавать новые экземпляры одного сервера для PostgreSQL версии 11 до портал Azure. Однако вы по-прежнему можете сделать их через CLI до марта 2025 года. Мы поддерживаем отдельные серверы с помощью политики поддержки управления версиями. Лучше всего начать миграцию на База данных Azure для PostgreSQL — гибкий сервер немедленно.
В. Можно ли продолжать работу База данных Azure для PostgreSQL — один сервер за пределами даты заката 28 марта 2025 г.?
А. Мы планируем поддерживать единый сервер до даты окончания 28 марта 2025 г., и мы настоятельно рекомендуем начать планирование миграции как можно скорее. Мы планируем завершить поддержку развертываний с одним сервером на закате 28 марта 2025 г.
В. Что делать после объявления о прекращении поддержки отдельного сервера, если мне по-прежнему нужно создать новый отдельный сервер для удовлетворения бизнес-потребностей?
А. Мы не останавливаем возможность немедленно создавать новые отдельные серверы, поэтому вы можете продолжать создавать новые отдельные серверы с помощью ИНТЕРФЕЙСА командной строки для удовлетворения всех бизнес-потребностей всех версий PostgreSQL, поддерживаемых в База данных Azure для PostgreSQL — отдельный сервер. Мы настоятельно рекомендуем вам изучить гибкий сервер и узнать, будет ли это соответствовать вашим потребностям. Не стесняйтесь связаться с нами при необходимости, чтобы мы могли помочь вам и предложить лучший путь вперед.
В. Существуют ли дополнительные затраты, связанные с выполнением миграции?
А. Вы оплачиваете целевой гибкий сервер и исходный отдельный сервер во время миграции. Конфигурация и вычисления целевого гибкого сервера определяют дополнительные затраты(см . дополнительные сведения о ценах ). После завершения успешной миграции исходный сервер вы платите только за гибкий сервер. Использование односерверного сервера к гибкой службе миграции сервера не требует дополнительных затрат. Если у вас есть вопросы или проблемы с затратами на перенос одного сервера на гибкий сервер, обратитесь к представителю учетной записи Майкрософт.
В. Будет ли затронуто выставление счетов путем запуска База данных Azure для PostgreSQL — гибкий сервер вместо База данных Azure для PostgreSQL — отдельный сервер?
А. Выставление счетов должно быть сравнимо, если выбрать аналогичную конфигурацию База данных Azure для PostgreSQL — отдельный сервер. Однако если выбрать ту же зону или избыточность зоны с высоким уровнем доступности для целевого гибкого сервера, счет будет выше, чем на одном сервере. Для обеспечения высокой доступности, избыточного между зонами или зонами, требуется создать дополнительный резервный сервер горячего резервного копирования и хранить избыточные данные резервного копирования, следовательно, дополнительные затраты на второй сервер. Эта архитектура позволяет сократить время простоя во время незапланированных прекращений работы и планового обслуживания. Как правило, гибкий сервер обеспечивает более высокую производительность цен, однако это зависит от рабочей нагрузки.
В. Возникает ли простой при переносе базы данных Azure из PostgreSQL на гибкий сервер?
А. Служба миграции PostgreSQL поддерживает автономные и онлайн-миграции. Автономная миграция требует простоя приложений во время процесса миграции. Миграция через Интернет помогает перенести базы данных с ограниченным временем простоя, но с несколькими ограничениями. Дополнительные сведения см. в статье PostgreSQL Migration Service — База данных Azure для PostgreSQL отдельный сервер на гибкий сервер.
Время простоя зависит от нескольких факторов, включая количество и размер баз данных, количество таблиц в каждой базе данных, количество индексов и распределение данных между таблицами. Он также зависит от SKU исходного и целевого сервера, а также операций ввода-вывода в секунду, доступных на исходном и целевом сервере.
Учитывая множество факторов, участвующих в миграции, оптимальный подход к оценке простоя приложения — попробовать миграцию на сервере PITR, восстановленном с основного сервера, чтобы спланировать миграцию рабочей среды.
Автономные миграции являются менее сложными и имеют мало шансов на сбой. Рекомендуется перенести рабочие нагрузки с окнами служб с одного сервера на гибкий сервер. Миграция через Интернет может использоваться для рабочих сред с низкой отказоустойчивостью простоя.
В. Будут ли будущие обновления на одном сервере для поддержки последних версий PostgreSQL?
А. Рекомендуется перейти на гибкий сервер, если необходимо запустить последнюю версию ядра PostgreSQL. Мы продолжаем развертывать дополнительные версии, выпущенные сообществом для Postgres версии 11 до тех пор, пока она не будет прекращена сообществом в ноябре 2023 года.
Примечание.
Мы расширяем поддержку Postgres версии 11 после даты выхода на пенсию сообщества и будем поддерживать PostgreSQL версии 11 на одном сервере и гибком сервере, чтобы упростить этот переход. Рассмотрите возможность миграции на гибкий сервер, чтобы использовать преимущества последних версий подсистемы Postgres.
В. Как доступность гибкого сервера 99,99 % отличается от единого сервера?
А. Гибкое развертывание, избыточное между зонами сервера, обеспечивает доступность 99,99 % с устойчивостью зонального уровня, а отдельный сервер обеспечивает доступность 99,99 %, но без зональной устойчивости. Архитектура высокого уровня доступности гибкого сервера развертывает резервный сервер с избыточными вычислительными ресурсами и хранилищем (с данными каждого сайта, хранящимися в 3x копиях). Архитектура высокого уровня доступности одного сервера не имеет пассивного горячего резервирования, чтобы помочь восстановиться после зональных сбоев. Гибкая архитектура высокого уровня доступности сервера сокращает время простоя во время незапланированных сбоев и планового обслуживания.
В. Одиночный сервер развертывается в регионе, который не поддерживает гибкий сервер. Как выполнить миграцию?
А. Мы близко к региональному четности с одним сервером. Это регионы без присутствия гибкого сервера.
- Восточная часть Китая (CE и CE2),
- Китай Север (CN и CN2)
- Индия (запад)
- Центральная Швеция
Мы рекомендуем перейти на CN3/CE3, Центральную Индию, Центральную Швецию и Южную Швецию. В. У меня есть приватный канал, настроенный для одного сервера. Как выполнить миграцию
А. поддержка Приватный канал теперь доступна на гибком сервере. Сервер среды выполнения можно использовать для перехода на гибкий сервер с поддержкой приватного канала. Дополнительные сведения см. в разделе "Сервер среды выполнения" — База данных Azure для PostgreSQL отдельный сервер на гибкий сервер.
В. Существует ли возможность отката одного сервера к миграции гибкого сервера?
А. Вы можете выполнить любое количество тестовых миграций, проверить успешность миграции и выполнить окончательную миграцию после готовности. Тестовые миграции не влияют на один источник сервера, который остается в эксплуатации, пока не будет перенесен и изменены строка подключения, чтобы указать на гибкий сервер. Если во время тестовой миграции возникают ошибки, можно отложить окончательную миграцию и сохранить исходный сервер. После устранения ошибок можно повторить попытку окончательной миграции. После выполнения окончательной миграции на гибкий сервер и открытия его для рабочей рабочей нагрузки вы потеряете возможность вернуться к одному серверу без потери данных.
В. Как перенести базу данных (> 1TB)
A. Служба миграции PostgreSQL может перенести базы данных всех размеров с одного сервера на гибкий сервер. Служба миграции не имеет ограничений относительно размера баз данных.
В. Поддерживается ли миграция между регионами?
О. Да.
В. Поддерживается ли миграция между подписками?
А. Служба миграции PostgreSQL поддерживает миграцию между подписками.
В. Поддерживается ли подписка между группами ресурсов?
А. Служба миграции PostgreSQL поддерживает миграцию между группами ресурсов.
В. Поддерживаются ли разные версии?
А. Служба миграции PostgreSQL поддерживает переход с более низкой версии PostgreSQL (PG 9.5 и выше) на любую более позднюю версию. Как всегда, необходимо проверить совместимость приложений с более высокими версиями PostgreSQL.
Служба миграции PostgreSQL
Служба миграцииPostgreSQL — это мощная служба, которая позволяет легко перенести базу данных Сервера PostgreSQL с одного сервера на гибкий сервер. С помощью этой службы вы можете легко переместить базу данных с локального сервера или виртуальной машины на гибкий сервер в облаке, что позволяет воспользоваться преимуществами масштабируемости и гибкости облачных вычислений.
В. Какие компоненты данных, схемы и метаданных переносятся в ходе миграции?
А. Служба миграции PostgreSQL переносит схему, данные и метаданные из источника в место назначения. Все следующие компоненты данных, схемы и метаданных переносятся в рамках миграции базы данных:
Миграция данных
- Все таблицы из всех баз данных и схем.
Миграция схемы:
- Именование
- Первичный ключ
- Тип данных
- Порядковое положение
- Default value
- Допускает значения NULL
- Атрибуты автоматического увеличения
- Вторичные индексы
Миграция метаданных:
- Хранимые процедуры
- Функции
- Триггеры
- Представления
- Ограничения внешнего ключа
В. Какова разница между автономной и онлайн-миграцией?
А. При автономной миграции время простоя приложения начинается при начале миграции. При использовании миграции по сети простой приложения ограничен только временем, требуемым для переключения в конце миграции. Однако он использует механизм логической репликации, который имеет несколько ограничений.
В следующей таблице представлен обзор автономных и сетевых параметров.
| Вариант | Плюсы | Минусы | Рекомендуется для |
|---|---|---|---|
| Offline | — Простой, простой и менее сложный для выполнения. - Очень мало шансов на неудачу. — нет ограничений относительно объектов базы данных, которые она может обрабатывать |
Время простоя приложений. | — Лучше всего подходит для сценариев, когда простота и высокая скорость успеха являются важными. — Идеально подходит для сценариев, в которых база данных может быть автономной, не влияя на бизнес-операции. — Подходит для баз данных, когда процесс миграции может быть завершен в течение запланированного периода обслуживания. |
| Миграция по сети | — очень минимальное время простоя приложения. — идеально подходит для больших баз данных и клиентов с ограниченным временем простоя. |
— Репликация, используемая в оперативной миграции, имеет несколько ограничений (например, первичные ключи, необходимые во всех таблицах). — сложный и сложный процесс выполнения, чем автономная миграция. — больше шансов на сбой из-за сложности миграции. — Существует влияние на хранилище и вычисления исходного экземпляра, если миграция выполняется в течение длительного времени. Влияние должно внимательно отслеживаться во время миграции. |
- Лучше всего подходит для предприятий, где непрерывность является критически важной и простоем должна быть минимальной. — Рекомендуется для баз данных, когда процесс миграции должен происходить без прерывания текущих операций. |
В. Существуют ли рекомендации по оптимизации производительности миграции одного сервера на гибкий сервер?
О. Да. Чтобы ускорить миграцию, выберите более высокий номер SKU для гибкого сервера. Выберите минимум 4VCore или более поздней версии, чтобы быстро завершить миграцию. Номер SKU всегда можно изменить в соответствии с требованиями приложения после миграции. Ознакомьтесь с дополнительными рекомендациями.
В. Сколько времени выполняется автономная миграция с одного сервера на гибкий сервер с помощью службы миграции?
А. В следующей таблице показано время, затраченное на выполнение автономных миграций для баз данных различных размеров с помощью службы миграции PostgreSQL. Миграция была выполнена с помощью гибкого сервера с номером SKU:
Standard_D4ds_v4(4 ядра, 16 ГБ памяти и 500 операций ввода-вывода в секунду)
| Размер базы данных | Время (HH:MM) |
|---|---|
| 1 ГБ | 00:01 |
| 5 ГБ | 00:03 |
| 10 ГБ | 00:08 |
| 50 ГБ | 00:35 |
| 100 ГБ | 01:00 |
| 500 ГБ | 04:00 |
| 1,000 ГБ | 07:00 |
Примечание.
Числа, указанные выше, составляют приблизительное время, затраченное на завершение миграции. Чтобы получить точное время, необходимое для миграции на сервер, настоятельно рекомендуется использовать PITR (восстановление на определенный момент времени) отдельного сервера и переносить его с помощью службы миграции PostgreSQL.
В. Сколько времени выполняется миграция через Интернет с одного сервера на гибкий сервер с помощью службы миграции?
А. Миграция через Интернет включает в себя следующие действия.
- Начальная копия баз данных
- Изменение записи данных — повторная передача всех транзакций в источнике во время шага 1 на целевой объект.
Время, затраченное на шаге 1, совпадает с автономными миграциями (см. предыдущий вопрос).
Время, затраченное на шаг 2, зависит от транзакций, происходящих в источнике. Если это рабочая нагрузка с интенсивной записью, она дольше.
В. Существует ли какая-либо поддержка, предлагаемая корпорацией Майкрософт для перехода с одного сервера на гибкий сервер?
О. Да. Помимо непрерывного обновления службы миграции, мы сотрудничаем с внутренними группами партнеров, которые могут взаимодействовать с вами в процессе миграции. Чтобы получить дополнительные сведения, обратитесь к представителю учетной записи.
В. Может ли корпорация Майкрософт автоматически перенести мой отдельный сервер на гибкий сервер? О. Да. Вы можете назначить серверы для автоматической миграции. Дополнительные сведения см. здесь и номинировать серверы для автомиграции.
Дополнительная поддержка
В. У меня есть дополнительные вопросы о выходе на пенсию.
А. Дополнительные сведения можно получить несколькими способами.
Ответы от экспертов сообщества в Microsoft Q&A.
Если у вас есть план поддержки и вам нужна техническая помощь, создайте запрос на поддержку: — Для сводки введите описание проблемы. — Для типа проблемы выберите Technical. — Для подписки выберите подписку. — Для службы выберите "Мои службы". — Для типа службы выберите База данных Azure для PostgreSQL один сервер. — Для ресурса выберите ресурс. — Для типа проблемы выберите "Миграция в базу данных Azure для PostgreSQL". — Для подтипа проблемы выберите переход с одного на гибкий сервер.
Предупреждение
Эта статья не подходит для База данных Azure для PostgreSQL — гибкие пользователи сервера. Это для База данных Azure для PostgreSQL — клиентов с одним сервером, которым необходимо обновить до База данных Azure для PostgreSQL — гибкий сервер.
Мы знаем, что миграция служб может быть разочарована, и мы извиняемся заранее за любые неудобства, что может привести к вам. Вы можете выбрать оптимальный сценарий для вас и вашей среды.