Что происходит с База данных Azure для PostgreSQL — отдельный сервер после объявления о выходе на пенсию?
Область применения:
отдельный сервер Базы данных Azure для PostgreSQL
База данных Azure для PostgreSQL — отдельный сервер находится на пути выхода на пенсию и планируется выйти на пенсию 28 марта 2025 года.
База данных Azure для PostgreSQL — единый сервер, как правило, стал доступен в 2018 году. Учитывая отзывы клиентов и новые улучшения в вычислениях, доступности, масштабируемости и производительности в ландшафте базы данных Azure, предложение с одним сервером должно быть прекращено и обновлено с помощью новой архитектуры. База данных Azure для PostgreSQL. Гибкий сервер — это следующее поколение службы и обеспечивает лучшую платформу базы данных с открытым кодом Azure.
В рамках этого выхода на пенсию мы больше не поддерживаем создание новых экземпляров одного сервера с портал Azure начала 30 ноября 2023 года. Если необходимо создать экземпляры одного сервера для удовлетворения потребностей непрерывности бизнес-процессов, вы можете продолжать использовать Azure CLI и шаблон ARM. Однако по состоянию на март 2025 года эти методы больше не будут использоваться.
Если в настоящее время у вас есть База данных Azure для PostgreSQL — односерверная служба, на котором размещены рабочие серверы, мы рады сообщить вам, что вы можете перенести База данных Azure для PostgreSQL - один сервер на База данных Azure для PostgreSQL — гибкий сервер.
База данных Azure для PostgreSQL . Гибкий сервер — это полностью управляемая служба базы данных, готовая к работе с рабочей средой, предназначенная для более детального управления и гибкости функций управления базами данных и параметров конфигурации. Дополнительные сведения о База данных Azure для PostgreSQL — гибкий сервер см. в База данных Azure для PostgreSQL — гибкий сервер.
Миграция с База данных Azure для PostgreSQL — отдельный сервер на База данных Azure для PostgreSQL — гибкий сервер
Узнайте, как перейти с База данных Azure для PostgreSQL — отдельный сервер на База данных Azure для PostgreSQL — гибкий сервер с помощью средства миграции с одним сервером на гибкий сервер.
Часто задаваемые вопросы (FAQ)
В. Почему База данных Azure для PostgreSQL— отдельный сервер отменяется?
А. База данных Azure для PostgreSQL — единый сервер, как правило, стал доступен в 2018 году. Учитывая отзывы клиентов и новые улучшения в вычислениях, доступности, масштабируемости и производительности в ландшафте базы данных Azure, предложение с одним сервером должно быть прекращено и обновлено с помощью новой архитектуры. База данных Azure для PostgreSQL. Гибкий сервер — это следующее поколение службы и обеспечивает лучшую платформу базы данных с открытым кодом Azure.
В. Почему мне предлагается перейти на База данных Azure для PostgreSQL — гибкий сервер?
А.База данных 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 до ноября 2024 года. Мы будем продолжать поддерживать отдельные серверы с помощью нашей политики поддержки управления версиями. Лучше всего начать миграцию на База данных Azure для PostgreSQL — гибкий сервер немедленно.
В. Можно ли продолжать работу База данных Azure для PostgreSQL — один сервер за пределами даты заката 28 марта 2025 г.?
А. Мы планируем поддерживать единый сервер до даты окончания 28 марта 2025 г., и мы настоятельно рекомендуем начать планирование миграции как можно скорее. Мы планируем завершить поддержку развертываний с одним сервером на закате данных 28 марта 2025 г.
В. Что делать после объявления о прекращении поддержки отдельного сервера, если мне по-прежнему нужно создать новый отдельный сервер для удовлетворения бизнес-потребностей?
А. Мы не останавливаем возможность немедленно создавать новые отдельные серверы, поэтому вы можете продолжать создавать новые отдельные серверы с помощью ИНТЕРФЕЙСА командной строки для удовлетворения всех бизнес-потребностей всех версий PostgreSQL, поддерживаемых в База данных Azure для PostgreSQL — отдельный сервер. Мы настоятельно рекомендуем вам изучить гибкий сервер и узнать, будет ли это соответствовать вашим потребностям. Не стесняйтесь связаться с нами при необходимости, чтобы мы могли помочь вам и предложить лучший путь вперед.
В. Существуют ли дополнительные затраты, связанные с выполнением миграции?
А. Вы оплачиваете целевой гибкий сервер и исходный отдельный сервер во время миграции. Конфигурация и вычисления целевого гибкого сервера определяют дополнительные затраты(см . дополнительные сведения о ценах ). После завершения успешной миграции исходный сервер вы платите только за гибкий сервер. Использование средства миграции с одним сервером на гибкий сервер не стоит дополнительно. Если у вас есть вопросы или проблемы с затратами на перенос одного сервера на гибкий сервер, обратитесь к представителю учетной записи Майкрософт.
В. Будет ли затронуто выставление счетов путем запуска База данных Azure для PostgreSQL — гибкий сервер вместо База данных Azure для PostgreSQL — отдельный сервер?
А. Выставление счетов должно быть сравнимо, если выбрать аналогичную конфигурацию База данных Azure для PostgreSQL — отдельный сервер. Однако если выбрать ту же зону или избыточность зоны с высоким уровнем доступности для целевого гибкого сервера, счет будет выше, чем на одном сервере. Для обеспечения высокой доступности, избыточного между зонами или зонами, требуется создать дополнительный резервный сервер горячего резервного копирования и хранить избыточные данные резервного копирования, следовательно, дополнительные затраты на второй сервер. Эта архитектура позволяет сократить время простоя во время незапланированных прекращений работы и планового обслуживания. Как правило, гибкий сервер обеспечивает более высокую ценовую производительность, однако это зависит от рабочей нагрузки.
В. Возникает ли простой при переносе базы данных Azure из PostgreSQL на гибкий сервер?
А. В настоящее время средство миграции с одним сервером на гибкий сервер поддерживает только автономные миграции. Автономная миграция требует простоя приложений во время процесса миграции. Дополнительные сведения см. в разделе "Средство миграции" — База данных 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, Центральная Индия, Центральная Индия, Центральная Швеция и Южная Швеция. В. У меня есть приватный канал, настроенный для одного сервера, и эта функция в настоящее время не поддерживается в гибком сервере. Как выполнить миграцию
А. Поддержка гибкого сервера для приватного канала является нашим наивысшим приоритетом и стратегией развития. Эта функция планируется запустить в Q4 2023. Еще одним вариантом является перенос на виртуальный сеть, внедренный гибкий сервер.
В. Существует ли возможность отката одного сервера к миграции гибкого сервера?
А. Вы можете выполнить любое количество тестовых миграций, проверить успешность миграции и выполнить окончательную миграцию после готовности. Тестовые миграции не влияют на один источник сервера, который остается в эксплуатации, пока не будет выполняться миграция. Если во время тестовой миграции возникают ошибки, можно отложить окончательную миграцию и сохранить исходный сервер. После устранения ошибок можно повторить попытку окончательной миграции. После выполнения окончательной миграции на гибкий сервер и открытия его для рабочей рабочей нагрузки вы потеряете возможность вернуться на один сервер без потери данных.
В. Как перенести базу данных (>1 ТБ)
А.Средство миграции с одного сервера на гибкий сервер может перенести базы данных всех размеров с одного сервера на гибкий сервер. Новая версия средства не имеет ограничений относительно размера баз данных.
В. Поддерживается ли миграция между регионами?
А. В настоящее время средство миграции с одним сервером на гибкий сервер не поддерживает миграцию между регионами. Она поддерживается в последующий момент времени. Вы можете использовать pg_dump/pg_restore для выполнения миграции между регионами.
Миграция данных между регионами должна избежать, так как миграция занимает много времени. Это проще сделать, чтобы запустить реплика чтения в целевом geoRegion, отработку отказа приложения и выполнить описанные ранее действия.
В. Поддерживается ли миграция между подписками?
А. Средство миграции с одним сервером на гибкий сервер поддерживает миграцию между подписками.
В. Поддерживается ли подписка между группами ресурсов?
А. Средство миграции с одним сервером на гибкий сервер поддерживает миграцию между группами ресурсов.
В. Поддерживаются ли разные версии?
А. Служба миграции с одним сервером на гибкий сервер поддерживает переход с более низкой версии PostgreSQL (PG 9.5 и выше) на любую более позднюю версию. Как всегда, совместимость приложений с более высокими версиями PostgreSQL должна быть проверка заранее.
Средство миграции с одним сервером на гибкий сервер
Средство миграции с одного сервера на гибкий сервер — это мощное средство , позволяющее легко перенести базу данных SQL Server с одного сервера на гибкий сервер. С помощью этого средства можно легко переместить базу данных с локального сервера или виртуальной машины на гибкий сервер в облаке, что позволяет воспользоваться преимуществами масштабируемости и гибкости облачных вычислений.
В. Какие компоненты данных, схемы и метаданных переносятся в ходе миграции?
А. Средство миграции с одним сервером на гибкий сервер переносит схему, данные и метаданные из источника в место назначения. Все следующие компоненты данных, схемы и метаданных переносятся в рамках миграции базы данных:
Миграция данных
- Все таблицы из всех баз данных и схем.
Миграция схемы:
- Именование
- Первичный ключ
- Тип данных
- Порядковое положение
- Default value
- Допускает значения NULL
- Атрибуты автоматического увеличения
- Вторичные индексы
Миграция метаданных:
- Хранимые процедуры
- Функции
- Триггеры
- Представления
- Ограничения внешнего ключа
В. Какова разница между автономной и онлайн-миграцией?
А. Средство миграции с одним сервером на гибкий сервер поддерживает автономную миграцию в ближайшее время. При автономной миграции время простоя приложения начинается при начале миграции. При миграции по сети время простоя ограничено временем, необходимым для сокращения в конце миграции, но используется логический механизм реплика. Данные и схема должны передавать эти ограничения подсистемы PG с открытым исходным кодом для миграции через Интернет. Мы рекомендуем протестировать автономную миграцию, чтобы определить допустимо ли время простоя.
Сравнение миграции в сети и автономной миграции приведено в следующей таблице:
В. Существуют ли рекомендации по оптимизации производительности средства миграции одного сервера на гибкий сервер?
О. Да. Чтобы ускорить миграцию, выберите более высокий номер SKU для гибкого сервера. Выберите минимум 4VCore или более поздней версии, чтобы быстро завершить миграцию. Номер SKU всегда можно изменить в соответствии с требованиями приложения после миграции.
В. Как долго выполняется автономная миграция с одним сервером на гибкий инструмент миграции сервера?
А. В следующей таблице показано время выполнения автономной миграции для баз данных различных размеров с помощью средства миграции с одним сервером на гибкий сервер. Миграция была выполнена с помощью гибкого сервера с номером SKU:
Standard_D4ds_v4(4 ядра, 16 ГБ памяти, 128 ГБ диска и 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 (восстановление на определенный момент времени) одного сервера и его запуск с одним сервером на средство миграции гибкого сервера.
В. Как долго выполняется миграция через Интернет с одним сервером на гибкий инструмент миграции сервера?
А. Миграция через Интернет включает в себя следующие действия.
- Начальная копия баз данных
- Изменение записи данных — повторная передача всех транзакций в источнике во время шага 1 на целевой объект.
Время, затраченное на шаге 1, совпадает с автономными миграциями (см. предыдущий вопрос).
Время, затраченное на шаг 2, зависит от транзакций, происходящих в источнике. Если это рабочая нагрузка с интенсивной записью, время, затраченное на шаг 2, будет больше.
Дополнительная поддержка
В. У меня есть дополнительные вопросы о выходе на пенсию.
А. Дополнительные сведения можно получить несколькими способами.
Ответы от экспертов сообщества в Microsoft Q&A.
Вы можете связаться с командой База данных Azure для PostgreSQL продукта.
Если у вас есть план поддержки и вам нужна техническая помощь, создайте запрос на поддержку:
- В поле "Сводка" введите описание проблемы.
- В качестве типа проблемы укажите "Техническая".
- В качестве подписки выберите свою подписку.
- В качестве службы выберите Мои приложения.
- Для типа службы выберите База данных Azure для PostgreSQL один сервер.
- Для ресурса выберите ресурс.
- Для типа проблемы выберите "Миграция в Базу данных Azure для PostgreSQL".
- Для подтипа проблемы выберите переход с одного на гибкий сервер.
Предупреждение
Эта статья не подходит для База данных Azure для PostgreSQL — гибкие пользователи сервера. Это для База данных Azure для PostgreSQL — клиентов с одним сервером, которым необходимо обновить до База данных Azure для PostgreSQL — гибкий сервер.
Мы знаем, что миграция служб может быть разочарованием, и мы заранее извиняемся за любые неудобства, которые могут привести к вам. Вы можете выбрать оптимальный сценарий для вас и вашей среды.