Sobre Snowflake Connector for PostgreSQL

Nota

O Snowflake Connector for PostgreSQL está sujeito aos Termos do conector.

O Snowflake Connector for PostgreSQL permite:

  • Carregar dados no Snowflake a partir de um banco de dados PostgreSQL.

  • Configure a replicação para que as alterações em seu banco de dados PostgreSQL sejam replicadas para o Snowflake.

Para manipular conexões entre Snowflake e PostgreSQL, o conector usa um agente. O agente é distribuído como uma imagem Docker. O agente é executado em sua rede e é usado para enviar por push dados para sua conta Snowflake.

Nota

O Snowflake Connector for PostgreSQL requer que exatamente uma instância do aplicativo agente esteja em execução o tempo todo.

As atualizações incrementais em andamento usam a técnica de captura de dados de alteração (CDC) que obtém as alterações realizadas no banco de dados de origem. As alterações incluem operações INSERT, UPDATE e DELETE, que são replicadas automaticamente no banco de dados de destino Snowflake.

Várias instâncias de aplicativos

É possível instalar várias instâncias do Snowflake Connector for PostgreSQL em sua conta Snowflake. Para obter mais informações, consulte Opcional: Instalação de múltiplas instâncias de Snowflake Connector for PostgreSQL.

Compatibilidades de aplicativo do Agent e conector

O Snowflake Connector for PostgreSQL está sendo lançado em uma versão específica, descrita como versão x.y.z, onde x é a versão principal, y é a secundária e z é o patch. Os Agents no dockerhub também são lançados com a versão X.Y.Z. Cada versão x.y.z do Snowflake Connector for PostgreSQL oferece suporte a todos os agentes com a mesma versão principal X=x e não a uma versão secundária maior do agente. Além disso, cada versão x.0.0 do Snowflake Connector for PostgreSQL oferece suporte a todas as versões (x-1).Y.Z do agente para todas as versões Y e Z.

Limitações conhecidas

As seções a seguir descrevem as limitações conhecidas do conector.

Incompatibilidade das réplicas de leitura

Devido às limitações do PostgreSQL, a replicação lógica não é compatível em réplicas, portanto, o Snowflake Connector for PostgreSQL deve ser conectado somente ao banco de dados primário.

Número máximo de tabelas

O conector funciona bem com até 200 tabelas de origem adicionadas à replicação. Adicionar mais tabelas pode fazer com que o conector fique instável.

Disponibilidade do conector

Ao instalar o conector, observe as seguintes limitações:

  • As contas nas regiões governamentais não são suportadas.

  • Para instalar e configurar o conector, você deve estar conectado como um usuário com a função ACCOUNTADMIN. Outras funções não são suportadas neste momento.

Compatibilidade de tipos

Devido às diferenças entre o banco de dados de origem e os tipos de coluna Snowflake, alguns valores não podem ser convertidos e gravados no Snowflake devido à capacidade máxima da coluna ou aos intervalos permitidos. Por exemplo:

  • O tipo Snowflake BINARY tem um comprimento máximo de 8 MB (8.388.608 bytes)

  • Os tipos de data em Snowflake, como DATE, DATETIME e TIMESTAMP, têm um ano máximo de 9999

  • O tipo Snowflake VARCHAR tem um comprimento máximo de 16 MB (16.777.216 bytes)

Se tal incompatibilidade ocorrer, a replicação de uma tabela será interrompida com uma falha.

Alterações no esquema de tabela de origem

A tabela a seguir mostra diferentes tipos de alterações no esquema de tabela de origem, se elas são compatíveis e, em caso afirmativo, como.

Novos nomes de coluna estão sujeitos às mesmas limitações descritas na seção Limitações de identificadores.

Tipo de alteração de esquema

Tem suporte?

Notas

Adicionando uma nova coluna

Sim

A nova coluna ficará visível na tabela de destino como qualquer outra coluna existente no início da replicação.

Não é possível adicionar uma nova coluna com o mesmo nome de uma coluna excluída ou renomeada anteriormente.

Por exemplo, se as colunas A e B existiam inicialmente, mas A foi excluída e B foi renomeada para B2 – não é possível adicionar uma coluna nomeada A ou B.

Excluindo uma coluna existente

Sim

Se uma coluna for excluída na tabela de origem, ela não será excluída na tabela de destino. Em vez disso, uma abordagem de exclusão suave é seguida e a coluna será renomeada para <o nome anterior>__SNOWFLAKE_DELETED para que os valores históricos ainda possam ser consultados. Todas as linhas replicadas após a exclusão da coluna terão um valor NULL nesta coluna.

Por exemplo, se a coluna A for excluída, ela será renomeada para A__SNOWFLAKE_DELETED na tabela de destino, e o conteúdo da coluna permanecerá inalterado.

Como renomear uma coluna

Sim

Renomear uma coluna é o mesmo que excluir a coluna e criar uma nova com o novo nome. A exclusão segue a abordagem de exclusão suave explicada na linha anterior.

Por exemplo, se a coluna A foi renomeada para B, na tabela de destino, A foi renomeada para A__SNOWFLAKE_DELETED, e uma nova coluna B foi adicionada. Todas as linhas existentes antes da alteração mantêm os valores da coluna na coluna A__SNOWFLAKE_DELETED, enquanto as novas linhas adicionadas após a alteração mantêm os valores na coluna B.

Não é possível renomear uma coluna com o mesmo nome de uma coluna excluída ou renomeada anteriormente. Por exemplo, se as colunas A, B e C existiam inicialmente, mas A foi excluída e B foi renomeada para B2, não é possível renomear a coluna C para A ou B.

Alterando o tipo de coluna

Parcialmente

Alterar o tipo de coluna da tabela de origem só é possível se o tipo anterior e o novo forem mapeados para o mesmo tipo no Snowflake.

Em qualquer outro caso, a replicação falhará permanentemente.

Alteração da precisão de uma coluna numérica

Não

Alterar a precisão de uma coluna da tabela de origem resultará em falha permanente na replicação.

Alteração da escala de uma coluna numérica

Não

Alterar a escala de uma coluna da tabela de origem resultará em falha permanente na replicação.

Alterando a definição da chave primária

Não

Alterar a definição da chave primária da coluna da tabela de origem resultará na falha permanente da replicação.

Colunas de alta capacidade

Um agente ativo lê continuamente todos os eventos usando o mecanismo de replicação lógica, mesmo que alguns eventos se refiram a tabelas de origem que não foram adicionadas para replicação. Se a replicação lógica contiver eventos muito grandes, como atualizações de colunas do tipo TEXT, o agente poderá travar devido à falta de memória disponível.

Chaves primárias

Tabelas sem chaves primárias não são compatíveis.

Limitações dos identificadores

Atualmente, o conector não oferece suporte ao caractere " em nomes de esquema, tabela ou coluna replicados. Além disso, as seguintes palavras-chave não são compatíveis:

Para nomes de esquema:

  • INFORMATION_SCHEMA

Para nomes de coluna:

PostgreSQL versão 11 ou posterior

Atualmente, o conector depende da propriedade de configuração wal_level = logical introduzida na versão 11 do PostgreSQL.

Configuração de identidade de réplica

A identidade de réplica das tabelas replicadas deve ser definida como DEFAULT.

Valores TOAST

A replicação de tabelas com valores TOAST não é compatível atualmente. Isso inclui a adição de colunas compatíveis com TOAST ao esquema de origem quando a replicação já estiver em execução.

Autorização do banco de dados de origem

A autorização de chave privada para o banco de dados de origem não é compatível. Somente autorização via usuário e senha é compatível.

Identidade de réplica

A identidade de réplica de uma determinada tabela deve ser a mesma da chave primária, caso contrário a replicação falhará.

Linguagem: Português