Transmitir dados de bancos de dados PostgreSQL

Esta seção contém informações sobre:

  • O comportamento de como o Datastream lida com dados que estão sendo extraídos de um banco de dados PostgreSQL de origem
  • As versões do banco de dados PostgreSQL compatíveis com o Datastream
  • Uma visão geral de como configurar um banco de dados PostgreSQL de origem para que os dados possam ser transmitidos dele para um destino
  • Limitações conhecidas para o uso do banco de dados PostgreSQL como fonte

Comportamento

O banco de dados PostgreSQL de origem depende do recurso de decodificação lógica. A decodificação lógica expõe todas as mudanças confirmadas no banco de dados e permite consumir e processar essas mudanças em um formato fácil de usar com um plug-in de saída. O Datastream usa o plug-in pgoutput, que é o plug-in de decodificação lógica padrão do PostgreSQL para o PostgreSQL 10 e versões mais recentes.

  • É possível selecionar todos os esquemas ou esquemas específicos de uma determinada origem PostgreSQL, bem como todas as tabelas do esquema ou tabelas específicas.
  • Todos os dados históricos são replicados.
  • Todas as mudanças na linguagem de manipulação de dados (DML) como inserções, atualizações e exclusões dos bancos de dados e tabelas especificados são replicadas.
  • Apenas mudanças confirmadas são replicadas.
  • Se você definir uma REPLICA IDENTITY em uma tabela, o Datastream vai tratar as colunas especificadas como chaves primárias.
  • O Datastream envia mensagens de pulsação periodicamente para o banco de dados de origem quando ele está conectado a uma instância principal. Como resultado, os eventos de mensagem de decodificação lógica (op:"m") são inseridos diretamente no arquivo WAL. Essas mensagens são necessárias para que o Datastream garanta a disponibilidade da origem e calcule a atualização. Ao usar uma réplica de leitura como origem, é necessário configurar mensagens de pulsação externamente. Consulte Replicação de réplicas de leitura para mais informações. Recomendamos considerar isso se outras configurações de replicação forem lidas no mesmo banco de dados de origem.

Versões

O Datastream é compatível com o PostgreSQL versão 10 e mais recentes.

O Datastream é compatível com os seguintes tipos de banco de dados PostgreSQL:

  • PostgreSQL auto-hospedado
  • Cloud SQL para PostgreSQL
  • AlloyDB para PostgreSQL
  • AlloyDB Omni
  • Amazon RDS para PostgreSQL
  • Amazon Aurora PostgreSQL

Nível sem custo financeiro

O Datastream permite fazer streaming do AlloyDB para PostgreSQL para o BigQuery usando o nível sem custo financeiro, oferecendo até 100 GiB de dados de captura de dados alterados por mês. Para mais informações, consulte Preços do Datastream.

Práticas recomendadas

Esta seção descreve as práticas recomendadas para configurar a origem do PostgreSQL para uso com o Datastream.

Usar vários streams para evitar o bloqueio de cabeça de linha

Para origens do PostgreSQL, o Datastream usa um único slot de replicação lógica para um stream inteiro. Uma transação grande ou várias atualizações em uma tabela de alto volume podem atrasar a replicação de dados para todas as outras tabelas no mesmo stream.

Para evitar o bloqueio de cabeça de linha, crie streams separados para diferentes conjuntos de tabelas. Por exemplo, é possível criar um stream para tabelas de alto volume e outro para tabelas de baixo volume. Isso isola tabelas de alta rotatividade e impede que elas atrasem a replicação de outras tabelas.

Recomendação:identifique tabelas com taxas de gravação (INSERT/UPDATE/DELETE) excepcionalmente altas e coloque-as no próprio stream dedicado do Datastream com um slot de replicação separado.

Evitar transações de longa duração

Transações de longa duração podem levar ao acúmulo de registros de gravação antecipada (WAL). Como o WAL é sequencial, o PostgreSQL não pode remover arquivos WAL antigos necessários pelo slot de replicação até que a transação longa seja concluída. Isso aumenta o uso do disco WAL.

Além disso, isso pode deixar a decodificação lógica mais lenta. A lentidão é causada por grandes transações que derramam mudanças no disco, o que exige uma remontagem lenta e com uso intenso de E/S após a confirmação, bloqueando a replicação de todas as transações subsequentes. Recomendação:no banco de dados de origem, configure os parâmetros statement_timeout e idle_in_transaction_session_timeout para evitar transações de longa duração. Para mais informações, consulte a documentação do PostgreSQL.

Usar a filtragem de tabelas ao criar publicações

Se você estiver replicando mudanças de apenas algumas tabelas, crie uma PUBLICATION que inclua apenas essas tabelas. Quando uma publicação é definida para tabelas específicas, o PostgreSQL mantém as mudanças de forma eficiente apenas para essas tabelas no slot de replicação. Isso ajuda a reduzir o tamanho do slot de replicação e melhora a performance da decodificação lógica.

Gerenciar slots de replicação de forma proativa

O Datastream usa um slot de replicação lógica na instância principal do PostgreSQL, o que garante que os arquivos WAL sejam mantidos até que o Datastream confirme que eles foram processados. Se um stream falhar, for pausado ou excluído sem descartar o slot de replicação, o PostgreSQL vai continuar retendo arquivos WAL indefinidamente. Isso pode encher o disco do servidor de banco de dados e levar a uma interrupção da produção.

Recomendação:configure alertas eficientes e monitore o uso do disco WAL no servidor PostgreSQL de origem.

Configurar a identidade da réplica corretamente

A configuração REPLICA IDENTITY informa ao PostgreSQL quais dados gravar no WAL para eventos UPDATE e DELETE, permitindo que o Datastream identifique quais linhas foram alteradas.

Se você usar o BigQuery como destino, evite definir REPLICA IDENTITY como FULL. O Datastream usa as colunas registradas como uma chave lógica para operações MERGE do BigQuery. Se REPLICA IDENTITY estiver definido como FULL e uma tabela tiver mais de 16 colunas, isso vai exceder o limite de 16 colunas do BigQuery para chaves primárias em operações MERGE e interromper o stream.

Recomendações (em ordem de preferência):

  1. Melhor:use uma chave primária. A configuração padrão de REPLICA IDENTITY DEFAULT usa a chave primária atual de forma automática e eficiente.
  2. Boa:se não houver uma chave primária, crie um UNIQUE NOT NULL índice e defina REPLICA IDENTITY USING INDEX INDEX_NAME.
  3. Menos recomendada:use apenas a configuração REPLICA IDENTITY FULL em tabelas sem um identificador exclusivo. Esteja ciente do impacto na performance e do limite de 16 colunas e da restrição nos tipos de dados compatíveis com chaves primárias ao replicar para o BigQuery.

Replicação de réplicas de leitura

O Datastream oferece suporte à replicação de instâncias de réplica de leitura do PostgreSQL para o PostgreSQL versão 16 e mais recentes.

Para replicar de uma réplica de leitura, siga estas etapas de configuração na instância principal:

  1. Criar publicações na instância principal: embora o Datastream se conecte à réplica de leitura, as publicações que definem os dados a serem replicados precisam ser criadas na instância principal.
  2. Configurar pulsações WAL: o Datastream depende de mensagens de pulsação WAL periódicas para o mecanismo de checkpoint. Ao se conectar a uma instância principal, o Datastream processa a geração dessas pulsações. No entanto, para uma réplica de leitura, essas pulsações precisam ser geradas externamente.

Uma maneira de configurar pulsações periódicas é criar uma tarefa cron no PostgreSQL usando a extensão pg_cron:

SELECT cron.schedule_in_database(
    'datastream-heartbeat',             -- Job name
    '* * * * *',                        -- Every minute
   $$SELECT pg_logical_emit_message(true, 'datastream', 'cdc heartbeat')$$,
    'DATABASE_NAME',              -- Change this to your database name
    'USERNAME',                   -- Username to run as
    true                                -- Enabled
);

Substitua:

  • DATABASE_NAME: o nome do banco de dados para o qual você quer gerar pulsações.
  • USERNAME: o nome do usuário para executar a tarefa como. Normalmente postgres.

Limitações conhecidas

As limitações conhecidas para o uso do Datastream com um banco de dados PostgreSQL como origem incluem:

  • Os streams são limitados a 10.000 tabelas.
  • Uma tabela com mais de 500 milhões de linhas não pode ser preenchida, a menos que as seguintes condições sejam atendidas:
    1. A tabela tem um índice B-tree exclusivo.
    2. O índice não inclui colunas dos seguintes tipos: DOUBLE, FLOAT, MONEY, REAL, JSON, JSONB, BYTEA, TXID, XML, tipos de dados compostos ou tipos de dados geométricos.
    3. Nenhuma das colunas do índice é anulável.
    4. Todas as colunas do índice estão em ordem crescente ou decrescente.
    5. Todas as colunas do índice estão incluídas no stream.
  • Tabelas sem chaves primárias precisam ter uma REPLICA IDENTITY. Caso contrário, apenas eventos INSERT serão replicados para o destino.
  • Tabelas com chaves primárias não podem ter a REPLICA IDENTITY definida como FULL ou NOTHING. Ela precisa ser definida como DEFAULT.
  • Nem todas as mudanças no esquema de origem podem ser detectadas automaticamente. Nesse caso, pode ocorrer corrupção de dados. As seguintes mudanças de esquema podem causar corrupção de dados ou falha no processamento de eventos downstream:
    • Como descartar colunas.
    • Como adicionar colunas no meio de uma tabela.
    • Alterar o tipo de dados de uma coluna.
    • Como reorganizar as colunas.
    • Como descartar tabelas (relevantes se a mesma tabela for recriada com novos dados adicionados).
  • O Datastream não oferece suporte a colunas dos geometric tipos de dados.
  • O Datastream não oferece suporte a colunas dos tipos de dados range.
  • O Datastream não oferece suporte a matrizes de tipos de dados não compatíveis, matrizes de tipos de dados definidos pelo usuário (incluindo ENUM) ou matrizes de tipos de dados DATE, TIMESTAMP ou TIMESTAMP WITH TIME ZONE. Essas colunas são ignoradas.
  • Para streams criados antes de 17 de fevereiro de 2026: o Datastream não oferece suporte à replicação de eventos UPDATE para linhas que incluem valores TOAST em colunas que fazem parte da identidade da réplica da tabela. Esses eventos são descartados. Os streams criados após essa data não estão sujeitos a essa exceção.
  • O Datastream não oferece suporte à replicação de linhas que incluem valores JSON ou JSONB com mais de 2.950 objetos aninhados. Eventos que contêm esses valores JSON ou JSONB não são replicados para o banco de dados de destino.
  • O Datastream não oferece suporte à replicação de linhas que incluem valores NaN em colunas NUMERIC (precision, scale). Os valores dessas colunas são substituídos por valores NULL.
  • O Datastream não oferece suporte à replicação de colunas do tipo de dados hstore. Os valores dessas colunas são substituídos por valores NULL.
  • O Datastream não oferece suporte à replicação de registros não ASCII de um banco de dados de origem codificado em SQL_ASCII. Esses registros são descartados.
  • O Datastream não oferece suporte à replicação de tabelas com políticas de segurança no nível da linha (RLS) definidas. Para informações sobre como ignorar essa limitação, consulte Comportamento e limitações da origem do PostgreSQL.
  • O Datastream não captura mudanças feitas em colunas geradas.
  • O Datastream pode parar de funcionar ou não capturar novos eventos quando um upgrade de versão principal do PostgreSQL é realizado no banco de dados. Sugerimos que você descarte os slots de replicação antes do upgrade, depois faça o upgrade do banco de dados e, em seguida, recrie os slots de replicação. Se os streams falharem, recupere o stream especificando o novo nome do slot de replicação e faça um preenchimento se a consistência dos dados for necessária.
  • O Datastream não oferece suporte à replicação de tabelas de sistema do PostgreSQL ao usar o fluxo de configuração de stream automatizado. Se você editar o stream criado usando o fluxo automatizado e adicionar tabelas de sistema, o Datastream vai ignorar essas tabelas silenciosamente e não vai replicar dados ou mudanças delas.

A seguir