Share via

Ограничения в Базе данных Azure для PostgreSQL (Гибкий сервер)

  • Статья

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

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

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

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

  • В настоящее время для масштабирования хранилища сервера требуется перезапуск сервера.
  • Хранилище сервера можно масштабировать только в 2x приращения, см. в служба хранилища подробных сведений.
  • Уменьшение размера хранилища сервера в настоящее время не поддерживается. Единственным способом является дампа и восстановление его в новом База данных Azure для PostgreSQL гибком экземпляре сервера.

Хранилище

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

Сеть

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

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

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

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

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

  • Postgres 10 и более ранних версий не поддерживаются, так как сообщество с открытым исходным кодом отставили их. Если вы должны использовать одну из этих версий, необходимо использовать параметр База данных Azure для PostgreSQL отдельный сервер, который поддерживает старые основные версии 9.5, 9.6 и 10.
  • База данных Azure для PostgreSQL гибкий сервер поддерживает все contrib расширения и многое другое. (дополнительные сведения см. в статье Использование расширений PostgreSQL в базе данных Azure для PostgreSQL).
  • Встроенный пул подключений PgBouncer в настоящее время недоступен для серверов с возможностью ускорения.

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

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

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

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

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

  • Система управляет резервными копиями. В настоящее время нет способа запускать резервные копии вручную. Вместо этого рекомендуется использовать pg_dump.

  • Первый моментальный снимок — это полная резервная копия, а последовательные моментальные снимки — разностные резервные копии. Разностные резервные копии резервирует только измененные данные с момента последнего резервного копирования моментальных снимков.

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

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

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

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