Características Snowflake Connector for PostgreSQL¶

Suporte à versão¶

O Snowflake Connector for PostgreSQL é compatível com qualquer versão do PostgreSQL suportada oficialmente. A Snowflake deixa de oferecer suporte a versões mais antigas à medida que os clientes migram para versões mais recentes. A Snowflake anuncia o suporte a novas versões à medida que elas são lançadas.

Embora o conector seja compatível com várias versões da nuvem PostgreSQL, 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¶

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

`wal_level`	Defina como `logical`. O conector se baseia em chaves primárias para mesclar as alterações nas tabelas de destino. As configurações a seguir garantem que os registros do Write-Ahead Log (WAL) incluam informações de chave primária:
`max_replication_slots`	Adicione 1 para cada entrada de configuração de fonte de dados para esse banco de dados no agente de banco de dados.
`max_connections`	Adicione 1 para cada entrada de configuração de fonte de dados para esse banco de dados no agente de banco de dados.
`max_wal_senders`	Adicione 1 para cada entrada de configuração de fonte de dados para esse banco de dados no agente de banco de dados.

Publicações¶

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

O agente de banco de dados suporta exatamente uma publicação por fonte de dados. Se precisar usar várias publicações em um único servidor PostgreSQL, você pode configurar esse servidor várias vezes como fontes de dados separadas, cada uma com sua própria publicação.
A publicação deve incluir todas as alterações feitas nos dados, incluindo INSERT, UPDATE, DELETE e TRUNCATE.
A publicação pode ser configurada para ALL TABLES ou para um subconjunto de tabelas, mas, para obter o melhor desempenho, 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 suas colunas ou com um subconjunto de colunas. 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. A inclusão posterior de colunas adicionais à publicação fará com que a tabela seja marcada como permanentemente com falha.

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

Slots de replicação¶

Para replicar dados e alterações de 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 e usada para todas as tabelas dessa fonte de dados.

O nome do slot é estruturado como 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 de banco de dados para se conectar ao mesmo banco de dados várias vezes, adicionando várias fontes de dados, o conector criará vários slots de replicação.
Se você configurar vários agentes de banco de dados para se conectarem ao mesmo servidor PostgreSQL, deverá fornecer nomes de fonte de dados exclusivos a cada agente de banco de dados.

Cuidado

O agente de banco de dados não remove slots de replicação não utilizados. Se você desconectar o agente de banco de dados de uma instância PostgreSQL ou remover todas as suas tabelas da replicação, deverá obrigatoriamente também descartar manualmente o slot de replicação para evitar que ele atrase o corte de WAL.

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

Uma vez criado, um slot de replicação fará com que o PostgreSQL retenha os dados do WAL da posição mantida pelo slot de replicação, até que o conector confirme e avance essa posição. O conector confirma periodicamente a posição depois que os registros foram armazenados em suas 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 programado, o conector confirma a posição com base no cronograma configurado. Lembre-se de que cronogramas mais longos farão com que o WAL fique maior.

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

O agente do 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 e bloqueia o corte de WAL.
A replicação está acompanhando as alterações de dados nas tabelas replicadas? Caso contrário, o que significa que o atraso entre uma alteração de dados na origem e seu aparecimento na tabela de destino do Snowflake continua aumentando, então o slot de replicação está sendo avançado muito lentamente. Você precisa remover algumas tabelas da replicação ou aumentar o tamanho do warehouse de computação.

A configuração max_wal_size em PostgreSQL não terá efeito sobre o crescimento de WAL quando for causado pelo não avanço de um slot de replicação.

Dica

Em situações críticas, você pode retirar 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 da réplica da tabela¶

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

Toda 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 seu REPLICA IDENTITY definido como DEFAULT. Isso garante que as chaves primárias sejam representadas no WAL e que o conector possa lê-las.

Autenticação de agentes¶

O único método de autenticação suportado atualmente é o nome de usuário e a 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 obter instruções sobre como criar um usuário para o agente de banco de dados, consulte Criação do usuário necessário.

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