Yugabyte: Objetos e Operações Suportados

A lista a seguir descreve os objetos e as operações suportados para o Oracle GoldenGate for Yugabyte:

• O Oracle GoldenGate Extract suporta o plug-in yboutput.

• O Replica Identity CHANGE é a definição nativa para Yugabyte e é recomendado ao usar o plug-in yboutput, pois fornece melhor desempenho em comparação com outros tipos de Identidade de Réplica.

• A replicação bidirecional é suportada com o plug-in yboutput. Ao usar o plug-in yboutput para replicação bidirecional, a tabela de checkpoint do Oracle GoldenGate deve ser criada e incluída na lista de publicações antes de iniciar o processo de Extração do CDC.

  Além disso, o slot de replicação deve ser criado somente após a criação e a adição da tabela de checkpoint à publicação.

• A replicação bidirecional é suportada com o plug-in test_decoding. Todas as tabelas, incluindo as tabelas de checkpoint, devem ser criadas antes de registrar qualquer Extract ao usar o plug-in test_decoding. No caso do plug-in PGOUTPUT, a tabela de checkpoint junto com todas as outras tabelas interessadas deve ser incluída na publicação antes do registro do Extract.

Observação: Não elimine nenhuma tabela, incluindo tabelas de checkpoint.

• Só há suporte para várias operações de truncamento no plug-in pgoutput/yboutput.

• Comando Register aprimorado com a opção pgplugintype:

  • A opção pgplugintype está disponível na interface Web e no Admin Client sob o comando REGISTER EXTRACT. Essa opção permite que você escolha test_decoding ou pgoutput como plug-in de decodificação lógica.

  • Quando você especifica pgplugintype pgoutput, o módulo subjacente usa automaticamente o plug-in yboutput para registrar o processo de Extract.

  • Se você não especificar nenhum pgplugintype, o Extract do CDC será registrado usando o plug-in test_decoding, por padrão.

  • Para se registrar explicitamente com o plug-in yboutput no Yugabyte, especifique o tipo de plug-in pgoutput.

  Sintaxe:

    <pre class="copy"><code>REGISTER EXTRACT *group_name* PGPLUGINTYPE *plugin_option*;</code></pre>
  

  Exemplo:

    <pre class="copy"><code>REGISTER EXTRACT ext_yb PGPLUGINTYPE pgoutput;</code></pre>
  

• O parâmetro STREAMINGOPTIONS foi introduzido em TRANLOGOPTIONS. Esse parâmetro permite especificar o publication_name para o comando de início de replicação.

  Exemplo:

  TRANLOGOPTIONS STREAMINGOPTIONS (publication_names="my*123,my_publication2,123 pub,my_publication";)

  As seguintes diretrizes e restrições devem ser consideradas ao usar este parâmetro:

  • A(s) publicação(ões) deve(m) ser criada(s) antes de registrar o processo Extract.

  Os nomes de publicação não devem conter caracteres especiais, incluindo Vírgula (,) Aspas simples (') Aspas duplas (").

  • Vários nomes de publicação podem ser especificados como uma lista separada por vírgulas no publication_names. Por exemplo:

    TRANLOGOPTIONS STREAMINGOPTIONS (publication_names="my*123,my_publication2,123 pub,my_publication";)

  O nome da publicação final na lista deve terminar com um ponto e vírgula (;)

Limitações de Yugabyte

Considere as seguintes limitações para o banco de dados Yugabyte, enquanto o configura para captura e entrega:

• Transações de LOB grandes ausentes: quando um LOB (Objeto Grande) tem um tamanho entre 200 MB e 400 MB, toda a transação, seja INSERT ou UPDATE, pode estar ausente no fluxo CDC.

• Incompatibilidade de dados no downstream devido a várias atualizações na mesma transação: Quando várias atualizações ocorrem dentro da mesma transação, o módulo CDCSDK no Yugabyte pode falhar ao enviar a imagem APÓS correta se a identidade da réplica da tabela estiver definida como FULL ou DEFAULT. Isso pode resultar em discrepâncias de dados para a imagem AFTER no sistema downstream.

• A conexão de replicação termina após a DDL em tabelas replicadas (Plug-in test_decoding): Ao usar o plug-in test_decoding, todas as tabelas do banco de dados são incluídas automaticamente na lista de sondagem, por padrão. Se uma operação DDL (como uma eliminação de tabela) for executada em qualquer tabela incluída nesta lista, o servidor encerrará a conexão de replicação. No entanto, a eliminação de tabelas que fazem parte da lista de sondagem não é suportada com o plug-in test_decoding; portanto, se você precisar dessa flexibilidade, alterne para o plug-in yboutput.

  Observação: antes de eliminar uma tabela, certifique-se de que ela não faça parte de nenhuma publicação para evitar erros de replicação ou interrupções de conexão. Da mesma forma, não elimine a tabela de checkpoint do Oracle GoldenGate, pois ela também resultará no mesmo erro.

• Expiração do slot de replicação devido à inatividade estendida: Os slots de replicação retêm determinados recursos para impedir a coleta de lixo de registros WAL (Log de Gravação Antecipada) necessários para replicação. Se um slot permanecer inativo por um período prolongado, ele será marcado como expirado e os recursos retidos serão liberados. Após a expiração, o slot de replicação torna-se inutilizável e deve ser recriado.

  Janela de retenção padrão:

  • 8 horas a partir da versão 2024.2.1

  • 4 horas nas versões anteriores à versão 2024.2.1

  Este é um problema conhecido como mencionado no site Yugabyte:

  https://github.com/yugabyte/yugabyte-db/issues/27766

  Ações Recomendadas para Evitar Expiração:

  • Ative a funcionalidade de pulsação para garantir a atividade contínua de WAL e evitar longos períodos de inatividade.

  • Configure as opções autostart ou autorestart para o processo CDC para que ele se reconecte automaticamente ao módulo CDCSDK, minimizando o tempo de inatividade e evitando a expiração do slot.

• BatchSQL não funciona corretamente quando BatchMechanism 3 é definido com o Driver DD de Andamento, que é o padrão para o processo Replicat para Yugabyte. Portanto, se precisar usar BatchSQL, configure a definição DBOPTIONS _BatchMechanism 2 no arquivo de parâmetros do Replicat para obter a funcionalidade adequada. Essa solução alternativa pode ser aplicada ao processo Replicat no Oracle GoldenGate 23.10 e posterior para Yugabyte.

• Tabelas elegíveis somente para publicação: Tabelas base persistentes e tabelas particionadas podem ser incluídas em uma publicação. Os seguintes tipos de objeto não podem fazer parte de uma publicação:

  • Tabelas temporárias

  • Tabelas não conectadas

  • Tabelas estrangeiras

  • Views materializadas

  • Visualizações regulares

• Impacto da exclusão da publicação no Extract do CDC: Se uma publicação for excluída enquanto o Extract do CDC ainda estiver em execução, haverá um risco de corrupção do slot de replicação, fazendo com que ele pare de funcionar. Nesses casos, o slot de replicação afetado se torna inutilizável e simplesmente recriar a mesma publicação não resolverá o problema. Não há solução para retomar no fluxo existente e a única maneira é criar uma nova publicação e associá-la a um novo slot de replicação.

• Limitações com Fuso Horário (TZ): O processo do remetente WAL sempre transmite timestamps confirmados em UTC. Se o fuso horário da sessão do Oracle GoldenGate for diferente do UTC, poderão ocorrer discrepâncias durante o posicionamento por timestamp no processo de Extração do CDC. Para evitar esse problema, defina a variável de ambiente TZ=UTC na camada de implantação. Essa limitação se aplica especificamente ao plug-in yboutput.

• O plug-in pgoutput não é suportado para Yugabyte.

• A globalização não é suportada com o plug-in yboutput

• Chave primária na tabela: Somente tabelas com uma chave primária são suportadas para streaming de CDC em Yugabyte. A tabela que não tem a chave primária não será capturada pelo Extract do CDC do Oracle GoldenGate.

• Atualizações de Chave Primária em Yugabyte: Uma ATUALIZAÇÃO PK em Yugabyte será registrada como DELETE seguida de INSERT. O processo Extract do Oracle GoldenGate mostrará as estatísticas de PK UPDATE como DELETE e INSERT somente. Embora as estatísticas não sejam mostradas como operação de atualização nas estatísticas do Extract, não haverá nenhuma discrepância nos dados na origem e no destino.

• Comportamento de identidade da réplica: A identidade da réplica de tabelas presentes no momento da criação do slot não pode ser alterada após a criação do slot. No entanto, a identidade de réplica de todas as novas tabelas criadas após a criação do slot pode ser definida usando o flag ysql_yb_default_replica_identity, cdcsdk_publication_list_refresh_interval_secs e csdk_enable_dynamic_table_support tserver. Esses flags precisam ser definidos no mestre e em t-server para que novas tabelas sejam criadas.

  Por padrão, cdcsdk_publication_list_refresh_interval_secs é definido como 900 seg, que é de 15 minutos. Você precisa definir isso de acordo com sua exigência. A diminuição de seu valor reduzirá rapidamente a tabela recém-criada a ser atualizada no módulo CDCSDK, o que ajudará o Oracle GoldenGate a capturar todos os registros dessas novas tabelas. O exemplo a seguir mostra os flags que são definidos para tabelas criadas dinamicamente após a criação do SLOT:

  ysql_yb_default_replica_identity=FULL,cdcsdk_publication_list_refresh_interval_secs=120,cdcsdk_enable_dynamic_table_support=true

• Não há suporte para Posicionamento por Fim de Log (EOL) ou Fim de Arquivo (EOF): em vez de EOL/EOF, você pode alterar a posição do slot pelo timestamp atual, que filtrará os registros existentes.

• Operação de Execução: Parâmetros como GETTRUNCATES/IGNORETRUNCATES não são suportados, pois o banco de dados não permite que o usuário trunque a tabela se eles estiverem ativados para a captura de dados de alteração.

• Retenção de WAL: O yugabyte normalmente limpa segmentos de WAL após algum período. Isso significa que o Oracle GoldenGate poderá perder os dados de log do WAL se os logs forem truncados quando o Extract estiver inativo por mais tempo. A retenção de WAL não é garantida em Yugabyte até que alguns parâmetros, como cdc_intent_retention_ms e cdc_wal_retention_time_secs, sejam ajustados para reter os logs WAL por mais tempo. Isso deve ser ajustado em todos os nós ou clusters em que o processo Extract do Oracle GoldenGate esteja em execução.

  Os valores recomendados são os seguintes:

  cdc_wal_retention_time_secs=86400

  cdc_intent_retention_ms = 86400000

• Comando UNREGISTER EXTRACT: O Oracle GoldenGate usa o comando UNREGISTER EXTRACT para eliminar o slot de replicação. Um slot de replicação só pode ser eliminado depois que o cliente que consome dele tiver sido interrompido por pelo menos ysql_cdc_active_replication_slot_window_ms de duração. O valor padrão do flag é 5 minutos, o que significa que você deve aguardar o intervalo de tempo máximo para o qual um slot de replicação pode permanecer inativo antes de ser considerado desatualizado.

  No caso de uma configuração de cluster, esse parâmetro precisa ser ajustado em todos os nós com o mesmo valor.

• Limitações de BLOB/CLOB: O tipo de dados, como texto/imagem, tem a limitação de capturar apenas 200 MB de dados. O tamanho da linha não deve exceder mais 32 MB e cada coluna que contém os dados do lob deve ser mantida até 2 MB.

  https://docs.yugabyte.com/stable/develop/best-practices-ysql/#row-limite de tamanho

• Limitações com SAVEPOINT e Rollback em Operações DML: O Extract CDC do Oracle GoldenGate não suporta as operações de rollback SAVEPOINT. O plug-in CDC test_decoding não respeita os comandos ROLLBACK TO SAVEPOINT. Como resultado, os registros que deveriam ter sido excluídos devido a um rollback ainda são capturados e processados pelo Extract.

  Esse comportamento é uma limitação conhecida do módulo SDK do Yugabyte CDC. Para saber mais, consulte os seguintes links:

  https://yugabyte.atlassian.net/browse/DB-11714

  https://docs.yugabyte.com/stable/develop/change-data-capture/using-logical-replication/#limitations

• Limitação de Eliminação de Tabela: Depois que um slot for criado, o usuário não deverá eliminar nenhuma tabela do banco de dados até que o slot seja eliminado. Se o slot estiver ativo e o usuário tentar eliminar qualquer tabela do banco de dados, o CDC Extract não poderá capturar registros de outras tabelas do CDC que façam parte da replicação. Além disso, sugere-se que, quando a extração CDC está em execução, o usuário não deve eliminar nenhuma tabela no banco de dados onde o slot é criado. Se não seguir isso, o CDC Extract será encerrado com o erro de desconexão semelhante ao seguinte:

  Error: The server has ended the streaming connection.

• Limitação em statement_timeout: O parâmetro statement_timeout de Yugabyte não deve ser modificado no nível do usuário ou do banco de dados e deve ser mantido como padrão. Se estiver definido com um valor menor, o processo Extract CDC não poderá ler os registros do WAL. Se necessário, ele deve ser sempre definido apenas no nível da sessão.

• A criação de slot no nó de réplica com o modo somente leitura não é suportada: O processo Extract CDC não poderá capturar os registros do nó de réplica. Isso ocorre porque a versão que suportamos, como a 2024.2.1.0 ou a 2024.2.2.0, é criada com base no PostgreSQL 11.2, que não suporta a criação do slot no nó de réplica.