Масштабирование ресурсов в База данных Azure для PostgreSQL — гибкий сервер

Гибкий экземпляр сервера Базы данных Azure для PostgreSQL поддерживает параметры вертикального и горизонтального масштабирования.

Вертикальное масштабирование

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

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

После создания гибкого экземпляра сервера Базы данных Azure для PostgreSQL можно независимо масштабировать:

• Уровень вычислений и номер SKU.
• Уровень хранилища и размер.
• Период хранения резервных копий.

Вы можете масштабировать уровень вычислений вверх или вниз между Burstable, Общие задачи и Оптимизированный для памяти, чтобы соответствовать потребностям вашей рабочей нагрузки. На каждом из этих уровней можно выбрать широкий выбор предварительно настроенного оборудования разных поколений с различным количеством ЦП и объемом установленной памяти. Вы можете выбрать вариант, поддерживающий требования к ресурсам, сохраняя снижение и корректировку операционных затрат.

Вы можете изменять количество виртуальных ядер и объём установленной памяти, увеличивая или уменьшая его. Вы также можете настроить уровень хранилища, увеличивая или уменьшая его, чтобы соответствовать требованиям к пропускной способности и операциям ввода-вывода в секунду, необходимым для вашей рабочей нагрузки. Увеличить можно только размер хранилища. В зависимости от требований можно увеличить или уменьшить период хранения резервных копий в диапазоне от 7 до 35 дней.

Эти ресурсы можно масштабировать с помощью нескольких интерфейсов. Например, можно использовать портал Azure или Azure CLI.

Горизонтальное масштабирование

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

Масштабирование реплики чтения

Другим подходом к горизонтальному масштабированию экземпляра является создание реплик чтения. Реплики чтения позволяют масштабировать рабочие нагрузки чтения за счет использования отдельных экземпляров База данных Azure для PostgreSQL — Flexible Server. Они не влияют на производительность и доступность основного экземпляра.

В настройке с горизонтальным масштабированием можно также вертикально масштабировать основной экземпляр и реплики для чтения.

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

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

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

Масштабирование хранилища не требует перезапуска сервера в большинстве случаев. Дополнительные сведения см. в разделе "Параметры хранения" в Базе данных Azure для PostgreSQL.

Изменения периода хранения резервных копий являются оперативной операцией.

Чтобы улучшить время перезапуска, выполните операции масштабирования в нерабочие часы. Этот подход сокращает время, необходимое для перезапуска сервера базы данных.

Масштабирование с почти нулевым временем простоя

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

Как правило, этот процесс может занять от 2 до 10 минут с регулярным масштабированием. Благодаря функции масштабирования с почти нулевым временем простоя это время сокращается до менее чем 30 секунд. Это сокращение времени простоя во время масштабирования ресурсов повышает общую доступность экземпляра базы данных.

Принцип работы

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

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

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

Точные ожидания простоя

• Длительность простоя: в большинстве случаев время простоя составляет от 10 до 30 секунд.
• Другие рекомендации. После события масштабирования существует встроенный период DNS Time-To-Live (TTL) примерно в 30 секунд. Процесс масштабирования не управляет этим периодом напрямую. Это стандартная часть поведения DNS. С точки зрения приложения общее время простоя во время масштабирования может находиться в диапазоне от 40 до 60 секунд.

Соображения и ограничения

• Чтобы масштабирование с почти нулевым временем простоя работало, при использовании интеграции с виртуальной сетью разрешите все входящие и исходящие подключения между IP-адресами в делегированной подсети. Если вы не разрешите эти подключения, процесс масштабирования с почти нулевым временем простоя не будет работать, а масштабирование будет выполняться через стандартный рабочий процесс.
• Масштабирование с почти нулевым временем простоя не работает, если в регионе действуют ограничения доступной ёмкости или ограничения квот в рамках вашей подписки.
• Масштабирование почти нулевого простоя не работает для сервера-реплики, так как оно поддерживается только на основном сервере. Для серверов-реплик операция масштабирования автоматически проходит через обычный процесс.
• Масштабирование почти нулевого времени простоя не работает, если у сервера, внедренного в виртуальную сеть, нет достаточного количества доступных IP-адресов в делегированной подсети. Если у вас есть автономный сервер, потребуется один дополнительный IP-адрес. Для экземпляра с включённой функцией высокой доступности требуются два дополнительных IP-адреса.
• Логические слоты репликации не сохраняются при переключении при отказе с почти нулевым временем простоя. Чтобы поддерживать слоты логической репликации и обеспечить согласованность данных после операции масштабирования, используйте расширение pg_failover_slot . Дополнительные сведения см. в разделе Включение расширения pg_failover_slots на экземпляре гибкого сервера.
• Масштабирование с почти нулевым временем простоя не работает с нежурналируемыми таблицами. Если вы используете таблицы без журнала для хранения любых данных, вы потеряете все данные в этих таблицах после масштабирования с почти нулевым временем простоя.
• Режим почти нулевого использования не работает, если вы масштабируете вычислительные ресурсы вашего сервера от 1 или 2 виртуальных ядер уровня "Burstable".

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

• Управление базой данных Azure для PostgreSQL