Semantica di Checkpoint, Recovery e Delivery

Scopri di più su checkpoint, ripristino e consegna dalla configurazione dei flussi di dati.

Il contratto pubblico pos

Per impostazione predefinita, ogni record DML o DDL non metadati include un token pos opaco. Internamente, il token contiene informazioni di posizionamento GoldenGate sufficienti per identificare un record, incluse le informazioni di commit o sequenza, l'identità della transazione e il sequenziamento dei record. La sua codifica non è un formato di coordinate di origine pubblica e può variare in base al tipo di origine e alla release.

Do Non
Memorizzare la stringa esatta dopo l'elaborazione riuscita. Analizza per ottenere Oracle SCN, PostgreSQL LSN, coordinata binlog MySQL, SQL Server LSN o qualsiasi altro offset specifico dell'origine.
Portalo al flusso di dati, al contratto trail di origine e al consumatore. Confronta le posizioni in modo lessicale o numerico per determinare l'ordine.
La codifica percentuale viene utilizzata come begin in un URL. Taglia, normalizza, concatena, decifra o riscrivi.
Utilizzare campi separati csn, xid, opSeqno e transInd per la diagnostica o l'analisi delle transazioni. Riutilizzare una posizione da un altro flusso, un contratto di filtro diverso o un altro ambiente.

Portabilità dell'origine: l'algoritmo di recupero client è intenzionalmente lo stesso per Oracle, PostgreSQL, MySQL, SQL Server e altre origini supportate: rendere persistente l'opaco pos e restituirlo invariato. L'analisi delle coordinate specifica dell'origine non è né richiesta né supportata dal contratto client Data Streams.

Un checkpoint deve rappresentare l'ultimo record il cui effetto aziendale è durevole. Il salvataggio prima che l'azienda scriva può perdere dati dopo un crash. Il salvataggio dopo una scrittura non idempotente in una transazione separata può produrre un duplicato dopo un crash.

Pattern end-to-end esattamente una volta

Pattern Funzionamento Usa quando
Affondamento atomico e transazione checkpoint Scrivere il record attività e il nuovo pos nella stessa transazione del database. Il sink e il checkpoint possono condividere un datastore transazionale.
Chiave di idempotenza Utilizzare pos, o una chiave business più l'identità operazione, come chiave univoca; il nuovo tentativo dello stesso record diventa un'operazione non operativa. Il sink supporta l'unicità o le scritture condizionali.
Log temporaneo durevole Aggiungere il record e pos atomicamente a un log durevole, quindi elaborare il log in modo indipendente. L'elaborazione aziendale è lenta, a più fasi o si estende ai sistemi.
Almeno una volta con riconciliazione Accetta duplicati, deduplica periodicamente e riconcilia conteggi o checksum. Il caso d'uso tollera eventuali correzioni.

NOTA: Data Stream exactlyOnce descrive la risposta di eliminazione e recupero duplicati lato servizio. Non produce un effetto collaterale arbitrario a valle esattamente una volta perché il protocollo WebSocket non ha alcuna conferma transazionale per record con il client.

Quality of Service

Vedere le linee guida sulla qualità del servizio riportate nella tabella riportata di seguito.

Modalità Duplica Posizione salvata non disponibile Uso consigliato
exactlyOnce Elimina i duplicati riconosciuti durante il recupero e la gestione del riavvio/interruzione del trail di origine. Connessione non riuscita con un errore. Impostazione predefinita per l'elaborazione aziendale permanente. Coppia con logica di consumo atomica o idempotente.
atLeastOnce Non sopprime i duplicati durante il recupero e la gestione del riavvio/interruzione del trail di origine. Connessione non riuscita con un errore. Utilizzare quando si preferisce la ripetizione e il consumatore è progettato per la deduplicazione.
atMostOnce Elimina i duplicati riconosciuti. Il servizio trova il record disponibile successivo e continua, il che può saltare i dati. Utilizzare solo quando la perdita di dati è esplicitamente accettabile e l'avanzamento in avanti è più importante della completezza.

Metadati delle transazioni e ordini

Per i metadati delle transazioni e i requisiti per gli ordini, fare riferimento alla tabella seguente:

Campo Scopo Limitazioni
xid Raggruppa i record associati a una transazione di origine. Il formato dipende dall'origine e deve essere considerato una stringa.
csn Mostra il numero di sequenza del commit di origine se configurato. Il significato e il formato dipendono dall'origine; non utilizzare come token di riavvio.
opSeqno Numero di sequenza record all'interno della transazione. Abilitarla e facoltativamente rinominarla in modo esplicito.
transInd B prima, M metà, E ultima, o W transazione intera/singola operazione. L'applicazione di filtri può rimuovere i record e rendere incompleta la sequenza osservata. L'elaborazione coordinata può anche ridurre l'utilità.
pos Posizione di recupero univoca per il record. Opaco; non ordinare o derivare i confini delle transazioni dal suo testo.

Non presumere che una connessione inizi sempre al limite di una transazione. Una ricerca dell'indicatore orario o un limite della traccia mantenuta possono iniziare dopo che le operazioni precedenti non sono più disponibili. Se l'applicazione richiede transazioni di origine complete, progettare un buffer di transazioni, definire limiti per transazioni di grandi dimensioni e specificare cosa fare quando l'inizio di una transazione non è disponibile.

Quando una posizione salvata non è disponibile

Per controllare una posizione salvata che diventa non disponibile, controllare quanto riportato di seguito.

Pianificazione della conservazione dei trail

Imposta la retention dei trail per superare l'obiettivo del punto di recupero, oltre al rilevamento operativo e al tempo di risposta. Ad esempio, un consumer che può essere offline per 24 ore e richiede 12 ore per la risposta agli incidenti richiede più di 36 ore di trail disponibile, con margine aggiuntivo per backlog e manutenzione di grandi dimensioni. bufferSize non estende la conservazione dei trail.