Ограничения гибкого сервера Azure Database для PostgreSQL

2025-07-21

ОБЛАСТЬ ПРИМЕНЕНИЯ: База данных Azure для PostgreSQL — гибкий сервер

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

Максимальное количество соединений

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

Название продукта	Количество виртуальных ядер	Размер памяти	Максимальное количество соединений	Максимальное число пользовательских подключений
С увеличивающейся производительностью
B1ms	1	2 ГиБ	50	35
B2s	2	4 ГиБ	429	414
B20ms	2	8 ГиБ	859	844
B4 мс	4	16 ГиБ	1,718	1,703
B8ms	8	32 ГиБ	3437	3,422
B12ms	12	48 ГиБ	5 000	4,985
B16ms	16	64 ГиБ	5 000	4,985
B20ms	20	80 ГиБ	5 000	4,985
Общего назначения
D2s_v3 / D2ds_v4 / D2ds_v5 / D2ads_v5	2	8 ГиБ	859	844
D4s_v3 / D4ds_v4 / D4ds_v5 / D4ads_v5	4	16 ГиБ	1,718	1,703
D8s_v3 / D8ds_V4 / D8ds_v5 / D8ads_v5	8	32 ГиБ	3437	3,422
D16s_v3 / D16ds_v4 / D16ds_v5 / D16ads_v5	16	64 ГиБ	5 000	4,985
D32s_v3 / D32ds_v4 / D32ds_v5 / D32ads_v5	32	128 ГиБ	5 000	4,985
D48s_v3 / D48ds_v4 / D48ds_v5 / D48ads_v5	48	192 ГиБ	5 000	4,985
D64s_v3 / D64ds_v4 / D64ds_v5 / D64ads_v5	64	256 Гиб	5 000	4,985
D96ds_v5 / D96ads_v5	96	384 ГиБ	5 000	4,985
Оптимизировано для обработки в памяти
E2s_v3 / E2ds_v4 / E2ds_v5 / E2ads_v5	2	16 ГиБ	1,718	1,703
E4s_v3 / E4ds_v4 / E4ds_v5 / E4ads_v5	4	32 ГиБ	3437	3,422
E8s_v3 / E8ds_v4 / E8ds_v5 / E8ads_v5	8	64 ГиБ	5 000	4,985
E16s_v3 / E16ds_v4 / E16ds_v5 / E16ads_v5	16	128 ГиБ	5 000	4,985
E20ds_v4 / E20ds_v5 / E20ads_v5	20	160 ГиБ	5 000	4,985
E32s_v3 / E32ds_v4 / E32ds_v5 / E32ads_v5	32	256 Гиб	5 000	4,985
E48s_v3 / E48ds_v4 / E48ds_v5 / E48ads_v5	48	384 ГиБ	5 000	4,985
E64s_v3 / E64ds_v4 / E64ds_v5 / E64ads_v5	64	432 ГиБ	5 000	4,985
E96ds_v5 / E96ads_v5	96	672 Гиб	5 000	4,985

Зарезервированные слоты подключения, число которых на данный момент составляет 15, могут измениться. Мы регулярно проверяем общее зарезервированное подключение на сервере. Вычислите это число путем суммирования значений reserved_connections параметров сервера и superuser_reserved_connections параметров сервера. Максимальное количество доступных подключений пользователей — max_connections (reserved_connections + superuser_reserved_connections).

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

Изменение значения max_connections

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

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

Внимание

Хотя можно увеличить значение max_connections за пределами параметра по умолчанию, мы советуем против него.

Экземпляры могут столкнуться с трудностями, когда рабочая нагрузка расширяется и требует больше памяти. По мере увеличения числа подключений использование памяти также увеличивается. Экземпляры с ограниченной памятью могут столкнуться с такими проблемами, как сбои или высокая задержка. Хотя более высокое значение max_connections может быть приемлемым, если большинство подключений неактивны, это может привести к значительным проблемам производительности после того, как они станут активными.

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

Если подключения превышают предел, может появиться следующая ошибка:

FATAL: sorry, too many clients already.

Если вы используете База данных Azure для PostgreSQL гибкий сервер для занятой базы данных с большим количеством одновременных подключений, может оказаться существенной нагрузкой на ресурсы. Эта нагрузка может привести к высокой загрузке ЦП, особенно при одновременном создании большого количества подключений и при наличии коротких длительности подключений (менее 60 секунд). Эти факторы могут негативно повлиять на общую производительность базы данных, увеличив время, затраченное на обработку подключений и отключений.

Каждое подключение в Azure Database для гибкого сервера PostgreSQL, независимо от того, неактивно оно или активно, потребляет значительное количество ресурсов вашей базы данных. Это потребление может привести к проблемам с производительностью за пределами высокой загрузки ЦП, таких как диск и блокировка конфликтов. Дополнительные сведения см. в статье "Количество подключений к базам данных " в вики-сайте PostgreSQL. Дополнительные сведения см. в статье "Определение и решение производительности подключения" в База данных Azure для PostgreSQL гибком сервере.

Функциональные ограничения

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

Операции масштабирования

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

Хранилище

После настройки размера хранилища его нельзя уменьшить. Необходимо создать новый сервер с требуемым размером хранилища, выполнить операцию дампа вручную и восстановления и перенести базы данных на новый сервер.
Когда использование хранилища достигает 95% или если доступной емкости меньше 5 ГиБ (в зависимости от того, что больше), система автоматически переключает сервер на режим только для чтения , чтобы избежать ошибок, связанных с полным диском ситуаций. В редких случаях, если скорость роста данных опережает время, необходимое для перехода в режим только для чтения, сервер может по-прежнему выйти из хранилища. Вы можете включить автоматическое увеличение хранилища, чтобы избежать этих проблем и автоматически масштабировать хранилище на основе требований рабочей нагрузки.
Рекомендуется задать правила генерации оповещений или storage usedstorage percent превышение определенных пороговых значений, чтобы можно было заранее принять меры, такие как увеличение размера хранилища. Например, можно задать оповещение, если процент хранения превышает 80 % использования.
Если вы используете логическую репликацию, необходимо удалить слот логической репликации на основном сервере, если соответствующий подписчик больше не существует. В противном случае файлы журнала накануне записи накапливаются в основном и заполняют хранилище. Если хранилище превышает определенное пороговое значение и если слот логической репликации не используется (из-за недоступного подписчика), База данных Azure для PostgreSQL гибкий сервер автоматически удаляет неиспользуемый логический слот репликации. Это действие освобождает накопленные файлы WAL и предотвращает недоступность сервера, так как хранилище заполнено.
Мы не поддерживаем создание пространств таблиц. Если вы создаете базу данных, не укажите имя пространства таблиц. Гибкий сервер Базы данных Azure для PostgreSQL использует пространство таблиц по умолчанию, наследуемое базой данных шаблона. Это небезопасно для предоставления пространства таблиц, например временного, потому что мы не можем гарантировать, что такие объекты будут оставаться постоянными после событий, таких как перезапуск сервера и отработка отказа высокой доступности (HA).

Сеть

В настоящее время мы не поддерживаем перемещение и выход из виртуальной сети.
В настоящее время мы не поддерживаем объединение общедоступного доступа с развертыванием в виртуальной сети.
Виртуальные сети не поддерживают правила брандмауэра. Вместо этого можно использовать группы безопасности сети.
Серверы базы данных общедоступного доступа могут подключаться к общедоступному Интернету; например, через postgres_fdw. Вы не можете ограничить этот доступ. Серверы в виртуальных сетях могут иметь ограниченный исходящий доступ через группы безопасности сети.

Высокая доступность

См. Высокая доступность в гибком сервере Azure Database для PostgreSQL.

Зоны доступности

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

Подсистема Postgres, расширения и PgBouncer

Гибкий сервер Базы данных Azure для PostgreSQL поддерживает все функции ядра PostgreSQL, включая секционирование, логическую репликацию и внешние оболочки данных.
База данных Azure для PostgreSQL гибкий сервер поддерживает все contrib расширения и многое другое. (дополнительные сведения см. в статье Использование расширений PostgreSQL в базе данных Azure для PostgreSQL).
В настоящее время у серверов с возможностью увеличения производительности нет доступа к встроенному пулу подключений PgBouncer.

Операции остановки и запуска

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

Запланированное обслуживание

Настраиваемое время обслуживания можно изменить на любой день или время недели. Однако любые изменения, внесенные после получения уведомления об обслуживании, не будут влиять на следующее обслуживание. Изменения вступили в силу только со следующим ежемесячным запланированным обслуживанием.

Резервные копии сервера

Система управляет резервными копиями. В настоящее время невозможно запускать резервные копии вручную. Вместо этого рекомендуется использовать pg_dump.
Первый моментальный снимок — это полная резервная копия, а последовательные моментальные снимки — разностные резервные копии. Разностные резервные копии резервирует только измененные данные с момента последнего резервного копирования моментальных снимков.

Например, если размер базы данных составляет 40 ГБ, а подготовленное хранилище составляет 64 ГБ, первая резервная копия моментального снимка составляет 40 ГБ. Теперь, если изменить 4 ГБ данных, следующий размер резервного копирования разностного моментального снимка будет только 4 ГБ. Журналы транзакций (журналы для записи) отделены от полной и разностной резервной копии, и они архивируются непрерывно.

Восстановление сервера

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

Безопасность

Postgres 14 и более поздние версии отключают использование MD5-хэширования, и система хэширует собственные пароли Postgres только с помощью метода SCRAM-SHA-256.