Часто задаваемые вопросы по Managed Postgres
Мониторинг и метрики
Как получить доступ к метрикам своего экземпляра Managed Postgres?
Вы можете отслеживать загрузку CPU, использование памяти, IOPS и хранилища непосредственно в консоли ClickHouse Cloud на вкладке Monitoring вашего экземпляра Managed Postgres.
Функция Query Performance Insights для детального анализа запросов появится в ближайшее время.
Резервное копирование и восстановление
Какие варианты резервного копирования доступны?
Managed Postgres включает автоматические ежедневные резервные копии с непрерывным архивированием WAL, что обеспечивает возможность восстановления к определённому моменту времени (point-in-time recovery) в пределах 7‑дневного периода хранения. Резервные копии хранятся в S3.
Подробную информацию о частоте резервного копирования, сроках хранения и выполнении восстановления к определённому моменту времени см. в документации Резервное копирование и восстановление.
Инфраструктура и автоматизация
Доступна ли поддержка Terraform для Managed Postgres?
Поддержка Terraform для Managed Postgres на данный момент недоступна. Мы рекомендуем использовать консоль ClickHouse Cloud для создания и управления вашими экземплярами.
Расширения и настройка
Какие расширения поддерживаются?
Managed Postgres поддерживает более 100 расширений PostgreSQL, в том числе популярные PostGIS, pgvector, pg_cron и многие другие. Полный список доступных расширений и инструкции по установке см. в разделе документации Расширения.
Могу ли я настраивать параметры конфигурации PostgreSQL?
Да, вы можете изменять параметры конфигурации PostgreSQL и PgBouncer на вкладке Settings в консоли. Подробную информацию о доступных параметрах и способах их изменения см. в разделе Settings документации.
Если вам нужен параметр, который сейчас недоступен, обратитесь в службу поддержки с запросом на его добавление.
Пул соединений
Почему при работе через PgBouncer возникает ошибка prepared statement does not exist?
Managed Postgres запускает PgBouncer в режиме transaction pooling. В этом режиме backend-соединение Postgres назначается клиенту только на время одной транзакции, а затем возвращается в пул — следующая транзакция от того же клиента может попасть на другое backend-соединение.
Из-за этого не работают server-side prepared statements, которые привязаны к конкретному backend-соединению, выполнившему PREPARE (или Parse в extended query protocol). Когда соответствующий Execute попадает на другое backend-соединение, возникают ошибки вида:
Симптомы, которые часто связаны с той же первопричиной:
- Всплески ошибок
prepared statement does not exist, особенно при догрузке исторических данных или при записи с высоким параллелизмом - Вставки, которые как будто "тихо завершаются неудачей": выражение возвращает ошибку, драйвер выполняет повторную попытку, и в итоге пакет может примениться лишь частично или быть отброшен
- Возвращаемые значения с неверным типом (например, столбец
BIGINT, декодированный как битовый шаблонfloat64) — это происходит, когда кэшированный план на стороне клиента повторно использует устаревшие коды типа/формата для сервера, которому так и не был отправлен соответствующийParse
Исправление: отключите подготовленные выражения на стороне сервера в драйвере. Точный параметр зависит от используемой клиентской библиотеки:
| Driver | Setting |
|---|---|
| pgx (Go) | statement_cache_capacity=0 и default_query_exec_mode=exec (или simple_protocol) |
| psycopg3 (Python) | prepare_threshold=None |
| asyncpg (Python) | statement_cache_size=0 |
| JDBC (Java) | prepareThreshold=0 |
| node-postgres / pg (Node.js) | Не передавайте name в query() (именованные запросы становятся подготовленными на стороне сервера) |
Если ваша нагрузка зависит от подготовленных выражений, подключайтесь напрямую к PostgreSQL (порт 5432), а не через пулер PgBouncer — прямые подключения штатно поддерживают подготовленные выражения. Подробнее о выборе между конечной точкой с пулом и прямой конечной точкой см. в разделе Connection.
Что означает параметр "max_client_conn" в PgBouncer и как он соотносится с max_connections в Postgres?
Они отвечают за разные вещи:
- Postgres
max_connectionsограничивает число backend-соединений с самим PostgreSQL. Это затратный параметр — каждое backend-соединение потребляет память и занимает слот процесса. - PgBouncer
max_client_connограничивает число клиентских соединений, которые могут быть одновременно открыты к пулеру. PgBouncer мультиплексирует множество таких клиентских соединений на гораздо меньшее число backend-соединений.
Типичный экземпляр Managed Postgres настроен так, что PgBouncer принимает примерно в 10 раз больше клиентских соединений, чем доступно backend-соединений Postgres (например, 5000 клиентских / 500 backend-соединений). Если вы видите ошибки соединения на уровне пулера, гораздо вероятнее, что вы упираетесь в лимит backend-соединений для конкретного пула (default_pool_size), а не в общий лимит клиентских соединений.
Возможности базы данных
Могу ли я создавать несколько баз данных и схем?
Да. Managed Postgres предоставляет полный набор возможностей PostgreSQL, включая поддержку нескольких баз данных и схем в рамках одного экземпляра. Вы можете создавать и управлять базами данных и схемами с помощью стандартных команд PostgreSQL.
Поддерживается ли ролевая модель управления доступом (RBAC)?
У вас есть полный доступ с правами суперпользователя к вашему экземпляру Managed Postgres, что позволяет создавать роли и управлять правами доступа с помощью стандартных команд PostgreSQL.
Расширенные возможности RBAC с интеграцией с консолью запланированы на этот год.
Обновление
Как выполняются обновления версии PostgreSQL?
Минорные и мажорные обновления версии выполняются через переключение (failover) и обычно приводят только к нескольким секундам простоя. Вы можете настроить окно обслуживания, чтобы задать время выполнения обновлений. Подробные сведения см. в документации по обновлениям.
Миграция
Какие инструменты доступны для миграции на Managed Postgres?
Managed Postgres поддерживает несколько подходов к миграции:
- pg_dump и pg_restore: Для небольших баз данных или одноразовых миграций. См. руководство pg_dump and pg_restore.
- Логическая репликация: Для крупных баз данных, для которых важно минимизировать время простоя. См. руководство Logical replication.
- PeerDB: Для репликации на основе CDC из других источников Postgres. См. руководство PeerDB migration.
Полностью управляемый процесс миграции будет доступен в ближайшее время.
