PostgreSQL: Tipos de Dados, Objetos e Operações Suportados

O Oracle GoldenGate for PostgreSQL suporta a captura e a entrega da carga inicial e dados transacionais para as versões suportadas do banco de dados PostgreSQL.

O Oracle GoldenGate for PostgreSQL suporta o mapeamento, a filtragem e a transformação de dados de origem, a menos que seja observado o contrário neste documento, bem como a replicação de dados derivados de outros bancos de dados de origem suportados pelo Oracle GoldenGate, em bancos de dados PostgreSQL.

Bancos de Dados Suportados

Estas são as limitações e os bancos de dados suportados para o Oracle GoldenGate for PostgreSQL:

• Somente bancos de dados do usuário são suportados para captura e entrega.

• O Oracle GoldenGate não suporta captura de logs arquivados.

• A entrega não é suportada em bancos de dados de réplica e stand-by.

• O Capture também é suportado em bancos de dados stand-by e réplica.

• Alta Disponibilidade. Consulte Considerações sobre Alta Disponibilidade para obter detalhes.

Considerações sobre Alta Disponibilidade

O Oracle GoldenGate suporta a captura de dados de alteração da configuração de Alta Disponibilidade PostgreSQL. Essa funcionalidade só está disponível no banco de dados PostgreSQL versões 16 e posteriores. A captura de dados de alteração pode ser configurada no servidor principal ou em qualquer servidor stand-by somente para leitura na configuração de Alta Disponibilidade. Para evitar possível perda de dados e intervenção manual em casos de failover, o Oracle GoldenGate recomenda que a configuração de Alta Disponibilidade seja configurada usando replicação síncrona.

Consulte os procedimentos do Oracle GoldenGate para obter o ID do Documento de Failover de Alta Disponibilidade PostgreSQL 2818379.1 para obter mais detalhes sobre possíveis cenários de perda de dados e intervenção manual.

Para configurar a Extração CDC de uma configuração de Alta Disponibilidade PostgreSQL, execute as seguintes tarefas: 1. O Extract pode ser configurado para capturar dados do servidor principal ou de um servidor stand-by somente para leitura na configuração de Alta Disponibilidade.

1. Quando o Extract estiver configurado em um nó (principal ou stand-by), o slot de replicação com o mesmo nome deverá ser criado em todos os outros nós na configuração de Alta Disponibilidade ao mesmo tempo, antes de iniciar a captura de dados.

   1. Use o comando REGISTER EXTRACT para criar o slot de replicação em um servidor (em que o Extract está configurado), conforme mostrado no seguinte exemplo:

      REGISTER EXTRACT exte

   2. Imediatamente após registrar o Extract, crie o slot de replicação com o mesmo nome. Você deve usar o mesmo nome de slot de replicação em todos os outros nós na configuração de Alta Disponibilidade explicitamente.

      postgres=# select pg_create_logical_replication_slot('exte_ac6b520cab2871b7', 'test_decoding');
       pg_create_logical_replication_slot
      
      ------------------------------------
       (exte_ac6b520cab2871b7,0/8169E00)
      (1  row)

      2025-01-20T06:58:22Z  INFO    OGG-25355  Successfully created replication slot 'exte_ac6b520cab2871b7' for Extract group 'EXTE' in database 'postgres'.

   3. Estabeleça conexão com o banco de dados correspondente e execute a instrução pg_create_logical_replication_slot do PSQL. Observação: OBSERVAÇÃO IMPORTANTE PARA CRIAÇÃO DE SLOT DE REPLICAÇÃO EM STANDBY: Quando a criação do SLOT de replicação é tentada no servidor stand-by somente para leitura (usando o comando REGISTER EXTRACT ou a instrução pg_create_logical_replication_slot), a operação é concluída somente depois que algum DML (pode ser qualquer DML aleatório) é executado em qualquer tabela no servidor principal na configuração de alta disponibilidade. Como alternativa, a funcionalidade de pulsação pode ser ativada no servidor principal, o que pode fazer com que a atividade DML necessária no principal conclua a criação do slot de replicação no servidor stand-by.

1. Os comandos ADD TRANDATA ou DELETE TRANDATA não são suportados em nenhum servidor stand-by somente para leitura na configuração de alta disponibilidade do PostgreSQL. A definição REPLICA IDENTITY de qualquer tabela no servidor stand-by somente para leitura seria a mesma da definição REPLICA IDENTITY da tabela correspondente no servidor principal.

2. Para usar a funcionalidade de pulsação quando a captura de dados é configurada em um servidor stand-by somente leitura, a funcionalidade de pulsação deve ser ativada no servidor principal.

3. No caso de failover, o arquivo de parâmetros de extração deve ser modificado para estabelecer conexão com o nó desejado (principal/stand-by, com base no requisito) para continuar a captura de dados após o failover.

   Exemplo

   Considere uma situação em que há três nós no cluster de alta disponibilidade PostgreSQL, com aliases de conexão correspondentes:

   Node1 (principal atual) com o alias de conexão correspondente: node1

   Node2 (stand-by) com o alias de conexão correspondente: node2

   Node3 (stand-by) com o alias de conexão correspondente: node3

   Antes do failover, se o Extract estiver configurado para capturar dados de um dos nós (como node2), o arquivo de parâmetros do Extract conterá uma entrada semelhante à seguinte:

   USERIDALIAS node2

   No caso de um failover, para o nó primário (node1) fica inativo e o nó secundário (node2) se torna o novo primário, então pode haver duas possibilidades:

   1. Para continuar a captura de dados do mesmo node2:

      • Nenhuma alteração é necessária no arquivo de parâmetros de Extração.

      • Reinicie o processo Extract.

   2. Para capturar os dados sempre de um nó diferente:

      • Altere o arquivo de parâmetros do Extract para estabelecer conexão com o nó desejado, como Node3.

        USERIDALIAS node3

      • Reinicie o processo Extract.

Tipos de Dados PostgreSQL Suportados

Veja uma lista de tipos de dados PostgreSQL que o Oracle GoldenGate suporta, juntamente com as limitações desse suporte.

• array

• bigint

• bigserial

• bit(n)

• bit varying(n)

• boolean

• bytea

• char (n)

• cidr

• citext

• date

• decimal

• double precision

• Enumerated Types

• inet

• integer

• interval

• json

• jsonb

• macaddr

• macaddr8

• money

• numeric

• pgvector extension

• real

• serial

• smallint

• smallserial

• text

• time com/sem fuso horário

• timestamp com/sem fuso horário

• tsquery

• tsvector

• uuid

• varchar(n)

• varbit

• xml

Tratando o Tipo de Dados da Matriz

O PostgreSQL suporta o array de vários tipos incorporados e UDT. A partir do Oracle GoldenGate release 26ai, o Oracle GoldenGate Extract e Replicat suportam o tipo de dados PostgreSQL array dos seguintes tipos:

• boolean

• bigint

• bit

• char

• date

• double precision

• enum

• int

• interval

• numeric

• money

• real

• smallint

• timestamp, timestampz, time, timetz

• varbit

• varchar

• text

• tsvector

• tsquery

Os tipos de dados real, double, numeric suportam os valores numéricos especiais NaN e Infinity/-Infinity.

Para obter mais informações sobre tipos de dados por bancos de dados que suportam valores especiais, consulte Valores Especiais Suportados por Tipos de Dados de Banco de Dados.

Tanto a carga inicial quanto a Extração CDC suportam esses tipos de matriz.

Observação: A Extração de carga inicial não suporta PostgreSQL array do tipo de dados time.

Limitações do Suporte

• Se as colunas dos tipos de dados char, varchar, text ou bytea fizerem parte de uma chave primária ou exclusiva, o tamanho máximo individual dessas colunas não deverá exceder 8191 bytes.

• A extração não pode processar registros com colunas bytea de mais de 512 MB de tamanho.

• Há suporte para colunas do tipo de dados CITEXT que fazem parte da Chave Primária com até 8000 bytes. Não há suporte para colunas CITEXT com mais de 8000 bytes e que fazem parte da Chave Primária.

• A extração não pode processar registros com colunas bytea de mais de 512 MB de tamanho.

• Os valores de entrada decimal: NaN não são suportados.

• As seguintes limitações se aplicam aos tipos de dados bit/varbit:

  • Eles são suportados com até 4k de comprimento. Para tamanhos maiores que 4k, os dados são truncados e apenas os bits 4k inferiores são capturados.

  • A coluna bit(n) de origem só pode ser aplicada a uma coluna de tipo de caractere em um destino que não seja PostgreSQL e pode ser aplicada a um tipo char ou a uma coluna bit/varbit no destino PostgreSQL.

• As seguintes limitações se aplicam ao timestamp com fuso horário e ao timestamp sem fuso horário:

  • Os dados timestamp com tags de BC ou AD nos dados não são suportados.

  • Os dados do timestamp anteriores a 1883-11-18 12:00:00 não são suportados.

  • Os dados timestamp com mais de 4 dígitos no componente YEAR não são suportados.

  • As strings de entrada Infinity/-Infinity para colunas timestamp não são suportadas.

• Estas são as limitações ao usar interval:

  • A captura de dados do sinal misto interval das colunas do tipo interval não é suportada. Você pode usar DBOPTIONS ALLOWNONSTANDARDINTERVALDATA no arquivo de parâmetros Extract para capturar os dados de sinal misto interval (ou qualquer outro formato de dados interval, que não é suportado pelo Oracle GoldenGate) como string (não como dados interval padrão).

  Veja a seguir alguns exemplos de dados que são gravados no arquivo de trilha, sobre como usar o DBOPTIONS ALLOWNONSTANDARDINTERVALDATA no arquivo de parâmetros Extract:

  • +1026-9 +0 +0:0: 22.000000 é interpretado como 1026 anos, 9 meses, 0 dias, 0 horas, 0 minutos, 22 segundos.

  • -0-0 -0 -8 é interpretado como 0 ano, 0 mês, 0 dia, -8 horas.

  • +1-3 +0 +3:20 é interpretado como 1 ano, 3 meses, 0 dias, 3 horas, 20 minutos.

• Replicat: Se os dados do intervalo de origem tiverem sido capturados usando DBOPTIONS ALLOWNONSTANDARDINTERVALDATA e gravados como uma string na trilha, a coluna de origem correspondente poderá ser mapeada para uma coluna do tipo char ou binary no destino.

• As limitações de date são:

  • Os dados date com tags de BC ou AD nos dados não são suportados.

  • As strings de entrada Infinity/-Infinity para colunas date não são suportadas.

• As colunas de text, json, xml, bytea, char (>8191), varchar (>8191) são tratadas como colunas LOB e têm as seguintes limitações:

  • Ao usar GETUPDATEBEFORES, a imagem anterior das colunas LOB nunca é registrada em log.

  • Ao usar NOCOMPRESSUPDATES, as colunas LOB só serão registradas na imagem posterior se tiverem sido modificadas.

• O suporte de alcance e precisão para números de ponto flutuante depende da máquina host. Em geral, a precisão é precisa para 16 dígitos significativos, mas você deve revisar a documentação do banco de dados para determinar as aproximações esperadas. O Oracle GoldenGate arredonda ou trunca valores que excedem a precisão suportada.

Tipos de Dados PostgreSQL Não Suportados

O Oracle GoldenGate for PostgreSQL não suporta os seguintes tipos de dados:

• box

• bpchar

• circle

• Composite Types

• Domain Types

• line

• lseq

• Object Identifiers Types

• path

• pg_lsn

• pg_snapshot

• point

• polygon

• Pseudo-Types

• Range Types

• User-defined Types (UDTs)

• Extensões e Módulos Adicionais Fornecidos listados em: https://www.postgresql.org/docs/current/contrib.html não têm suporte do Oracle GoldenGate, a menos que esteja explicitamente listado em Tipos de Dados PostgreSQL Suportados. Observação: Se o arquivo de parâmetros Extract contiver uma tabela com tipos de dados não suportados, o Extract será interrompido com uma mensagem de erro. Para retomar a replicação, remova a tabela do arquivo Extract ou remova a coluna da tabela com um tipo de dados não suportado.

Objetos e Operações Suportados para PostgreSQL

• O Oracle GoldenGate for PostgreSQL só suporta operações DML (Inserir/Atualizar/Excluir). A replicação DDL não é suportada.

• O Oracle GoldenGate for PostgreSQL suporta a replicação de operações de truncamento começando com PostgreSQL 11 e acima e requer o parâmetro GETTRUNCATES no Extract e no Replicat.

• Só há suporte para várias operações de truncamento em pgoutput plugin.

• Nomes com distinção entre maiúsculas e minúsculas:

  • Nomes sem aspas não fazem distinção entre maiúsculas e minúsculas e são implicitamente minúsculos. Por exemplo, CREATE TABLE MixedCaseTable e SELECT * FROM mixedcasetable são equivalentes.

  • Os nomes de tabelas e colunas entre aspas fazem distinção entre maiúsculas e minúsculas e precisam ser listados corretamente em Extracts e Replicats e com comandos do Oracle GoldenGate.

  Por exemplo, TABLE appschema."MixedCaseTable" e ADD TRANDATA appschema."MixedCaseTable" seriam necessários para suportar um nome de tabela com distinção entre maiúsculas e minúsculas.

Tabelas, Views e Views Materializadas

As tabelas a serem incluídas para captura e entrega devem atender aos requisitos a seguir e devem incluir apenas os tipos de dados listados em Tipos de Dados PostgreSQL Suportados.

• O Oracle GoldenGate for PostgreSQL suporta a captura de DML transacional de tabelas de usuário e a entrega para tabelas de usuário.

• O Oracle GoldenGate for PostgreSQL, versões 21.14.0.0.0 e posteriores, suporta captura e entrega em tabelas particionadas base. Para capturar dados de tabelas particionadas PostgreSQL, a definição de Identidade de Réplica de todas as partições deve corresponder à definição de Identidade de Réplica da tabela particionada base. Isto é aplicável para tabelas particionadas de vários níveis também.

  Você pode escolher uma das seguintes maneiras para definir essa configuração:

  1. Execute o comando ADD TRANDATA em todas as partições ou nas partições necessárias da tabela particionada base:

     ADD TRANDATA *partition-name* ALLCOLS

  2. Execute o comando ALTER TABLE em todas as partições ou nas partições necessárias da tabela particionada base:

     ALTER TABLE *partition-name* REPLICA IDENTITY *replica-identity-setting*

• A globalização é suportada para nomes de objetos (nomes de tabela /schema/database/column) e dados de coluna.

• A captura e a entrega de uma view materializada são suportadas.

• O processo de extração suporta views materializadas, que devem ter um índice exclusivo e devem ser atualizadas simultaneamente.

• A Identidade de Réplica de views materializadas deve ser definida como FULL para que CDR, UNIFIED FORMAT RECORD e NOCOMPRESSDELETES, GETUPDATEBEFORES possam ser suportados. Além disso, a definição de identidade de réplica FULL é necessária para que a view materializada processe o registro WAL DELETE. Se a Identidade de Réplica da view materializada não estiver definida como FULL, o registro DELETE não será processado pelo Extract.

  Para definir a identidade de réplica como FULL, use o seguinte comando:

  add trandata *schema.materialized_view*, ALLCOLS

• As estatísticas de um UPDATE ou PK UPDATE serão registradas como DELETE seguidas por INSERT. Embora isso exiba uma anomalia nas estatísticas do Extract, mas a sincronização de dados esteja correta quando os dados das views materializadas de origem e destino forem comparados.

• O PK UPDATE resulta em DELETE seguido por INSERT; portanto, as estatísticas do Extract serão mostradas de maneira diferente da contagem de linhas do banco de dados. Você precisa confiar nas ferramentas de comparação de dados para verificar a integridade dos dados entre os dados de origem e de destino, contendo os registros de views materializadas.

• Os dados da trilha não podem ser aplicados à view materializada pelo processo Replicat. Você pode mapear os dados das views materializadas da trilha para qualquer outra tabela.

Limitações

• O Oracle GoldenGate para PostgreSQL não suporta captura e entrega de views.

• O Oracle GoldenGate para PostgreSQL não suporta captura de partições individuais de uma tabela particionada.

Sequências e Colunas de Identidade

• As sequências são suportadas nas tabelas de origem e destino para implementações unidirecionais, bidirecionais e multidirecionais.

• As colunas de identidade criadas usando a cláusula GENERATED BY DEFAULT AS IDENTITY são suportadas nas tabelas de origem e destino, para implementações unidirecionais, bidirecionais e multidirecionais.

• As colunas de identidade criadas usando a cláusula GENERATED ALWAYS AS IDENTITY não são suportadas nas tabelas de banco de dados de destino e a propriedade Identity deve ser removida das tabelas de destino ou alterada para GENERATED BY DEFAULT AS IDENTITY.

• Para implementações bidirecionais e multidirecionais, defina as colunas e sequências de Identidade com um valor INCREMENT BY igual ao número de servidores na configuração, com um MINVALUE diferente para cada um.

  Por exemplo, os valores MINVALUE /INCREMENT BY para uma configuração bidirecional de dois bancos de dados seriam os seguintes:

  Database1, defina MINVALUE como 1 com INCREMENT BY como 2.

  Database2, defina MINVALUE como 2 com INCREMENT BY como 2.

  Por exemplo, os valores MINVALUE /INCREMENT BY para uma configuração multidirecional de três bancos de dados seriam os seguintes:

  Database1, defina MINVALUE como 1 com INCREMENT BY como 3.

  Database2, defina MINVALUE como 2 com INCREMENT BY como 3.

  Database3, defina MINVALUE em 3 com um INCREMENT BY de 3.