Características do 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.

Suporte à versão¶

O Snowflake Connector for PostgreSQL é compatível com qualquer versão do PostgreSQL com suporte oficial. O Snowflake descontinua o suporte para versões mais antigas à medida que os clientes passam para versões mais recentes. O Snowflake anuncia o suporte para novas versões conforme elas são lançadas.

Embora o conector ofereça suporte a uma série de versões do PostgreSQL na nuvem, algumas exigem configurações adicionais. Consulte Pré-requisitos para fontes de dados do Snowflake Connector for PostgreSQL para obter mais informações.

A seguir, as versões compatíveis do PostgresSQL.

Versões PostgreSQL compatíveis¶
	11	12	13	14	15	16	17
Padrão	Sim	Sim	Sim	Sim	Sim	Sim	Sim
AWS RDS	Sim	Sim	Sim	Sim	Sim	Sim	Sim
Amazon Aurora	Sim	Sim	Sim	Sim	Sim	Sim
GCP Cloud SQL	Sim	Sim	Sim	Sim	Sim	Sim
Banco de dados do Azure	Sim	Sim	Sim	Sim	Sim	Sim

Configurações do servidor¶

Revise e ajuste as seguintes configurações no servidor PostgreSQL conforme necessário:

`wal_level`	Defina como `logical`. O conector depende de chaves primárias para fazer a fusão das alterações nas tabelas de destino. As configurações a seguir garantem que o log de gravação antecipada (WAL) incluam as informações da chave primária:
`max_replication_slots`	Adicione 1 para cada entrada de configuração da fonte referente a este banco de dados no agente.
`max_connections`	Adicione 1 para cada entrada de configuração da fonte referente a este banco de dados no agente.
`max_wal_senders`	Adicione 1 para cada entrada de configuração da fonte referente a este banco de dados no agente.

Publicações¶

O conector requer uma publicação do PostgreSQL para acessar tabelas para replicação.

O agente de banco de dados oferece suporte a exatamente uma publicação por fonte de dados. Se você precisar usar várias publicações em um único servidor PostgreSQL, pode configurar esse servidor várias vezes como fontes separadas de dados, cada uma com sua própria publicação.
A publicação deve incluir todas as mudanças feitas nos dados, incluindo INSERT, UPDATE, DELETE e TRUNCATE.
A publicação pode ser configurada para ALL TABLES ou um subconjunto de tabelas, mas para um desempenho ideal, adicione apenas as tabelas que devem ser replicadas. O conector só receberá alterações das tabelas incluídas na publicação.
As tabelas podem ser adicionadas à publicação com todas as colunas ou um subconjunto delas. Ao adicionar com um subconjunto de colunas, use o procedimento ADD_TABLE_WITH_COLUMNS.

Aviso

Quando uma tabela é adicionada a uma publicação com um subconjunto de colunas, mas depois habilitada para replicação usando o procedimento ADD_TABLES, as colunas ausentes na publicação serão marcadas na tabela de destino como excluídas. Se qualquer outra coluna for adicionada à publicação posteriormente, a tabela será permanentemente marcada como falha.

Para mais informações sobre a configuração da conexão, consulte Configuração da publicação.

Slots de replicação¶

Para replicar alterações de dados e esquema, o conector cria um slot de replicação. O slot é criado quando a primeira tabela em uma determinada fonte de dados é adicionada à replicação. Ele é usado para todas as tabelas dessa fonte de dados.

O nome do slot segue a estrutura sf_db_conn_rs_kbmd_<data-source-name>, em que <data-source-name> é o identificador da fonte de dados na configuração do agente do banco de dados.

Se você configurar o agente para se conectar ao mesmo banco de dados várias vezes, adicionando várias fontes, o conector criará vários espaços de replicação.
Se você configurar vários agentes de banco de dados para se conectarem ao mesmo servidor PostgreSQL, será necessário fornecer nomes de fontes exclusivos para cada agente de banco de dados.

Cuidado

O agente de banco de dados não remove intervalos de replicação não utilizados. Se você desconectar o agente de banco de dados de uma instâncias do PostgreSQL ou remover todas as suas tabelas da replicação, você também precisa remover manualmente o slot de replicação para impedir que ele atrase o corte WAL.

Posição do slot de replicação e crescimento WAL¶

Depois de criado, um slot de replicação fará o PostgreSQL reter os dados WAL da posição mantida pelo slot de replicação, até que o conector confirme e avance para essa posição. O conector confirma periodicamente a posição após os registros terem sido armazenados nas tabelas de diário, mesmo que ainda não tenham sido mesclados nas tabelas de destino.

No modo contínuo, o conector confirma a posição a cada minuto.
No modo agendado, o conector confirma a posição com base no cronograma configurado. Tenha em mente que cronogramas mais longos * farão com que o WAL cresça ainda mais*.

Você deve garantir que haja espaço em disco suficiente no servidor do PostgreSQL para o WAL. Se você detectar que o WAL está crescendo de forma contínua, verifique o seguinte:

O agente de banco de dados está conectado e o conector está replicando dados ativamente? Caso contrário, o slot de replicação não está sendo avançado, bloqueando os cortes no WAL.
A replicação está acompanhando as alterações de dados nas tabelas replicadas? Caso contrário, ou seja, se o atraso entre uma alteração de dados na fonte e o surgimento deles na tabela de destino do Snowflake continuar aumentando, o slot de replicação está avançando lentamente demais. Você precisa remover algumas tabelas da replicação ou aumentar o tamanho do warehouse de computação.

A configuração max_wal_size no PostgreSQL não terá efeito sobre o crescimento do WAL se a causa for a falta de avanço de um slot de replicação.

Dica

Em situações críticas, você pode descartar manualmente o slot de replicação usado pelo conector. Isso interromperá qualquer replicação em execução no conector, mas permitirá que o PostgreSQL corte o WAL e recupere espaço em disco.

Chaves primárias e identidade de réplica de tabela¶

O conector depende de chaves primárias para mesclar alterações nas tabelas de destino. Como resultado:

Cada tabela habilitada para replicação deve ter uma chave primária. A chave pode ser uma coluna única ou composta.
As tabelas também devem ter o parâmetro REPLICA IDENTITY definido como DEFAULT. Isso garante que as chaves primárias sejam representadas no WAL e que o conector poderá lê-las.

Autenticação do agente¶

O único método de autenticação compatível atualmente é nome de usuário e senha. Cada entrada de fonte de dados na configuração do agente de banco de dados inclui seu próprio conjunto de credenciais, e elas podem variar entre as fontes de dados.

Os usuários do agente de banco de dados devem ter uma função com o atributo REPLICATION ou SUPERUSER se o primeiro não puder ser aplicado.

Para instruções sobre como criar um usuário para o agente de banco de dados, consulte Criação do usuário necessário.

Para mais informações sobre como proteger o acesso do agente aos bancos de dados de origem, consulte a documentação do PostgreSQL.