Perguntas Frequentes sobre conectores PostgreSQL

Esta página responde a perguntas frequentes sobre o conector PostgreSQL no Databricks Lakeflow Connect.

Perguntas frequentes gerais sobre conectores gerenciados

As respostas nas Perguntas frequentes sobre o conector gerenciado se aplicam a todos os conectores gerenciados no Lakeflow Connect. Continue a ler para consultar perguntas frequentes específicas do conector.

Como é que o Databricks se liga ao PostgreSQL?

O Databricks liga-se ao PostgreSQL usando segurança na camada de transporte (TLS) e uma ligação JDBC. Pipelines recém-criados também validam o certificado TLS do servidor para verificar a identidade do servidor. Para detalhes e opções de configuração, veja validação de certificados de servidor TLS. As credenciais são armazenadas de forma segura no Unity Catalog e só podem ser recuperadas se o utilizador que executa o fluxo de ingestão tiver as permissões apropriadas. O Databricks recomenda criar um utilizador de replicação separado no PostgreSQL para ingerir dados. Se existirem bases de dados ou tabelas que não queira expor a este utilizador, pode usar as permissões incorporadas do PostgreSQL.

Se o pipeline falhar, a ingestão será retomada sem perda de dados?

Yes. O Databricks acompanha o que o conector extraiu da origem e aplicou no destino. Se algo acontecer, o Databricks pode retomar nesse ponto desde que o slot de replicação e os dados do Write-Ahead Log (WAL) permaneçam na base de dados de origem. Isto pode ser afetado se o pipeline não for executado antes de atingidos os limites do período de retenção WAL ou dos slots de replicação, o que pode exigir uma atualização completa das tabelas de destino.

Que variações do PostgreSQL suporta o conector?

O conector suporta AWS RDS PostgreSQL, Aurora PostgreSQL, Amazon EC2, Azure Database para PostgreSQL, máquinas virtuais Azure e GCP Cloud SQL para PostgreSQL. Isto inclui o PostgreSQL a correr em máquinas virtuais. O conector também suporta PostgreSQL local usando Azure ExpressRoute, AWS Direct Connect e VPN, se houver largura de banda suficiente. Para detalhes sobre conectividade entre cloud, veja Conectividade de rede.

Como o conector extrai dados incrementalmente?

O conector utiliza a replicação lógica do PostgreSQL com o plugin pgoutput. A replicação lógica captura todas as operações de modificação de dados (inserções, atualizações e eliminações) através do Write-Ahead Log sem impacto significativo no desempenho da base de dados de origem.

O conector regista fusos horários para as colunas de data e hora?

O conector preserva a informação do fuso horário para as colunas TIMESTAMP WITH TIME ZONE. TIMESTAMP WITHOUT TIME ZONE e TIME as colunas são ingeridas como cadeias no seu formato original, sem conversão de fuso horário.

Posso personalizar o cronograma do gateway de ingestão?

Não, o gateway de ingestão tem de funcionar em modo contínuo. Isto é fundamental para o PostgreSQL evitar o inchaço do Write-Ahead Log (WAL) e garantir que os slots de replicação não acumulem alterações não consumidas. Se o gateway for parado por um período prolongado, o slot de replicação pode fazer com que ficheiros WAL se acumulem na base de dados de origem, potencialmente preenchendo o espaço em disco.

Como o conector lida com uma tabela sem uma chave primária?

O conector pode replicar tabelas sem chave primária se a identidade da réplica estiver definida para FULL. Neste caso, o conector trata todas as colunas, exceto objetos grandes, como uma chave primária agrupada. Se houver linhas duplicadas na tabela de origem, essas linhas são ingeridas como uma única linha na tabela de destino, a menos que ative o rastreio de histórico.

Com que frequência posso agendar a execução do pipeline de ingestão?

Não há limite para a frequência com que podes agendar a execução do pipeline de ingestão. No entanto, Databricks recomenda pelo menos 5 minutos entre os intervalos porque a computação serverless leva algum tempo a iniciar. O Databricks não suporta a execução do pipeline de ingestão em modo contínuo.

Porque não vejo todas as linhas do meu banco de dados na execução inicial do pipeline?

O gateway de ingestão extrai dados históricos e CDC assim que começa a ser executado. O pipeline de ingestão pode ser executado antes de todos esses dados terem sido extraídos, resultando em uma aplicação parcial de dados em tabelas de destino. Pode requerer várias execuções do pipeline de ingestão para que todos os dados sejam completamente extraídos e aplicados às tabelas alvo.

Posso ingerir de uma réplica de leitura ou de uma instância de espera?

Não. O suporte está limitado às instâncias primárias do PostgreSQL porque a replicação lógica não é suportada em réplicas de leitura ou instâncias de espera.

O que acontece com o slot de replicação quando apago um pipeline?

Quando elimina um pipeline de ingestão, o slot de replicação não é automaticamente removido da base de dados PostgreSQL de origem. Deve remover manualmente o slot de replicação para evitar a acumulação do Log de escrita antecipada (WAL). Para obter instruções sobre como limpar slots de replicação, consulte "Limpar slots de replicação".

Que versão do PostgreSQL é necessária?

O PostgreSQL 13 ou superior é obrigatório.

É obrigatório definir wal_level = logical para a ingestão do CDC?

Yes. O parâmetro wal_level deve ser definido para logical para permitir a replicação lógica.

Posso replicar tabelas de várias bases de dados PostgreSQL num só pipeline?

Yes. Pode especificar múltiplas bases de dados fonte no campo de source_catalogingestion_definition. No entanto, cada base de dados de origem requer a sua própria ligação ao Catálogo Unity e configuração de publicação.

Quantas tabelas posso ingerir num único pipeline?

A Databricks recomenda ingerir 250 ou menos tabelas por pipeline para um desempenho ótimo. No entanto, não existe um limite rígido para o número de linhas ou colunas suportadas por estes objetos.

O meu gateway de ingestão demora muito tempo a arrancar. Como faço para corrigi-lo?

Os gateways funcionam em computação clássica e provisionam uma máquina virtual (VM) em cada arranque. Se o arranque demorar mais do que alguns minutos, considere o seguinte:

• Altere para o canal atual do pipeline. Esta é a solução mais comum. As versões de canais de pré-visualização têm tempos de arranque mais longos. Podes alterar isto na interface do utilizador (nas definições avançadas do pipeline em Channel), ficheiro de recursos do pacote ou especificação do pipeline.
• Não reinicies o gateway entre as sessões de ingestão. O gateway foi concebido para funcionar de forma contínua. Parar e reiniciar reaprovisiona a VM a cada reinício e corre o risco de perder logs de alterações se a fonte os truncar enquanto o gateway está inativo.

Se o gateway ficar preso num estado inicial durante 15 minutos ou mais, crie um ticket de suporte.

Isto aplica-se apenas a portas de entrada. As canalizações de ingestão executam em computação baseada em Serverless e iniciam rapidamente.

O conector suporta tipos e extensões definidos pelo utilizador?

O conector suporta a maioria dos tipos de dados PostgreSQL, incluindo arrays e JSONB. Tipos definidos pelo utilizador e tipos de extensão de terceiros são lidos como cadeias de caracteres. Consulte a referência do conector PostgreSQL para uma lista completa de mapeamentos de tipos suportados.