Rollbacks de transações são replicados para o ClickHouse?
Posso manter os dados no ClickHouse por mais tempo do que no meu Postgres de origem?
Como posso enriquecer os dados à medida que fluem do Postgres para o ClickHouse?
Posso replicar de várias instâncias do Postgres para um ou mais serviços do ClickHouse?
Como a ociosidade afeta meu ClickPipe de CDC do Postgres?
Como o ClickPipes for Postgres lida com colunas TOAST?
Como o ClickPipes for Postgres lida com colunas geradas?
As tabelas precisam ter chaves primárias para fazer parte do Postgres CDC?
- Chave primária: A abordagem mais simples é definir uma chave primária na tabela. Isso fornece um identificador único para cada linha, o que é essencial para rastrear atualizações e exclusões. Nesse caso, você pode manter a REPLICA IDENTITY como
DEFAULT (o comportamento padrão).
- Identidade de réplica: Se uma tabela não tiver chave primária, você pode definir uma identidade de réplica. A identidade de réplica pode ser definida como
FULL, o que significa que a linha inteira será usada para identificar alterações. Como alternativa, você pode configurá-la para usar um índice único, caso exista um na tabela, e então definir a REPLICA IDENTITY como USING INDEX index_name.
Para definir a identidade de réplica como FULL, você pode usar o seguinte comando SQL:
ALTER TABLE your_table_name REPLICA IDENTITY FULL;
REPLICA IDENTITY FULL também permite a replicação de colunas TOAST inalteradas. Mais sobre isso aqui.
Observe que usar REPLICA IDENTITY FULL pode ter implicações de desempenho e também acelerar o crescimento do WAL, especialmente em tabelas sem chave primária e com atualizações ou exclusões frequentes, pois exige que mais dados sejam registrados em log a cada alteração. Se você tiver alguma dúvida ou precisar de ajuda para configurar chaves primárias ou identidades de réplica para suas tabelas, entre em contato com nossa equipe de suporte para obter orientação.
É importante observar que, se não houver uma chave primária nem uma identidade de réplica definida, o ClickPipes não conseguirá replicar alterações dessa tabela, e você poderá encontrar erros durante o processo de replicação. Portanto, é recomendável revisar os esquemas das suas tabelas e garantir que eles atendam a esses requisitos antes de configurar seu ClickPipe.
Há suporte para tabelas particionadas como parte do Postgres CDC?
Posso conectar bancos de dados Postgres que não têm IP público ou estão em redes privadas?
-
Tunelamento SSH
- Funciona bem para a maioria dos casos de uso
- Consulte as instruções de configuração aqui
- Funciona em todas as regiões
-
AWS PrivateLink
- Disponível em três regiões da AWS:
- us-east-1
- us-east-2
- eu-central-1
- Para instruções detalhadas de configuração, consulte nossa documentação do PrivateLink
- Para as regiões em que o PrivateLink não está disponível, use o tunelamento SSH
O ClickPipes for Postgres captura tanto INSERTs quanto UPDATEs do Postgres como novas linhas com versões diferentes (usando a coluna de versão _peerdb_) no ClickHouse. O mecanismo de tabela ReplacingMergeTree executa periodicamente a desduplicação em segundo plano com base na chave de ordenação (colunas de ORDER BY), mantendo apenas a linha com a versão _peerdb_ mais recente.
Os DELETEs do Postgres são propagados como novas linhas marcadas como excluídas (usando a coluna _peerdb_is_deleted). Como o processo de desduplicação é assíncrono, talvez você veja duplicatas temporariamente. Para resolver isso, é necessário tratar a desduplicação na camada de consulta.
Observe também que, por padrão, o Postgres não envia os valores de colunas que não fazem parte da chave primária nem da identidade de réplica durante operações de DELETE. Se você quiser capturar os dados completos da linha durante DELETEs, pode definir a REPLICA IDENTITY como FULL.
Para mais detalhes, consulte:
Posso atualizar colunas de chave primária no PostgreSQL?
Por padrão, atualizações de chave primária no PostgreSQL não podem ser reproduzidas corretamente no ClickHouse.Essa limitação existe porque a desduplicação do ReplacingMergeTree funciona com base nas colunas de ORDER BY (que normalmente correspondem à chave primária). Quando uma chave primária é atualizada no PostgreSQL, ela passa a aparecer no ClickHouse como uma nova linha com uma chave diferente, em vez de uma atualização da linha existente. Isso pode fazer com que tanto os valores antigos quanto os novos da chave primária coexistam na sua tabela do ClickHouse.
Há suporte para alterações de esquema?
Quais são os custos do ClickPipes for Postgres CDC?
O tamanho do meu slot de replicação está aumentando ou não diminuindo; qual pode ser o problema?
-
Picos repentinos de atividade no banco de dados
- Grandes atualizações em lote, inserts em massa ou mudanças significativas no esquema podem gerar rapidamente uma grande quantidade de dados de WAL.
- O slot de replicação manterá esses registros de WAL até que sejam consumidos, causando um aumento temporário no tamanho.
-
Transações de longa duração
- Uma transação aberta força o Postgres a manter todos os segmentos de WAL gerados desde o início da transação, o que pode aumentar drasticamente o tamanho do slot.
- Defina
statement_timeout e idle_in_transaction_session_timeout com valores razoáveis para evitar que transações permaneçam abertas indefinidamente:
SELECT
pid,
state,
age(now(), xact_start) AS transaction_duration,
query AS current_query
FROM
pg_stat_activity
WHERE
xact_start IS NOT NULL
ORDER BY
age(now(), xact_start) DESC;
-
Operações de manutenção ou utilitárias (por exemplo,
pg_repack)
- Ferramentas como
pg_repack podem reescrever tabelas inteiras, gerando grandes volumes de dados de WAL em pouco tempo.
- Programe essas operações para períodos de menor tráfego ou monitore de perto o uso de WAL enquanto elas estiverem em execução.
-
VACUUM e VACUUM ANALYZE
- Embora sejam necessários para a saúde do banco de dados, esses procedimentos podem gerar tráfego adicional de WAL, especialmente se fizerem varredura em tabelas grandes.
- Considere usar parâmetros de ajuste do autovacuum ou programar operações manuais de VACUUM fora dos horários de pico.
-
O consumidor de replicação não está lendo o slot ativamente
- Se o seu pipeline de CDC (por exemplo, ClickPipes) ou outro consumidor de replicação parar, ficar pausado ou falhar, os dados de WAL se acumularão no slot.
- Garanta que seu pipeline esteja em execução contínua e verifique os logs em busca de erros de conectividade ou authentication.
Para um excelente aprofundamento neste tema, confira nosso post no blog: Overcoming Pitfalls of Postgres Logical Decoding.
Como os tipos de dados do Postgres são mapeados para o ClickHouse?
Posso definir meu próprio mapeamento de tipos de dados ao replicar dados do Postgres para o ClickHouse?
Como as colunas JSON e JSONB são replicadas do Postgres?
- Para a sincronização, se ela for cancelada no meio do processo, o confirmed_flush_lsn no Postgres não é avançado, então a próxima sincronização começará da mesma posição da que foi abortada, garantindo a consistência dos dados.
- Para a normalização, a ordem de insert do ReplacingMergeTree lida com a desduplicação.
Em resumo, embora os processos de sincronização e normalização sejam encerrados durante uma pausa, isso é seguro, pois eles podem ser retomados sem perda de dados nem inconsistências.
A criação de ClickPipe pode ser automatizada ou feita por meio da API ou da CLI?
Como acelerar a carga inicial?
snapshot number of tables in parallel ou especificar uma coluna de particionamento personalizada e indexada para tabelas grandes.
Como devo delimitar o escopo das minhas publicações ao configurar a replicação?
REPLICA IDENTITY FULL. Se houver tabelas sem chave primária, criar uma publicação para todas as tabelas fará com que as operações DELETE e UPDATE falhem nessas tabelas.
Para identificar tabelas sem chaves primárias no seu banco de dados, você pode usar esta consulta:
SELECT table_schema, table_name
FROM information_schema.tables
WHERE
(table_catalog, table_schema, table_name) NOT IN (
SELECT table_catalog, table_schema, table_name
FROM information_schema.table_constraints
WHERE constraint_type = 'PRIMARY KEY') AND
table_schema NOT IN ('information_schema', 'pg_catalog', 'pgq', 'londiste');
-
Excluir do ClickPipes as tabelas sem chaves primárias:
Crie a publicação apenas com as tabelas que têm chave primária:
CREATE PUBLICATION clickpipes_publication FOR TABLE table_with_primary_key1, table_with_primary_key2, ...;
-
Incluir no ClickPipes as tabelas sem chaves primárias:
Se quiser incluir tabelas sem chave primária, você precisará alterar a identidade da réplica delas para
FULL. Isso garante que as operações de UPDATE e DELETE funcionem corretamente:
ALTER TABLE table_without_primary_key1 REPLICA IDENTITY FULL;
ALTER TABLE table_without_primary_key2 REPLICA IDENTITY FULL;
CREATE PUBLICATION clickpipes_publication FOR TABLE <...>, <...>;
Se você estiver criando uma publicação manualmente, em vez de deixar o ClickPipes gerenciá-la, não recomendamos criar uma publicação FOR ALL TABLES, pois isso gera mais tráfego do Postgres para o ClickPipes (ao enviar alterações de outras tabelas que não estão no pipe) e reduz a eficiência geral.Em publicações criadas manualmente, adicione à publicação todas as tabelas desejadas antes de adicioná-las ao pipe.
Se você estiver replicando a partir de uma réplica de leitura/hot standby do Postgres, precisará criar sua própria publicação na instância primária, que será propagada automaticamente para o standby. Nesse caso, o ClickPipe não poderá gerenciar a publicação, pois não é possível criar publicações em um standby.
Configurações recomendadas de max_slot_wal_keep_size
- No mínimo: defina
max_slot_wal_keep_size para reter pelo menos dois dias de dados de WAL.
- Para bancos de dados grandes (alto volume de transações): retenha pelo menos 2 a 3 vezes o pico diário de geração de WAL.
- Para ambientes com restrição de armazenamento: ajuste esse parâmetro de forma conservadora para evitar o esgotamento do disco, garantindo ao mesmo tempo a estabilidade da replicação.
Como calcular o valor ideal
Para PostgreSQL 10+
SELECT pg_wal_lsn_diff(pg_current_wal_insert_lsn(), '0/0') / 1024 / 1024 AS wal_generated_mb;
Para PostgreSQL 9.6 e versões anteriores:
SELECT pg_xlog_location_diff(pg_current_xlog_insert_location(), '0/0') / 1024 / 1024 AS wal_generated_mb;
- Execute a consulta acima em diferentes horários do dia, especialmente durante períodos de alta atividade transacional.
- Calcule quanto WAL é gerado em um período de 24 horas.
- Multiplique esse número por 2 ou 3 para garantir retenção suficiente.
- Defina
max_slot_wal_keep_size com o valor resultante em MB ou GB.
Exemplo
Se o seu banco de dados gera 100 GB de WAL por dia, defina:
max_slot_wal_keep_size = 200GB
Estou vendo um erro ReceiveMessage EOF nos logs. O que isso significa?
ReceiveMessage é uma função do protocolo de logical decoding do Postgres que lê mensagens do stream de replicação. Um erro EOF (End of File) indica que a conexão com o servidor Postgres foi encerrada inesperadamente ao tentar ler do stream de replicação.
É um erro recuperável e totalmente não fatal. O ClickPipes tentará se reconectar automaticamente e retomar o processo de replicação.
Isso pode acontecer por alguns motivos:
- Problemas de rede: Interrupções temporárias na rede podem fazer a conexão cair.
- Reinicialização do servidor Postgres: Se o servidor Postgres for reiniciado ou falhar, a conexão será perdida.
Meu slot de replicação foi invalidado. O que devo fazer?
max_slot_wal_keep_size no seu banco de dados PostgreSQL (por exemplo, alguns gigabytes). Recomendamos aumentar esse valor. Consulte esta seção sobre o ajuste de max_slot_wal_keep_size. O ideal é configurá-lo para pelo menos 200 GB para evitar a invalidação do slot de replicação.
Em casos raros, vimos esse problema ocorrer mesmo quando max_slot_wal_keep_size não está configurado. Isso pode ser causado por um bug raro e complexo no PostgreSQL, embora a causa exata permaneça incerta.
Estou vendo erros de falta de memória (OOMs) no ClickHouse enquanto meu ClickPipe está ingerindo dados. Podem ajudar?
-
Uma técnica comum de otimização para JOINs é quando você tem um
LEFT JOIN em que a tabela do lado direito é muito grande. Nesse caso, reescreva a consulta para usar um RIGHT JOIN e mova a tabela maior para o lado esquerdo. Isso permite que o planejador de consultas seja mais eficiente em termos de memória.
-
Outra otimização para JOINs é filtrar explicitamente as tabelas por meio de
subqueries ou CTEs e, em seguida, executar o JOIN entre essas subconsultas. Isso dá ao planejador indicações de como filtrar linhas com eficiência e executar o JOIN.
Estou vendo um invalid snapshot identifier durante a carga inicial. O que devo fazer?
invalid snapshot identifier ocorre quando há uma queda na conexão entre o ClickPipes e seu banco de dados Postgres. Isso pode acontecer devido a timeouts no gateway, reinicializações do banco de dados ou outros problemas transitórios.
Recomenda-se não realizar operações disruptivas, como upgrades ou reinicializações, no seu banco de dados Postgres enquanto a carga inicial estiver em andamento, e garantir que a conexão de rede com o banco esteja estável.
Para resolver esse problema, você pode acionar uma ressincronização pela UI do ClickPipes. Isso reiniciará o processo de carga inicial desde o início.
O que acontece se eu excluir uma publicação no Postgres?
- Crie uma nova publicação com o mesmo nome e as tabelas necessárias no Postgres
- Clique no botão ‘Resync tables’ na aba Settings do seu ClickPipe
Essa ressincronização é necessária porque a publicação recriada terá um identificador de objeto (OID) diferente no Postgres, mesmo que tenha o mesmo nome. O processo de ressincronização atualiza suas tabelas de destino e restaura a conexão.
Como alternativa, você pode criar um pipe totalmente novo, se preferir.
Observe que, se você estiver trabalhando com tabelas particionadas, certifique-se de criar sua publicação com as configurações apropriadas:
CREATE PUBLICATION clickpipes_publication
FOR TABLE <...>, <...>
WITH (publish_via_partition_root = true);
E se eu estiver vendo erros Unexpected Datatype ou Cannot parse type XX ...
Estou recebendo erros como invalid memory alloc request size <XXX> durante a replicação/criação de slot
Preciso manter um histórico completo no ClickHouse, mesmo quando os dados forem excluídos do banco de dados Postgres de origem. Posso ignorar completamente as operações DELETE e TRUNCATE do Postgres no ClickPipes?
CREATE PUBLICATION <pub_name> FOR TABLES IN SCHEMA <schema_name> WITH (publish = 'insert,update');
Por que não consigo replicar minha tabela que tem um ponto no nome?
A carga inicial foi concluída, mas não há dados ou estão faltando dados no ClickHouse. Qual pode ser o problema?
- Se o usuário tem permissões suficientes para ler as tabelas de origem.
- Se há políticas de linha no ClickHouse que possam estar filtrando linhas.
Sim, em um ClickPipe do Postgres com modo de replicação CDC ou Snapshot + CDC, você pode fazer com que o ClickPipes crie um slot de replicação com failover habilitado ativando a opção abaixo na seção Advanced Settings ao criar o ClickPipe. Observe que sua versão do Postgres deve ser 17 ou superior para usar esse recurso.
Se a origem estiver configurada adequadamente, o slot será preservado após failovers para uma réplica de leitura do Postgres, garantindo a replicação contínua dos dados. Saiba mais aqui.
Estou vendo erros como Internal error encountered during logical decoding of aborted sub-transaction
ReorderBufferPreserveLastSpilledSnapshot, isso indica que a logical decoding não está conseguindo ler o snapshot gravado em disco. Pode valer a pena tentar aumentar o logical_decoding_work_mem para um valor mais alto.
Estou vendo erros como error converting new tuple to map ou error parsing logical message durante a replicação por CDC
Posso incluir colunas que inicialmente excluí da replicação?
Estou percebendo que meu ClickPipe entrou em Snapshot, mas os dados não estão entrando. Qual pode ser o problema?
O snapshot paralelo está demorando para obter partições
A criação do replication slot está bloqueada por uma transação
CREATE_REPLICATION_SLOT travada no estado Lock. Isso pode acontecer porque outra transação está mantendo bloqueios em objetos que o Postgres usa para criar replication slots.
Para ver as consultas que estão causando o bloqueio, você pode executar a consulta abaixo na sua origem Postgres:
SELECT
blocked.pid AS blocked_pid,
blocked.query AS blocked_query,
blocking.pid AS blocking_pid,
blocking.query AS blocking_query,
blocking.state AS blocking_state
FROM pg_locks blocked_lock
JOIN pg_stat_activity blocked
ON blocked_lock.pid = blocked.pid
JOIN pg_locks blocking_lock
ON blocking_lock.locktype = blocked_lock.locktype
AND blocking_lock.database IS NOT DISTINCT FROM blocked_lock.database
AND blocking_lock.relation IS NOT DISTINCT FROM blocked_lock.relation
AND blocking_lock.page IS NOT DISTINCT FROM blocked_lock.page
AND blocking_lock.tuple IS NOT DISTINCT FROM blocked_lock.tuple
AND blocking_lock.virtualxid IS NOT DISTINCT FROM blocked_lock.virtualxid
AND blocking_lock.transactionid IS NOT DISTINCT FROM blocked_lock.transactionid
AND blocking_lock.classid IS NOT DISTINCT FROM blocked_lock.classid
AND blocking_lock.objid IS NOT DISTINCT FROM blocked_lock.objid
AND blocking_lock.objsubid IS NOT DISTINCT FROM blocked_lock.objsubid
AND blocking_lock.pid != blocked_lock.pid
JOIN pg_stat_activity blocking
ON blocking_lock.pid = blocking.pid
WHERE NOT blocked_lock.granted;
