Transmita dados de bases de dados PostgreSQL

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

  • O comportamento da forma como o Datastream processa os dados extraídos de uma base de dados PostgreSQL de origem
  • As versões da base de dados PostgreSQL suportadas pelo Datastream
  • Uma vista geral de como configurar uma base de dados PostgreSQL de origem para que os dados possam ser transmitidos a partir da mesma para um destino
  • Limitações conhecidas da utilização da base de dados PostgreSQL como origem

Comportamento

A base de dados PostgreSQL de origem baseia-se na respetiva funcionalidade de descodificação lógica. A descodificação lógica expõe todas as alterações confirmadas na base de dados e permite consumir e processar estas alterações num formato fácil de usar através de um plug-in de saída. O Datastream usa o plug-in pgoutput, que é o plug-in de descodificação lógica padrão do PostgreSQL para o PostgreSQL 10 e posterior.

  • Pode 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 do histórico são replicados.
  • Todas as alterações da linguagem de manipulação de dados (DML), como inserções, atualizações e eliminações das bases de dados e tabelas especificadas, são replicadas.
  • Apenas as alterações confirmadas são replicadas.
  • Se definir uma REPLICA IDENTITY numa tabela, o Datastream trata as colunas especificadas como chaves primárias.
  • O fluxo de dados envia periodicamente mensagens de sinal de vida à base de dados de origem. Como resultado, os eventos de mensagens de descodificação lógica (op:"m") são inseridos diretamente no ficheiro WAL. Estas mensagens são necessárias para o fluxo de dados para garantir a disponibilidade da origem e calcular a atualidade. Recomendamos que tenha isso em consideração se outras configurações de replicação lerem a partir da mesma base de dados de origem.

Versões

O Datastream suporta o PostgreSQL versão 10 e posteriores.

O Datastream suporta os seguintes tipos de base de dados PostgreSQL:

  • PostgreSQL autoalojado
  • Cloud SQL para PostgreSQL
  • AlloyDB para PostgreSQL
  • AlloyDB Omni
  • Amazon RDS para PostgreSQL
  • Amazon Aurora PostgreSQL

Práticas recomendadas

Esta secção descreve as práticas recomendadas para configurar a sua origem do PostgreSQL para utilização com o Datastream.

Use várias streams para evitar o bloqueio de cabeça de fila

Para origens do PostgreSQL, o Datastream usa um único espaço de replicação lógica para uma stream inteira. Uma transação grande ou várias atualizações numa tabela de volume elevado podem atrasar a replicação de dados para todas as outras tabelas na mesma stream.

Para evitar o bloqueio de cabeça de fila, crie streams separadas para diferentes conjuntos de tabelas. Por exemplo, pode criar uma stream para tabelas de volume elevado e outra para tabelas de volume baixo. Isto isola as tabelas com elevada rotatividade e impede que atrasem a replicação de outras tabelas.

Recomendação: identifique tabelas com taxas de gravação excecionalmente elevadas (INSERT/UPDATE/DELETE) e coloque-as na sua própria stream do Datastream dedicada com um intervalo de replicação separado.

Evite transações de longa duração

As transações de longa duração podem levar à acumulação do registo de gravação antecipada (WAL). Uma vez que o WAL é sequencial, o PostgreSQL não pode esvaziar o WAL até que a transação longa seja concluída, mesmo que outras transações estejam a ser consumidas. Isto pode aumentar o tamanho do espaço de replicação e abrandar a descodificação lógica, porque as alterações de transações de longa duração que se sobrepõem à transação atual têm de ser descodificadas repetidamente.

Recomendação: na base de dados de origem, configure os parâmetros statement_timeout e idle_in_transaction_session_timeout para evitar transações de execução prolongada. Para mais informações, consulte a documentação do PostgreSQL.

Use a filtragem de tabelas quando criar publicações

Se estiver a replicar alterações apenas de algumas tabelas, certifique-se de que cria um PUBLICATION que inclua apenas essas tabelas. Quando uma publicação é limitada a tabelas específicas, o PostgreSQL persiste de forma eficiente as alterações apenas para essas tabelas no espaço de replicação. Isto ajuda a reduzir o tamanho do espaço de replicação e melhora o desempenho da descodificação lógica.

Faça a gestão proativa dos espaços de replicação

O Datastream usa um espaço de replicação lógica na sua instância principal do PostgreSQL, o que garante que os ficheiros WAL são retidos até o Datastream confirmar que foram processados. Se uma stream falhar, for pausada ou eliminada sem eliminar o espaço de replicação, o PostgreSQL continua a reter ficheiros WAL indefinidamente. Isto pode encher o disco do servidor da base de dados e provocar uma interrupção da produção.

Recomendação: configure alertas eficientes e monitorize a utilização do disco WAL no servidor PostgreSQL de origem.

Configure corretamente a identidade da réplica

A definição REPLICA IDENTITY indica ao PostgreSQL que dados escrever no WAL para eventos UPDATE e DELETE, o que permite ao Datastream identificar que linhas foram alteradas.

Se usar o BigQuery como destino, evite definir REPLICA IDENTITY como FULL. O fluxo de dados usa as colunas registadas como uma chave lógica para operações do BigQuery MERGE. Se REPLICA IDENTITY estiver definido como FULL e uma tabela tiver mais de 16 colunas, isto excede o limite de 16 colunas do BigQuery para chaves primárias em operações MERGE e interrompe a stream.

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

  1. Melhor: use uma tecla principal. A predefinição usa a chave principal existente de forma automática e eficiente.REPLICA IDENTITY DEFAULT
  2. Bom: se não existir nenhuma chave primária, crie um UNIQUE NOT NULL índice e defina REPLICA IDENTITY USING INDEX INDEX_NAME.
  3. Menos recomendado: use apenas a definição REPLICA IDENTITY FULL em tabelas sem um identificador único. Tenha em atenção o impacto no desempenho, o limite de 16 colunas e a restrição nos tipos de dados suportados para chaves primárias se estiver a replicar para o BigQuery.

Limitações conhecidas

As limitações conhecidas da utilização do Datastream com uma base de dados PostgreSQL como origem incluem:

  • Os streams estão limitados a 10 000 tabelas.
  • Não é possível preencher previamente uma tabela com mais de 500 milhões de linhas, a menos que sejam cumpridas as seguintes condições:
    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 por ordem ascendente ou todas as colunas do índice estão por ordem descendente.
    5. Todas as colunas do índice estão incluídas no fluxo.
  • As tabelas sem chaves primárias têm de ter uma REPLICA IDENTITY. Caso contrário, apenas os eventos INSERT são replicados para o destino.
  • As tabelas com chaves primárias não podem ter o REPLICA IDENTITY definido como FULL ou NOTHING. Tem de ser definido como DEFAULT.
  • O Datastream não pode fazer a replicação a partir de uma instância de réplica de leitura porque o PostgreSQL não suporta a descodificação lógica em réplicas de leitura.
  • Nem todas as alterações ao esquema de origem podem ser detetadas automaticamente, caso em que pode ocorrer corrupção de dados. As seguintes alterações ao esquema podem causar corrupção de dados ou falha no processamento dos eventos a jusante:
    • Eliminar colunas.
    • Adicionar colunas ao meio de uma tabela.
    • Alterar o tipo de dados de uma coluna.
    • Reordenar colunas.
    • Eliminar tabelas (relevante se a mesma tabela for recriada com novos dados adicionados).
  • O fluxo de dados não suporta colunas dos tipos de dados geometric.
  • O fluxo de dados não suporta colunas dos tipos de dados range.
  • O fluxo de dados não suporta matrizes de tipos de dados não suportados, matrizes de tipos de dados definidos pelo utilizador (incluindo ENUM) nem matrizes de tipos de dados DATE, TIMESTAMP ou TIMESTAMP WITH TIME ZONE. Essas colunas são ignoradas.
  • A stream de dados não suporta a 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 rejeitados.
  • O fluxo de dados não suporta a replicação de linhas que incluem valores JSON ou JSONB com mais de 2950 objetos aninhados. Os eventos que contêm esses valores JSON ou JSONB não são replicados para a base de dados de destino.
  • O fluxo de dados não suporta a replicação de linhas que incluem valores NaN em colunas NUMERIC (precision, scale). Os valores nessas colunas são substituídos por valores NULL.
  • O fluxo de dados não suporta a replicação de colunas do tipo de dados hstore. Os valores nessas colunas são substituídos por valores NULL.
  • O Datastream não suporta a replicação de registos não ASCII de uma base de dados de origem codificada em SQL_ASCII. Esses registos são rejeitados.
  • O fluxo de dados não suporta a replicação de tabelas com políticas de segurança ao nível da linha (RLS) definidas. Para obter informações sobre como contornar esta limitação, consulte o artigo Comportamento e limitações da origem do PostgreSQL.
  • O fluxo de dados não captura alterações feitas a colunas geradas.
  • A stream de dados pode deixar de funcionar ou não captar novos eventos quando é feita uma atualização da versão principal do PostgreSQL na base de dados. Sugerimos que elimine os slots de replicação antes da atualização, atualize a base de dados e, em seguida, recrie os slots de replicação. Se as streams falharem, recupere a stream especificando o novo nome do espaço de replicação e faça um preenchimento se for necessária a consistência dos dados.

O que se segue?