Перейти к основному содержанию

​
Мониторинг и метрики

​
Как получить доступ к метрикам моего экземпляра Managed Postgres?

Вы можете отслеживать использование CPU, памяти, IOPS и хранилища напрямую в консоли ClickHouse Cloud на вкладке Мониторинг вашего экземпляра Managed Postgres. Кроме того, вы можете ознакомиться с Query Performance Insights для подробного анализа ваших запросов на вкладке Query Insights.

​
Резервное копирование и восстановление

​
Какие варианты резервного копирования доступны?

Managed Postgres включает автоматическое ежедневное резервное копирование с непрерывным архивированием WAL, что позволяет выполнять восстановление на определённый момент времени на любой момент в пределах 7-дневного периода хранения. Резервные копии хранятся в S3. Подробные сведения о частоте резервного копирования, сроках хранения и выполнении восстановления на определённый момент времени см. в документации Backup and restore.

​
Инфраструктура и автоматизация

​
Доступна ли поддержка Terraform для Managed Postgres?

Поддержка Terraform для Managed Postgres в настоящее время недоступна. Мы рекомендуем использовать консоль ClickHouse Cloud или OpenAPI для создания экземпляров и управления ими.

​
Расширения и конфигурация

​
Какие расширения поддерживаются?

Managed Postgres включает более 90 расширений PostgreSQL, в том числе популярные PostGIS, pgvector, pg_cron и многие другие. Полный список доступных расширений и инструкции по установке см. в документации Расширения.

​
Можно ли настраивать параметры конфигурации PostgreSQL?

Да, параметры конфигурации PostgreSQL и PgBouncer можно изменять на вкладке Настройки в консоли. Подробнее о доступных параметрах и о том, как их изменять, см. в документации Настройки.
Если вам нужен параметр, который пока недоступен, обратитесь в поддержку, чтобы запросить его.

​
Пул соединений

​
Почему через PgBouncer возникают ошибки prepared statement does not exist?

Managed Postgres использует PgBouncer в режиме transaction pooling. В этом режиме backend-соединение Postgres выделяется вашему клиенту только на время одной транзакции, а затем возвращается в пул — следующая транзакция того же клиента может попасть на другое backend-соединение. Из-за этого не работают серверные подготовленные операторы, привязанные к конкретному backend-соединению, на котором был выполнен PREPARE (или Parse в extended query). Если соответствующий EXECUTE попадает на другое backend-соединение, возникают ошибки вида:
Симптомы, которые часто указывают на одну и ту же первопричину:
  • Всплески ошибок prepared statement does not exist, особенно во время дозагрузки или записи с высоким параллелизмом
  • Вставки, которые как будто «тихо не срабатывают»: оператор завершается ошибкой, драйвер выполняет повторную попытку, и в итоге батч может быть применён частично или вовсе отброшен
  • Возвращаемые значения неправильного типа (например, столбец BIGINT, декодированный как битовый шаблон float64) — это происходит, когда кэшированный клиентский план повторно использует устаревшие коды типа/формата для backend-соединения, которому так и не был отправлен соответствующий Parse
Исправление: отключите подготовленные операторы на стороне сервера в драйвере. Конкретный параметр зависит от используемой клиентской библиотеки: Если ваша рабочая нагрузка зависит от подготовленных операторов, подключайтесь напрямую к PostgreSQL (порт 5432), а не через пулер PgBouncer — прямые подключения штатно поддерживают подготовленные операторы. Подробнее о выборе между pooled и direct конечными точками см. в разделе Connection.

​
Что означает параметр max_client_conn в PgBouncer и как он соотносится с max_connections в Postgres?

Они отвечают за разные вещи:
  • max_connections в Postgres ограничивает число backend-соединений с самим PostgreSQL. Это затратный показатель — каждое backend-соединение потребляет память и занимает слот процесса.
  • max_client_conn в PgBouncer ограничивает число клиентских соединений, которые могут быть одновременно открыты в пулере. PgBouncer мультиплексирует множество таких клиентских соединений на значительно меньшее число backend-соединений.
Типичный экземпляр Managed Postgres настроен так, что PgBouncer принимает примерно в 10 раз больше клиентских соединений, чем есть backend-соединений Postgres (например, 5000 клиентских / 500 backend-соединений). Если вы видите ошибки соединения на стороне пулера, гораздо вероятнее, что вы упираетесь в лимит backend-соединений для конкретного пула (default_pool_size), а не в основной лимит клиентских соединений.

​
Возможности базы данных

​
Могу ли я создать несколько баз данных и схем?

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

​
Поддерживается ли ролевое управление доступом (RBAC)?

У вас есть полный доступ с правами superuser к вашему экземпляру Managed Postgres, что позволяет создавать роли и управлять разрешениями с помощью стандартных команд PostgreSQL.
Расширенные возможности RBAC с интеграцией в консоль планируются в этом году.

​
Обновления

​
Как выполняются обновления версий PostgreSQL?

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

​
Миграция

​
Какие инструменты доступны при миграции в Managed Postgres?

Managed Postgres поддерживает несколько подходов к миграции:
  • pg_dump and pg_restore: Для небольших баз данных или разовых миграций. См. руководство pg_dump and pg_restore.
  • Logical replication: Для более крупных баз данных, где требуется минимальное время простоя. См. руководство Логическая репликация.
  • PeerDB: Для репликации на основе CDC из других экземпляров Postgres. См. руководство Миграция с PeerDB.
Полностью управляемый процесс миграции скоро станет доступен.
Последнее изменение 2 июля 2026 г.