Масштабирование ресурсов в База данных Azure для PostgreSQL — гибкий сервер
ОБЛАСТЬ ПРИМЕНЕНИЯ: 
База данных Azure для PostgreSQL — гибкий сервер
База данных Azure для PostgreSQL — гибкий сервер поддерживает параметры вертикального и горизонтального масштабирования.
Вертикальное масштабирование
Вы можете масштабировать экземпляр по вертикали, добавив дополнительные ресурсы в База данных Azure для PostgreSQL гибкий экземпляр сервера. Вы можете увеличить или уменьшить количество ЦП и памяти, назначенных ему.
Пропускная способность сети экземпляра зависит от значений, которые вы выбираете для ЦП и памяти.
После создания гибкого экземпляра сервера База данных Azure для PostgreSQL можно независимо масштабировать:
- Уровень вычислений и номер SKU.
- Уровень хранилища и размер.
- Период хранения резервных копий.
Уровень вычислений можно масштабировать вверх или вниз между ускорением, общим назначением и оптимизированной для памяти, чтобы настроить потребности рабочей нагрузки. На каждом из этих уровней достаточно выбора предварительно настроенного оборудования разных поколений и с более или менее ЦП и более или менее установленной памяти. Среди этого широкого выбора вы можете выбрать тот, который поддерживает требования к ресурсам в любое время, сохраняя операционные затраты на снижение и корректировку ваших потребностей.
Количество виртуальных ядер и установленной памяти можно увеличить или уменьшить. Уровень хранилища также можно настроить вверх или вниз для удовлетворения требований пропускной способности и операций ввода-вывода в секунду, необходимых рабочей нагрузке. Размер хранилища можно только увеличить. Кроме того, в зависимости от ваших требований можно увеличить или уменьшить период хранения резервных копий в диапазоне от 7 до 35 дней.
Эти ресурсы можно масштабировать с помощью нескольких интерфейсов. Например, можно использовать портал Azure или Azure CLI.
Примечание.
После увеличения размера хранилища, назначенного экземпляру, его нельзя уменьшить до меньшего размера.
Горизонтальное масштабирование
Вы можете горизонтально масштабировать экземпляр, создав реплики чтения. Реплики чтения позволяют масштабировать рабочие нагрузки чтения на отдельные База данных Azure для PostgreSQL гибкие экземпляры сервера. Они не влияют на производительность и доступность основного экземпляра.
В горизонтально масштабируемой настройке основной экземпляр и реплики чтения также можно масштабировать по вертикали.
При изменении количества виртуальных ядер или уровня вычислений экземпляр перезагрузится таким образом, чтобы новое аппаратное оборудование начало выполнять рабочую нагрузку сервера. В течение этого времени система переключается на новый тип сервера. Новые подключения не могут быть установлены, и откат всех незафиксированных транзакций.
Общее время перезапуска сервера зависит от процесса аварийного восстановления и действия базы данных во время перезапуска. Обычно перезапуск занимает минуту или меньше, но может занять несколько минут. Время зависит от транзакционного действия при инициировании перезапуска.
Если приложение учитывает потерю транзакций во время масштабирования вычислений, рекомендуется реализовать шаблон повторных попыток транзакции.
Масштабирование хранилища не требует перезапуска сервера в большинстве случаев. Дополнительные сведения см. в разделе "Параметры хранения" в База данных Azure для PostgreSQL — гибкий сервер.
Изменения периода хранения резервных копий являются оперативной операцией.
Чтобы повысить время перезапуска, рекомендуется выполнять операции масштабирования во время внепиковой нагрузки. Этот подход сокращает время, необходимое для перезапуска сервера базы данных.
Сокращение времени простоя
Сокращение времени простоя — это функция, предназначенная для минимизации простоя при изменении уровней хранилища и вычислений. Если изменить количество виртуальных ядер или уровень вычислений, сервер перезапускается, чтобы применить новую конфигурацию. Во время этого перехода на новый сервер новые подключения не могут быть установлены.
Как правило, этот процесс может занять от 2 до 10 минут с регулярным масштабированием. При снижении времени простоя эта длительность уменьшается до 30 секунд. Это сокращение времени простоя во время масштабирования ресурсов повышает общую доступность экземпляра базы данных.
Принцип работы
При обновлении База данных Azure для PostgreSQL гибкого экземпляра сервера в сценариях масштабирования служба создает новую виртуальную машину для сервера с обновленной конфигурацией. Затем синхронизируется с виртуальной машиной, которая в настоящее время выполняет экземпляр, а затем переключается на новую с коротким прерыванием. Затем фоновый процесс устраняет старую виртуальную машину. Весь этот процесс выполняется без дополнительных затрат.
Этот процесс позволяет легко обновлять, минимизируя время простоя и обеспечивая экономичность. Этот процесс масштабирования активируется при внесении изменений в уровни хранилища и вычислений. Для использования этой возможности не требуется никаких действий клиента.
Для конфигураций горизонтального масштабирования, состоящих из первичного сервера и одной или нескольких реплик чтения, операции масштабирования должны соответствовать определенной последовательности, чтобы обеспечить согласованность данных и свести к минимуму время простоя. Дополнительные сведения об этой последовательности см . в разделе масштабирования с помощью реплик чтения.
Примечание.
Уменьшение времени простоя — это тип операции по умолчанию . При возникновении следующих ограничений система переключается на регулярное масштабирование, что включает больше простоев по сравнению с уменьшением времени простоя.
Точные ожидания простоя
- Длительность простоя: в большинстве случаев время простоя составляет от 10 до 30 секунд.
- Другие рекомендации. После события масштабирования существует встроенный период DNS
Time-To-Live(TTL) примерно в 30 секунд. Процесс масштабирования не управляет этим периодом напрямую. Это стандартная часть поведения DNS. С точки зрения приложения общее время простоя во время масштабирования может находиться в диапазоне от 40 до 60 секунд.
Рекомендации и ограничения
- Чтобы сократить время простоя для работы, разрешите все входящие и исходящие подключения между IP-адресами в делегированной подсети при использовании интегрированных сетей виртуальной сети. Если эти подключения не разрешены, процесс уменьшения времени простоя не работает, а масштабирование выполняется через стандартный рабочий процесс масштабирования.
- Сокращение времени простоя не работает, если в подписке существуют региональные ограничения емкости или квоты.
- Уменьшение времени простоя не работает для сервера-реплики, так как оно поддерживается только на основном сервере. Для серверов-реплик операция масштабирования автоматически проходит через обычный процесс.
- Сокращение времени простоя не работает, если у сервера, внедренного в виртуальную сеть, нет достаточного количества доступных IP-адресов в делегированной подсети. Если у вас есть автономный сервер, потребуется один дополнительный IP-адрес. Для экземпляра с поддержкой высокой доступности требуются два дополнительных IP-адреса.
- Слоты логической репликации не сохраняются во время события отработки отказа с уменьшенным временем простоя. Чтобы поддерживать слоты логической репликации и обеспечить согласованность данных после операции масштабирования, используйте расширение pg_failover_slot . Дополнительные сведения см. в разделе о включении расширения pg_failover_slots в экземпляре гибкого сервера.
- Сокращение времени простоя не работает с незалогизованными таблицами. Если вы используете незалогированные таблицы для любого из ваших данных, потеряете все данные в этих таблицах после уменьшения времени простоя.