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

Область применения: гибкий сервер Базы данных Azure для PostgreSQL

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

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

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

• ЦП (виртуальные ядра).
• Объем хранилища.
• Период хранения резервных копий.

Число виртуальных ядер можно увеличить или уменьшить, но размер хранилища можно увеличить только. Вы также можете масштабировать период хранения резервных копий в диапазоне от 7 до 35 дней. Ресурсы можно масштабировать с помощью нескольких инструментов, например портал Azure или Azure CLI.

Примечание.

После увеличения размера хранилища вы не сможете вернуться к меньшему размеру хранилища.

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

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

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

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

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

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

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

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

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

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

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

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

Примечание.

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

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

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

Рекомендации и ограничения

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

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

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