Yugabyte: oggetti e operazioni supportati

Nell'elenco riportato di seguito vengono descritti gli oggetti e le operazioni supportati per Oracle GoldenGate per Yugabyte.

• Oracle GoldenGate Extract supporta il plugin yboutput.

• Replica Identity CHANGE è l'impostazione nativa per Yugabyte ed è consigliata quando si utilizza il plugin yboutput, in quanto offre prestazioni migliori rispetto ad altri tipi di Replica Identity.

• La replica bidirezionale è supportata con il plugin yboutput. Quando si utilizza il plugin yboutput per la replica bidirezionale, è necessario creare e includere la tabella di checkpoint di Oracle GoldenGate nell'elenco di pubblicazioni prima di avviare il processo di estrazione CDC.

  Inoltre, lo slot di replica deve essere creato solo dopo la creazione e l'aggiunta della tabella di checkpoint alla pubblicazione.

• La replica bidirezionale è supportata con il plugin test_decoding. Tutte le tabelle, comprese le tabelle di checkpoint, devono essere create prima di registrare qualsiasi Extract quando si utilizza il plugin test_decoding. In caso di plugin PGOUTPUT, la tabella dei checkpoint insieme a tutte le altre tabelle interessate deve essere inclusa nella pubblicazione prima della registrazione Extract.

Nota: non eliminare alcuna tabella, comprese le tabelle di checkpoint.

• Più operazioni di troncamento sono supportate solo nel plugin pgoutput/yboutput.

• Comando di registrazione attivato con l'opzione pgplugintype:

  • L'opzione pgplugintype è disponibile sia nell'interfaccia Web che nel client di amministrazione con il comando REGISTER EXTRACT. Questa opzione consente di scegliere test_decoding o pgoutput come plugin di decodifica logica.

  • Quando si specifica pgplugintype pgoutput, il modulo sottostante utilizza automaticamente il plugin yboutput per registrare il processo Extract.

  • Se non si specifica alcun pgplugintype, per impostazione predefinita CDC Extract si registra utilizzando il plugin test_decoding.

  • Per registrarsi in modo esplicito con il plugin yboutput in Yugabyte, è necessario specificare il tipo di plugin pgoutput.

  Sintassi:

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

  Esempio:

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

• Il parametro STREAMINGOPTIONS è stato introdotto in TRANLOGOPTIONS. Questo parametro consente di specificare publication_name per il comando di avvio della replica.

  Esempio:

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

  Quando si utilizza questo parametro, devono essere prese in considerazione le seguenti linee guida e limitazioni:

  • La pubblicazione o le pubblicazioni devono essere create prima di registrare il processo di estrazione.

  I nomi delle pubblicazioni non devono contenere caratteri speciali, tra cui virgolette (,) virgolette singole (') virgolette doppie (").

  • È possibile specificare più nomi di pubblicazione come lista separata da virgole in publication_names. Ad esempio:

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

  Il nome della pubblicazione finale nell'elenco deve terminare con un punto e virgola (;)

Limitazioni di Yugabyte

Considerare le seguenti limitazioni per il database Yugabyte, durante l'impostazione per l'acquisizione e la consegna:

• Transazioni LOB di grandi dimensioni mancanti: se un LOB (Large Object) ha una dimensione compresa tra 200 MB e 400 MB, l'intera transazione, indipendentemente dal fatto che sia INSERT o UPDATE, potrebbe non essere presente nel flusso CDC.

• Mancata corrispondenza dei dati a valle a causa di più aggiornamenti nella stessa transazione: quando si verificano più aggiornamenti all'interno della stessa transazione, il modulo CDCSDK in Yugabyte potrebbe non inviare l'immagine AFTER corretta se l'identità di replica della tabella è impostata su FULL o DEFAULT. Ciò può comportare discrepanze di dati per l'immagine AFTER nel sistema a valle.

• La connessione di replica termina dopo DDL nelle tabelle replicate (plugin test_decoding): quando si utilizza il plugin test_decoding, per impostazione predefinita tutte le tabelle del database vengono incluse automaticamente nella lista di polling. Se viene eseguita un'operazione DDL (ad esempio un'eliminazione della tabella) su qualsiasi tabella inclusa in questa lista, il server interrompe la connessione di replica. Tuttavia, l'eliminazione delle tabelle che fanno parte della lista di polling non è supportata con il plugin test_decoding, quindi, se si richiede questa flessibilità, è necessario passare al plugin yboutput.

  Nota: prima di eliminare una tabella, assicurarsi che non faccia parte di alcuna pubblicazione per evitare errori di replica o interruzioni di connessione. Analogamente, non eliminare la tabella di checkpoint di Oracle GoldenGate poiché si verificherà anche lo stesso errore.

• Scadenza dello slot di replica a causa dell'inattività estesa: gli slot di replica conservano determinate risorse per evitare il ciclo di garbage collection dei record WAL (Write-Ahead Log) necessari per la replica. Se uno slot rimane inattivo per un periodo esteso, viene contrassegnato come scaduto e le risorse conservate vengono rilasciate. Dopo la scadenza, lo slot di replica diventa inutilizzabile e deve essere ricreato.

  Finestra di conservazione predefinita:

  • 8 ore a partire dalla versione 2024.2.1

  • 4 ore nelle versioni precedenti al 2024.2.1

  Questo è un problema noto come menzionato sul sito di Yugabyte:

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

  Azioni consigliate per evitare la scadenza:

  • Abilita la funzionalità heartbeat per garantire l'attività WAL continua e prevenire lunghi periodi di inattività.

  • Configurare le opzioni autostart o autorestart per il processo CDC in modo che si riconnetta automaticamente al modulo CDCSDK, riducendo al minimo i tempi di inattività ed evitando la scadenza degli slot.

• BatchSQL non funziona correttamente se BatchMechanism 3 è impostato con il driver Progress DD, che è l'impostazione predefinita per il processo Replicat per Yugabyte. Pertanto, se è necessario utilizzare BatchSQL, è necessario configurare l'impostazione DBOPTIONS _BatchMechanism 2 nel file dei parametri Replicat per il corretto funzionamento. Questa soluzione alternativa può essere applicata al processo Replicat in Oracle GoldenGate 23.10 e versioni successive per Yugabyte.

• Tabelle idonee per la pubblicazione: le tabelle di base persistenti e le tabelle partizionate possono essere incluse in una pubblicazione. I seguenti tipi di oggetto non possono far parte di una pubblicazione:

  • Tabelle temporanee

  • Tabelle non registrate nel log

  • Tabelle esterne

  • Viste materializzate

  • Viste regolari

• Impatto sull'eliminazione della pubblicazione su CDC Extract: se una pubblicazione viene eliminata mentre CDC Extract è ancora in esecuzione, si corre il rischio di danneggiamento dello slot di replica che ne impedisce il funzionamento. In questi casi, lo slot di replica interessato diventa inutilizzabile e la semplice ricreazione della stessa pubblicazione non risolverà il problema. Non esiste una soluzione per riprendere il flusso esistente e l'unico modo è creare una nuova pubblicazione e associarla a un nuovo slot di replica.

• Limitazioni con fuso orario (TZ): il processo del mittente WAL trasmette sempre gli indicatori orari di cui è stato eseguito il commit in UTC. Se il fuso orario della sessione di Oracle GoldenGate è diverso da UTC, potrebbero verificarsi discrepanze durante il posizionamento in base all'indicatore orario nel processo di estrazione CDC. Per evitare questo problema, è necessario impostare la variabile di ambiente TZ=UTC a livello di distribuzione. Questa limitazione si applica specificamente al plugin yboutput.

• Il plugin pgoutput non è supportato per Yugabyte.

• La globalizzazione non è supportata con il plugin yboutput

• Chiave primaria nella tabella: solo le tabelle con una chiave primaria sono supportate per lo streaming CDC in Yugabyte. La tabella che non dispone della chiave primaria non verrà acquisita da Oracle GoldenGate CDC Extract.

• Aggiornamenti chiave primaria in Yugabyte: un aggiornamento chiave primaria in Yugabyte verrà registrato come DELETE seguito da INSERT. Oracle GoldenGate Extract mostrerà le statistiche di un aggiornamento PK solo come DELETE e INSERT. Anche se le statistiche non verranno visualizzate come operazione di aggiornamento nelle statistiche di estrazione, non ci saranno discrepanze nei dati sull'origine e sulla destinazione.

• Comportamento dell'identità replica: l'identità della replica delle tabelle presenti al momento della creazione dello slot non può essere modificata dopo la creazione dello slot. Tuttavia, l'identità di replica di tutte le nuove tabelle create dopo la creazione dello slot può essere impostata utilizzando i flag ysql_yb_default_replica_identity, cdcsdk_publication_list_refresh_interval_secs e csdk_enable_dynamic_table_support tserver. Questi flag devono essere impostati sia nel master che in t-server prima di creare nuove tabelle.

  Per impostazione predefinita, cdcsdk_publication_list_refresh_interval_secs è impostato su 900 sec, ovvero 15 minuti. È necessario impostare questo secondo il vostro requisito. Se si diminuisce il valore, la tabella appena creata verrà aggiornata rapidamente nel modulo CDCSDK. Ciò consentirà a Oracle GoldenGate di acquisire i record per queste nuove tabelle. L'esempio seguente mostra i flag impostati per le tabelle create in modo dinamico dopo la creazione di SLOT.

  ysql_yb_default_replica_identity=FULL,cdcsdk_publication_list_refresh_interval_secs=120,cdcsdk_enable_dynamic_table_support=true

• La posizione in base alla fine del log (EOL) o alla fine del file (EOF) non è supportata: invece di EOL/EOF, è possibile modificare la posizione dello slot in base all'indicatore orario corrente, che filtrerà i record esistenti.

• Operazione di esecuzione: parametri quali GETTRUNCATES/IGNORETRUNCATES non sono supportati in quanto il database non consente all'utente di troncare la tabella se sono abilitati per l'acquisizione dei dati di modifica.

• Conservazione WAL: in genere Yugabyte rimuove i segmenti WAL dopo un certo periodo di tempo. Ciò significa che Oracle GoldenGate potrebbe perdere i dati di log WAL se i log vengono troncati quando Extract è inattivo per una durata maggiore. La conservazione WAL non è garantita in Yugabyte fino a quando un paio di parametri come cdc_intent_retention_ms e cdc_wal_retention_time_secs non vengono modificati per conservare i log WAL per una durata maggiore. Questa operazione deve essere modificata in tutti i nodi o in tutti i cluster in cui è in esecuzione il processo Extract di Oracle GoldenGate.

  I valori consigliati sono i seguenti:

  cdc_wal_retention_time_secs=86400

  cdc_intent_retention_ms = 86400000

• Comando UNREGISTER EXTRACT: Oracle GoldenGate utilizza il comando UNREGISTER EXTRACT per eliminare lo slot di replica. Uno slot di replica può essere eliminato solo dopo che il client che lo utilizza è stato arrestato per almeno ysql_cdc_active_replication_slot_window_ms durata. Il valore predefinito del flag è 5 minuti. Ciò significa che è necessario attendere la finestra di tempo massima per la quale uno slot di replica può rimanere inattivo prima di essere considerato non più valido.

  In caso di configurazione di un cluster, questo parametro deve essere regolato in tutti i nodi con lo stesso valore.

• Limitazioni di BLOB/CLOB: il tipo di dati come testo/immagine ha la limitazione di acquisire solo 200 MB di dati. La dimensione della riga non deve superare i 32 MB e ogni colonna contenente i dati lob deve essere mantenuta fino a 2 MB.

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

• Limitazioni con SAVEPOINT e rollback nelle operazioni DML: Oracle GoldenGate CDC Extract non supporta le operazioni di rollback SAVEPOINT. Il plugin CDC test_decoding non rispetta i comandi ROLLBACK TO SAVEPOINT. Di conseguenza, i record che avrebbero dovuto essere esclusi a causa di un rollback vengono ancora acquisiti ed elaborati dall'estrazione.

  Questo comportamento è una limitazione nota del modulo SDK CDC Yugabyte. Per ulteriori informazioni, fare riferimento ai seguenti collegamenti:

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

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

• Limitazione della tabella di rimozione: una volta creato uno slot, l'utente non deve eliminare alcuna tabella dal database finché lo slot non viene eliminato. Se lo slot è attivo e l'utente tenta di eliminare una tabella dal database, CDC Extract non sarà in grado di acquisire record da altre tabelle CDC che fanno parte della replica. Inoltre, si suggerisce che quando l'estrazione CDC è in esecuzione, anche l'utente non dovrebbe eliminare alcuna tabella nel database in cui viene creato lo slot. In caso contrario, CDC Extract interromperà l'errore di disconnessione simile al seguente:

  Error: The server has ended the streaming connection.

• Limitazione su statement_timeout: il parametro Yugabyte statement_timeout non deve essere modificato a livello di utente o di database e deve essere mantenuto come predefinito. Se è impostato su un valore inferiore, CDC Extract non sarà in grado di leggere i record da WAL. Se necessario, deve essere sempre impostato solo a livello di sessione.

• La creazione dello slot nel nodo di replica con modalità di sola lettura non è supportata: CDC Extract non sarà in grado di acquisire i record dal nodo di replica. Questo perché la versione supportata come la versione 2024.2.1.0 o la versione 2024.2.2.0 si basa su PostgreSQL 11.2, che non supporta la creazione dello slot nel nodo di replica.