Limitações do conector PostgreSQL

Esta página lista as limitações e considerações para a ingestão do PostgreSQL usando o Databricks Lakeflow Connect.

Limitações gerais do conector do banco de dados

As limitações nesta seção se aplicam a todos os conectores de banco de dados no Lakeflow Connect. Continue lendo para ver as limitações específicas do conector.

• Quando você executa um pipeline agendado, os alertas não são acionados imediatamente. Em vez disso, eles são acionados quando a próxima atualização é executada.
• Quando uma tabela de origem é excluída, a tabela de destino não é excluída automaticamente. Você deve excluir a tabela de destino manualmente. Esse comportamento não é consistente com o comportamento do Lakeflow Spark Declarative Pipelines.
• Durante os períodos de manutenção de origem, o Databricks pode não conseguir acessar seus dados.
• Se um nome de tabela de origem entrar em conflito com um nome de tabela de destino existente, a atualização do pipeline falhará.
• O suporte a pipeline para múltiplos destinos é somente através da API.
• Opcionalmente, você pode renomear uma tabela ingerida. Se você renomear uma tabela em seu pipeline, ela se tornará um pipeline somente de API e você não poderá mais editar o pipeline na interface do usuário.
• Se você selecionar uma coluna depois que um pipeline já tiver iniciado, o conector não preencherá automaticamente os dados da nova coluna. Para ingerir dados históricos, execute manualmente uma atualização completa na tabela.
• O Databricks não pode ingerir duas ou mais tabelas com o mesmo nome no mesmo pipeline, mesmo que elas venham de esquemas de origem diferentes.
• O sistema de origem assume que as colunas do cursor estão aumentando monotonicamente.

• Não há suporte para pipelines de ingestão gerenciados para espaços de trabalho em regiões do Azure GovCloud.

• Com o SCD tipo 1 habilitado, as exclusões não produzem um evento explícito delete no feed de dados de alteração. Para exclusões auditáveis, use SCD tipo 2 se o conector oferecer suporte a ele. Para obter detalhes, consulte Exemplo: processamento de SCD tipo 1 e SCD tipo 2 com dados de origem CDF.

• O conector só suporta replicação a partir das instâncias primárias do PostgreSQL.

Authentication

• O conector suporta apenas autenticação de nome de usuário e senha.

Variações do banco de dados

• O conector suporta PostgreSQL 13 ou superior.
• O conector suporta AWS RDS PostgreSQL, Aurora PostgreSQL, Amazon EC2, Azure Database para PostgreSQL, máquinas virtuais Azure e GCP Cloud SQL para PostgreSQL. O conector também suporta PostgreSQL local usando Azure ExpressRoute, AWS Direct Connect e redes VPN.

Tubulações

• Cada pipeline de entrada deve estar associado a exatamente um gateway de entrada.
• Embora o pipeline de ingestão seja executado em computação sem servidor, o gateway de ingestão deve ser executado em computação clássica.
• O gateway de ingestão tem de funcionar em modo contínuo para evitar o aumento excessivo do Write-Ahead Log (WAL) e o acúmulo de ranhuras de replicação.

Replication

• A replicação lógica requer PostgreSQL 13 ou superior com o wal_level parâmetro definido como logical.

• Cada tabela que replicar deve ter a sua identidade de réplica definida como FULL ou DEFAULT. O Databricks recomenda usar FULL identidade réplica para tabelas sem chaves primárias ou com colunas TOASTable.
• Os slots de replicação não são removidos automaticamente quando se apagam pipelines. Tens de limpar manualmente os espaços de replicação para evitar o acúmulo de WAL. Consulte Limpeza dos slots de replicação.

Evolução do esquema

O conector trata automaticamente colunas novas e eliminadas.

• Quando uma nova coluna aparece na fonte, o Databricks ingere-a automaticamente na próxima execução do pipeline.
• Quando uma coluna é eliminada da fonte, o Databricks não a apaga automaticamente. Em vez disso, o conector usa uma propriedade de tabela para definir a coluna excluída como inactive no destino. Se aparecer mais tarde outra coluna com um nome conflitante com a inactive coluna, o pipeline falhará. Neste caso, execute uma atualização completa da tabela ou retire manualmente a coluna inativa.

O conector pode gerir os DDLs mencionados abaixo (por exemplo, renomeações de colunas), mas requer uma atualização completa das tabelas de destino.

As DDLs requerem uma atualização completa

• Alterar o tipo de dados de uma coluna
• Renomear uma coluna
• Alterar a chave primária de uma tabela
• Converter uma tabela de não logada para logada ou vice-versa
• Adição ou remoção de partições (para tabelas particionadas)

Staging

O catálogo de preparação não pode ser um catálogo estrangeiro.

Tables

• A Databricks recomenda a ingestão de no máximo 250 tabelas por pipeline. No entanto, não há limite para o número de linhas ou colunas suportadas nestas tabelas.
• Os Databricks não podem ingerir duas tabelas cujos nomes diferem apenas no caso (por exemplo, mytable e MyTable) usando um único pipeline. Para suportar estes casos, crie dois pares de pipeline de gateway e ingestão que publiquem em esquemas alvo diferentes.
• Os source_catalog, source_schema e source_table devem ser diferenciados por maiúsculas e minúsculas para o nome da base de dados, mas não distinguem maiúsculas de minúsculas para os nomes de esquemas e tabelas (seguindo o comportamento padrão do PostgreSQL). Por exemplo, se a base de dados de origem for nomeada MyDatabase, deve especificá-la como MyDatabase no ingestion_definition.
• Embora possa ingerir de várias bases de dados ou esquemas de origem num pipeline, não pode ingerir duas tabelas com o mesmo nome. Por exemplo, não pode ingerir tanto schema1.orders como schema2.orders no mesmo pipeline.
• Pode incluir múltiplas especificações de tabelas ou esquemas no objects campo do ingestion_definition. No entanto, os nomes das tabelas fonte em diferentes esquemas fonte não podem sobrepor-se. Nomes sobrepostos resultam na falha do pipeline de ingestão.

Tipos de dados

• Tipos definidos pelo utilizador e tipos de extensão de terceiros são lidos como cadeias de caracteres.
• Os TIME tipos de dados e TIMETZ são ingeridos como cadeias de caracteres.
• Qualquer tipo de dado incorporado do PostgreSQL que não esteja listado na tabela de transformações automáticas de dados é ingerido como string.
• Para o tipo de dado numérico: NaN é convertido em nulo.
• Para data e marca temporal: Não suportamos datas anteriores a Cristo ou posteriores a 9999 d.C.
• O Infinity não é suportado para data, carimbo temporal ou intervalo.

Tabelas particionadas

• São suportadas tabelas particionadas PostgreSQL.
• Cada partição é tratada como uma tabela separada para fins de replicação.
• Adicionar ou remover partições requer uma atualização completa da tabela.

Limitações para variações específicas do PostgreSQL

Amazon RDS e Aurora

• O rds.logical_replication parâmetro deve ser definido como 1.

Base de Dados do Azure para PostgreSQL

• A replicação lógica deve estar ativada nos parâmetros do servidor.
• Para implementações de Servidor Único, a replicação lógica só está disponível nos níveis de Propósito Geral e Otimizado para Memória.
• Para implementações de Servidores Flexíveis, a replicação lógica é suportada em todos os níveis.
• O max_wal_slot_keep_size parameter é apenas de leitura, fixo em -1 (infinito) e não pode ser configurado.

Google Cloud SQL para PostgreSQL

• A cloudsql.logical_decoding bandeira tem de estar ativada.
• Cloud SQL não permite configurar max_wal_slot_keep_size; é definido como -1 (infinito) por padrão.