Transmitir dados de bancos de dados PostgreSQL

Essa 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 padrão de decodificação lógica do PostgreSQL para PostgreSQL 10 e versões mais recentes.

  • É possível selecionar todos os esquemas ou esquemas específicos de uma determinada origem do PostgreSQL, bem como todas as tabelas do esquema ou tabelas específicas.
  • Todos os dados históricos são replicados.
  • Todas as alterações 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 alterações 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 periodicamente mensagens de pulsação ao banco de dados de origem. 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 o Datastream garantir a disponibilidade da origem e calcular a atualização. Recomendamos considerar isso se outras configurações de replicação lerem do 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

Práticas recomendadas

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

Use vários streams para evitar o bloqueio "head-of-line"

Para fontes 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 fluxo.

Para evitar o bloqueio de início de linha, crie fluxos separados para diferentes conjuntos de tabelas. Por exemplo, é possível criar um fluxo para tabelas de alto volume e outro para tabelas de baixo volume. Isso isola tabelas com alta rotatividade e evita que elas atrasem a replicação de outras tabelas.

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

Evite 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 liberar o WAL até que a transação longa seja concluída, mesmo que outras transações estejam sendo consumidas. Isso pode aumentar o tamanho do slot de replicação e diminuir a velocidade da decodificação lógica, porque as mudanças de transações de longa duração que se sobrepõem à transação atual precisam ser decodificadas repetidamente.

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 (em inglês).

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 é limitada a tabelas específicas, o PostgreSQL persiste de maneira eficiente as mudanças apenas nessas 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 proativamente slots de replicação

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

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

Configurar corretamente a identidade da réplica

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 de MERGE e interromper o fluxo.

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

  1. Melhor opção:use uma chave primária. A configuração padrão de REPLICA IDENTITY DEFAULT usa automaticamente e de maneira eficiente a chave primária atual.
  2. Bom:se não houver uma chave primária, crie um índice UNIQUE NOT NULL e defina REPLICA IDENTITY USING INDEX INDEX_NAME.
  3. Menos recomendado: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, além da restrição nos tipos de dados compatíveis para chaves primárias, se você estiver replicando para o BigQuery.

Limitações conhecidas

Limitações conhecidas para o uso do Datastream com um banco de dados PostgreSQL como fonte:

  • 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 exclusivo de árvore B.
    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 pode ser nula.
    4. Todas as colunas do índice estão em ordem crescente ou decrescente.
    5. Todas as colunas do índice são incluídas no fluxo.
  • Tabelas sem chaves primárias precisam ter uma REPLICA IDENTITY. Caso contrário, apenas os eventos INSERT serão replicados para o destino.
  • Tabelas com chaves primárias não podem ter REPLICA IDENTITY definido como FULL ou NOTHING. Ele precisa ser definido como DEFAULT.
  • O Datastream não pode replicar de uma instância de réplica de leitura porque o PostgreSQL não é compatível com a decodificação lógica em réplicas de leitura.
  • Nem todas as alterações no esquema de origem podem ser detectadas automaticamente. Nesse caso, pode ocorrer corrupção de dados. As seguintes alterações 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 é compatível com colunas dos tipos de dados geometric.
  • O Datastream não é compatível com colunas dos tipos de dados range.
  • O Datastream não é compatível com matrizes de tipos de dados não aceitos, 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.
  • O Datastream não oferece suporte à replicação de eventos UPDATE para linhas que incluem valores TOAST em colunas que fazem parte da identidade de réplica da tabela. Esses eventos são descartados.
  • O Datastream não é compatível com a replicação de linhas que incluem valores JSON ou JSONB com mais de 2.950 objetos aninhados. Os 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 é compatível com a replicação de linhas que incluem valores NaN em colunas NUMERIC (precision, scale). Os valores nessas colunas são substituídos por NULL.
  • O Datastream não é compatível com a replicação de colunas do tipo de dados hstore. Os valores nessas colunas são substituídos por NULL.
  • O Datastream não é compatível com a 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 é compatível com a replicação de tabelas com políticas de segurança no nível da linha (RLS, na sigla em inglês) definidas. Para saber como contornar 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, faça o upgrade do banco de dados e recrie os slots de replicação. Se os streams falharem, recupere-os especificando o novo nome do slot de replicação e faça um backfill se a consistência de dados for necessária.

A seguir