Skip to main content

​
Monitoramento e métricas

​
Como posso acessar as métricas da minha instância do ClickHouse Managed Postgres?

Você pode monitorar o uso de CPU, memória, IOPS e armazenamento diretamente no console do ClickHouse Cloud, na aba Monitoramento da sua instância do ClickHouse Managed Postgres. Além disso, você pode explorar Query Performance Insights para uma análise detalhada das suas consultas na aba Query Insights.

​
Backup e recuperação

​
Quais opções de backup estão disponíveis?

O ClickHouse Managed Postgres inclui backups automáticos diários com arquivamento contínuo de WAL, permitindo a recuperação para um ponto no tempo a qualquer momento dentro de uma janela de retenção de 7 dias. Os backups são armazenados em armazenamento de objetos. Para obter detalhes completos sobre a frequência dos backups, a retenção e como realizar a recuperação para um ponto no tempo, consulte a documentação de Backup e restauração.

​
Infraestrutura e automação

​
Quais provedores de Cloud são suportados?

O ClickHouse Managed Postgres está disponível na AWS em public beta. O GCP está em Private Preview. Você pode entrar na lista de espera do Private Preview do GCP aqui e ler o anúncio para saber mais. Consulte Provedores de Cloud suportados para mais detalhes.

​
O ClickHouse Managed Postgres tem suporte ao Terraform?

Sim. Você pode criar e gerenciar serviços do ClickHouse Managed Postgres com o Terraform provider do ClickHouse usando o resource clickhouse_postgres_service. Consulte a referência do Terraform para mais detalhes. Você também pode usar o console do ClickHouse Cloud ou OpenAPI para criar e gerenciar suas instâncias.

​
Extensões e configuração

​
Quais extensões são suportadas?

O ClickHouse Managed Postgres inclui mais de 90 extensões do PostgreSQL, incluindo extensões populares como PostGIS, pgvector, pg_cron e muitas outras. Para ver a lista completa de extensões disponíveis e as instruções de instalação, consulte a documentação de Extensões.

​
Posso personalizar os parâmetros de configuração do PostgreSQL?

Sim, você pode modificar os parâmetros de configuração do PostgreSQL e do PgBouncer pela aba Settings no console. Para saber mais sobre os parâmetros disponíveis e como alterá-los, consulte a documentação de Settings.
Se precisar de um parâmetro que ainda não esteja disponível, entre em contato com o suporte para solicitá-lo.

​
Pool de conexões

​
Por que estou recebendo erros prepared statement does not exist ao usar o PgBouncer?

O ClickHouse Managed Postgres executa o PgBouncer no modo pooling de transações. Nesse modo, uma conexão de backend do Postgres fica atribuída ao seu cliente apenas durante uma única transação e depois é devolvida ao pool — a próxima transação do mesmo cliente pode ir parar em um backend diferente. O PgBouncer rastreia prepared statements em nível de protocolo, que a maioria dos drivers envia pelo protocolo de consulta estendido (mensagens Parse, Bind e Execute). Quando uma instrução é executada em um backend que ainda não a conhece, o PgBouncer primeiro a prepara nesse backend. Cada conexão de backend mantém até max_prepared_statements delas (200 por padrão). Por isso, a maioria dos drivers funciona com o PgBouncer usando suas configurações padrão. O que não funciona com o PgBouncer:
  • Prepared statements em nível de SQL. O PgBouncer não rastreia PREPARE e EXECUTE enviados como SQL, então um EXECUTE pode ir parar em um backend que nunca executou o PREPARE.
  • Liberar instruções com DEALLOCATE em SQL. O PgBouncer renomeia as instruções no backend, então um DEALLOCATE usando o nome da instrução definido pelo cliente falha. Dentro de uma transação, isso aborta a transação, e as instruções seguintes falham com current transaction is aborted. Drivers baseados na libpq 17 ou posterior liberam instruções com uma mensagem Close em nível de protocolo, que o PgBouncer consegue tratar.
  • Instruções sem nome divididas entre idas e voltas ao servidor. Alguns modos de driver enviam o Parse de uma instrução sem nome em uma ida e volta ao servidor e o Bind correspondente na seguinte. O PgBouncer pode executar a segunda ida e volta ao servidor em um backend diferente, o que resulta em falha com unnamed prepared statement does not exist ou, silenciosamente, na execução da instrução de outro cliente, retornando os resultados dela.
Nesses casos, ocorrem erros como:
Sintomas que frequentemente têm essa mesma causa raiz:
  • Picos de erros prepared statement does not exist, especialmente durante backfills ou gravações com alta concorrência
  • Inserts que parecem “falhar silenciosamente” — a instrução gera erro, o driver faz novas tentativas e um lote pode acabar aplicado parcialmente ou descartado
  • Transações que falham com current transaction is aborted depois que uma instrução é liberada
  • Linhas que pertencem a uma consulta diferente
Correção: use a configuração correspondente ao seu driver abaixo. Se o seu driver não estiver listado, faça o upgrade dele para um lançamento que use a libpq 17 ou posterior, ou desative nele as prepared statements do lado do servidor. Se a sua carga de trabalho depende de PREPARE no nível de SQL, conecte-se diretamente ao PostgreSQL (porta 5432) em vez de usar o pooler PgBouncer. Consulte Conexão para saber como escolher entre os endpoints com pooling e os diretos.

​
Por que as consultas falham com cached plan must not change result type após uma migração?

O PgBouncer mantém prepared statements em suas conexões com o Postgres e os reutiliza para o mesmo texto SQL. Após uma alteração de schema que muda o tipo de uma coluna retornada por uma consulta, por exemplo de integer para bigint, essa consulta continua falhando via PgBouncer com cached plan must not change result type. A falha ocorre até mesmo em novas conexões de cliente, até que o PgBouncer substitua suas conexões com o Postgres. Alguns drivers, em vez de falhar, decodificam os tipos de resultado desatualizados e retornam valores incorretos sem gerar erro. Pela conexão direta, cada conexão falha no máximo uma vez e depois se recupera. Para resolver, encerre as conexões do PgBouncer com o Postgres para esse banco de dados, e o PgBouncer abrirá novas conexões. O PgBouncer se conecta ao Postgres localmente, portanto suas conexões não têm client_addr. Execute o comando abaixo pela conexão direta (porta 5432), com o mesmo usuário que sua aplicação usa para se conectar. Ele encerra apenas as conexões do PgBouncer do usuário da sua aplicação; assim, as transações em execução via PgBouncer naquele momento falharão, mas as conexões diretas não serão afetadas:
Drivers que usam instruções sem nome, como o Npgsql com suas configurações padrão, o Postgrex com prepare: :unnamed e o pgx com cache_describe, não são afetados.

​
Por que recebo unsupported startup parameter ao usar o PgBouncer?

O PgBouncer rejeita configurações definidas no momento da conexão que ele não consegue aplicar de forma consistente em todas as conexões Postgres do seu pool e falha com FATAL: unsupported startup parameter: ... ou unsupported startup parameter in options: .... Os casos mais comuns são:
  • extra_float_digits, que o pgjdbc 42.7.4 e versões anteriores (por exemplo, com Spring Boot 3) e o sqlx enviam em toda conexão. Faça o upgrade do pgjdbc para a versão 42.7.5 ou posterior. No sqlx, defina extra_float_digits(None) em PgConnectOptions.
  • search_path e outras configurações na string de conexão, como currentSchema em uma URL JDBC, Search Path em uma string de conexão do Npgsql, options=-c ... ou OPTIONS["options"] do Django. Nesses casos, defina o valor padrão com ALTER ROLE ... SET ou ALTER DATABASE ... SET, use SET LOCAL dentro de uma transação ou conecte-se diretamente.
application_name e TimeZone são compatíveis.

​
Por que os comandos SET não persistem ao usar o PgBouncer?

No modo de pooling de transações, um SET em nível de sessão se aplica à conexão do Postgres que o executou, e não ao seu cliente. Transações posteriores do seu cliente podem ser executadas em outras conexões que não têm essa configuração, enquanto outros clientes podem acabar usando a conexão que a tem. Isso inclui SET ROLE, ou seja, uma função que você assume pode acabar sendo aplicada às consultas de outro cliente. Use SET LOCAL dentro de uma transação, defina valores padrão com ALTER ROLE ... SET ou ALTER DATABASE ... SET, ou conecte-se diretamente no caso de cargas de trabalho que dependem do estado da sessão.

​
Por que as migrações travam ou não conseguem liberar um advisory lock via PgBouncer?

Muitas ferramentas de migração adquirem um advisory lock em nível de sessão para garantir que apenas uma migração seja executada por vez e depois o liberam com uma instrução separada. Via PgBouncer, a liberação pode ser executada em outra conexão Postgres, e o bloqueio permanece em uma conexão do pool. Com isso, as migrações seguintes ficam aguardando ou falham com erros como failed to release advisory lock, mesmo usando a conexão direta. Entre as ferramentas que usam advisory locks de sessão estão golang-migrate, sqlx, o Migrator do Kysely, Rails, Flyway com transactional-lock=false e Ecto com migration_lock: :pg_advisory_lock. Execute as migrações pela conexão direta (porta 5432). Um bloqueio vazado é mantido por uma sessão idle, enquanto uma migração ainda em execução mantém seu bloqueio em uma sessão ativa. Para liberar bloqueios vazados, encerre apenas as sessões idle que mantêm advisory locks no seu banco de dados, também pela conexão direta:

​
O que significa a configuração max_client_conn no PgBouncer e como ela se relaciona com max_connections no Postgres?

Elas controlam coisas diferentes:
  • Postgres max_connections limita o número de conexões de backend com o próprio PostgreSQL. Esse é o número mais custoso — cada backend consome memória e um slot de processo.
  • PgBouncer max_client_conn limita o número de conexões de cliente que podem ficar abertas simultaneamente no pooler. O PgBouncer multiplexa essas várias conexões de cliente em um conjunto muito menor de conexões de backend.
O PgBouncer aceita várias vezes mais conexões de cliente do que o número de backends do Postgres. Por exemplo, uma instância com max_connections definido como 500 aceita 2500 conexões de cliente no pooler. Se você vir erros de conexão no pooler, é muito mais provável que esteja esbarrando em um limite de backend por pool (default_pool_size, ou max_db_connections por banco de dados) do que no limite total de clientes. Para ver os valores da sua instância, conecte-se ao banco de dados especial pgbouncer por meio do PgBouncer (porta 6432) e execute SHOW CONFIG:

​
Recursos do banco de dados

​
Posso criar vários bancos de dados e esquemas?

Sim. O ClickHouse Managed Postgres oferece todos os recursos nativos do PostgreSQL, incluindo suporte a vários bancos de dados e esquemas em uma única instância. Você pode criar e gerenciar bancos de dados e esquemas usando os comandos padrão do PostgreSQL.

​
Há suporte a Controle de Acesso Baseado em Funções (RBAC)?

Você tem acesso completo de superusuário à sua instância do ClickHouse Managed Postgres, o que permite criar funções e gerenciar permissões usando os comandos padrão do PostgreSQL.
Recursos avançados de RBAC com integração ao Console estão planejados para este ano.

​
Atualizações de versão

​
Como as atualizações de versão do PostgreSQL são gerenciadas?

Tanto as atualizações de versões secundárias quanto as de versões principais são realizadas por failover e normalmente resultam em apenas alguns segundos de indisponibilidade. Você pode configurar upgrades agendados para controlar os dias e a janela de duas horas em UTC em que os upgrades são aplicados. Para mais detalhes, consulte a documentação de upgrade.

​
Migração

​
Quais ferramentas estão disponíveis para migrar para o ClickHouse Managed Postgres?

O ClickHouse Managed Postgres oferece suporte a várias abordagens de migração:
  • pg_dump and pg_restore: Para bancos de dados menores ou migrações únicas. Consulte o guia pg_dump and pg_restore.
  • Logical replication: Para bancos de dados maiores que exigem o mínimo de indisponibilidade. Consulte o guia Replicação lógica.
  • PeerDB: Para replicação baseada em CDC a partir de outras fontes do Postgres. Consulte o guia Migração com PeerDB.
Uma experiência de migração totalmente gerenciada estará disponível em breve.