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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Этот процесс обеспечивает простое обновление с минимальным временем простоя и автоматически активируется при изменении хранилища или вычислительных уровней. Вам не нужно предпринимать никаких действий для использования этой возможности. Эта возможность поддерживается как для экземпляров гибкого сервера Azure Database for 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