Sobre Snowflake Connector for PostgreSQL¶
Importante
Agradecemos pelo seu interesse no conector Snowflake para PostgreSQL. Agora, estamos focados em uma solução de próxima geração que oferecerá uma experiência significativamente melhor. Portanto, no momento não temos planos de passar esse conector para o status de disponibilidade geral. Você pode continuar usando esse conector como um recurso em versão preliminar, mas o suporte para futuras correções de bugs e melhorias não é garantido. A nova solução está disponível como Conector Openflow para PostgreSQL e inclui melhor desempenho, personalização e opções aprimoradas de implantação.
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 do Snowflake Connector for PostgreSQL.
Links privados¶
O Snowflake Connector para PostgreSQL oferece suporte a links privados. Para obter mais informações, consulte:
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¶
Por causa das 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.
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¶
As diferenças entre o banco de dados de origem e os tipos de coluna Snowflake fazem com que alguns valores não possam 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 64 MB (67108864 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 128 MB (134217728 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 |
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 é adotada, e a coluna será renomeada para Por exemplo, se a coluna |
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 Não é possível renomear uma coluna com o mesmo nome de uma coluna excluída ou renomeada anteriormente. Por exemplo, se as colunas |
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 tiver eventos muito grandes, como atualizações de colunas do tipo TEXT, o agente poderá travar por causa da 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:
_SNOWFLAKE_INSERTED_AT
_SNOWFLAKE_UPDATED_AT
_SNOWFLAKE_DELETED
nomes com o sufixo
__SNOWFLAKE_DELETED
Nomes de coluna marcados como
Cannot be used as column name
em Palavras-chave reservadas e limitadas
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.
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á.