Il vostro sistema di sviluppo del CDC non è fermo. Siete sicuri che sia in salute?

Non è necessario che un oleodotto del CDC fallisca per creare un rischio.

A volte la replica è ancora in corso. Lo stato del processo è verde. La destinazione è ancora disponibile. Ma il backlog sta crescendo.

L'obiettivo sta diventando sempre più obsoleto. E ogni minuto che passa, le opzioni di ripristino potrebbero diventare più limitate. La domanda non è semplicemente: "La replica è in esecuzione?", ma: "La replica è al passo con i tempi?" .

E se non lo è: "Quanto tempo abbiamo prima che questo diventi un problema di recupero?"

Il monitoraggio CDC più efficace non si limita a comunicare agli operatori se un processo è attivo o inattivo. Li aiuta a riconoscere quando una pipeline apparentemente sana si sta silenziosamente dirigendo verso una situazione da cui sarà più difficile riprendersi in seguito.

Un buon monitoraggio aiuta i team a rispondere a queste domande:

• Quanto siamo indietro?
• L'arretrato sta aumentando o diminuendo?
• Il progetto del gasdotto sta effettivamente procedendo?
• I team a valle stanno già utilizzando dati obsoleti?
• Siamo ancora consapevoli delle opzioni di recupero a nostra disposizione se la situazione dovesse peggiorare?

L'obiettivo non è prevedere ogni fallimento, ma individuare i problemi in fase iniziale con sufficiente anticipo da dare al team ancora delle alternative.

A seconda delle piattaforme di origine e di replica, un monitoraggio efficace del CDC può includere metriche e concetti quali ritardo di replica, crescita del backlog, ritardo di applicazione tra origine e destinazione, stato di riavvio, posizione del log, cronologia delle modifiche conservate, log archiviati, progressione RBA/LRSN, comportamento di recupero e esposizione dei dati a valle. La terminologia esatta varia, ma l'obiettivo è sempre lo stesso: capire se la replica sta tenendo il passo e se il ripristino rimane semplice in caso di peggioramento delle condizioni.

Come posso rilevare se una pipeline CDC sta accumulando ritardi prima che si blocchi?

Una pipeline può essere in esecuzione mentre il ritardo aumenta, il backlog cresce e i dati a valle diventano obsoleti.

Risposta rapida: Inizia rispondendo a cinque domande operative:

1. Quanto siamo indietro?
2. L'arretrato è in aumento, stabile o in diminuzione?
3. Disponiamo ancora della cronologia delle fonti che potrebbe esserci utile in caso di necessità di recupero?
4. Il progetto del gasdotto sta effettivamente procedendo?
5. Chi si affida già ai dati a valle e c'è qualcosa che ci indichi un peggioramento della situazione?

Le metriche esatte e le soglie di allerta dipendono dalla sorgente, dalla destinazione, dalla piattaforma di replica, dal carico di lavoro, dai requisiti di ripristino e dal caso d'uso successivo. Non esiste un numero universale di minuti, record o spazio di log che definisca un'emergenza CDC.

Una condotta può risultare "in funzione" pur essendo in procinto di presentare un problema di ripristino.

Il monitoraggio deve rispondere a due domande diverse

1. Il programma di sviluppo è in buone condizioni al momento?

Questa è la questione operativa immediata. Si tratta di replica:

• Riuscite a stare al passo?
• Sei rimasto indietro?
• Bloccato?
• In fase di recupero?
• Funziona in uno stato degradato?

Lo stato del processo è parte della risposta, ma non è la risposta completa.

2. Stiamo perdendo opzioni di recupero con l'aumentare del ritardo?

Questa è la domanda più difficile. Una pipeline può essere ancora attiva mentre:

• L'arretrato continua ad aumentare
• L'obiettivo diventa sempre più obsoleto
• Il recupero richiede più tempo
• I team a valle continuano a utilizzare dati obsoleti
• Modifiche alla cronologia della fonte disponibili
• Un problema operativo relativamente circoscritto si trasforma in un problema di recupero di più ampia portata.

La domanda più importante è: "Se la situazione dovesse peggiorare ulteriormente, saremmo ancora in grado di capire come riprenderci?"

1. Quanto siamo indietro?

Il ritardo di replica indica di quanto la destinazione è rimasta indietro rispetto all'attività corrente della sorgente. Tuttavia, un semplice numero non è sempre sufficiente. Un arretrato di 100.000 modifiche può essere irrilevante in un ambiente e significativo in un altro. Ciò che gli operatori devono generalmente comprendere è: "Che impatto ha questo ritardo in termini di tempo e di attività aziendale?".

Indicatori di ritardo di replicazione del CDC: cosa misurare e come interpretarli

Piattaforme diverse mostrano ritardi e progressi in modo differente. A seconda della sorgente, della destinazione e della tecnologia di replica, un monitoraggio utile può includere:

• ritardo di replica trascorso
• ritardo lato sorgente
• obiettivo o applicare ritardo
• modifiche o arretrati delle transazioni
• posizione della sorgente rispetto alla posizione di elaborazione corrente
• profondità della coda o dell'attività
• flusso di lavoro
• timestamp dell'ultima elaborazione riuscita
• tendenza al recupero
• Informazioni sullo stato e sulla diagnostica specifiche della piattaforma

I nomi esatti delle metriche sono meno importanti della capacità degli operatori di rispondere:

• Quanto siamo indietro?
• Dove si trova il ritardo?
• La situazione sta migliorando?

Chiedere

• Quanto dista l'obiettivo?
• Quando è iniziato il ritardo?
• È normale che questo carico di lavoro sia così elevato durante questo periodo?
• Quali sistemi a valle dipendono da questi dati?
• A che punto il ritardo diventa rilevante per loro?

Perché è importante

Un obiettivo con un ritardo di cinque minuti può essere accettabile per un determinato carico di lavoro e inaccettabile per un altro. La metrica tecnica deve essere interpretata nel contesto dei dati utilizzati.

Che aspetto ha il bene

Il team operativo può affermare: "Siamo in ritardo di circa questa cifra, e questo è ciò che comporta per i sistemi che utilizzano i dati".

Non semplicemente: "L'attività è ancora in esecuzione".

2. L'arretrato è in aumento, stabile o in diminuzione?

La direzione del ritardo può essere importante tanto quanto la sua entità. Un gasdotto che è significativamente indietro ma che sta recuperando rapidamente rappresenta una situazione diversa da un gasdotto con un ritardo minore che sta perdendo terreno costantemente. Gli esperti spesso descrivono questa situazione in modo molto semplice: "Sta andando a fuoco?".

Chiedere

• L'arretrato sta aumentando?
• Si è stabilizzato?
• Si sta restringendo?
• Il flusso di nuove fonti è al passo con l'attività di sviluppo?
• Il lavoro viene elaborato più velocemente di quanto ne arrivino i nuovi da recuperare?
• La tendenza è cambiata da quando è iniziato l'incidente?

Tasso di cattura rispetto al tasso di elaborazione o di applicazione

Laddove la piattaforma metta a disposizione metriche appropriate, il confronto tra le modifiche che entrano nel flusso di replica e quelle elaborate sul target può aiutare a capire se l'ambiente sta migliorando o peggiorando. Le misurazioni specifiche variano a seconda della piattaforma. Il principio è semplice: se il flusso di nuove attività continua ad aumentare più velocemente di quanto la pipeline riesca a elaborarle per un periodo prolungato, il backlog continuerà a crescere anche se il processo non si è interrotto.

Che aspetto ha il bene

Gli operatori possono distinguere rapidamente: rimanere indietro → mantenere un ritmo costante → recuperare

Bandiera rossa

Il pannello di controllo indica il ritardo attuale, ma non se la situazione sta migliorando.

4. Il progetto sta effettivamente procedendo?

Un processo può essere attivo anche senza che i dati progrediscano in modo significativo.

Ciò rende la prova di un'attività di elaborazione andata a buon fine un importante controllo di coerenza.

A seconda della piattaforma, i team possono prendere in considerazione:

• attività di replicazione più recente e riuscita
• modifica elaborata più recente
• applicare l'obiettivo più recente
• avanzamento in una posizione salvata o stato di elaborazione
• movimento arretrato
• flusso di lavoro
• un altro indicatore di progresso specifico della piattaforma

Chiedere

Si è effettivamente verificato qualche progresso?

Poi:

Sta avanzando al ritmo che ci aspetteremmo da questa fonte e da questo carico di lavoro?

La risposta deve tenere conto del normale schema di attività del sistema.

Un ambiente transazionale ad alto volume può normalmente subire continue modifiche.

Un'altra fonte potrebbe avere periodi legittimi di scarsa o nulla attività.

Perché è importante

Questo aiuta a identificare la situazione di disagio in cui:

"Dice che è in esecuzione, ma non si muove niente."

Che aspetto ha il bene

L'ambiente di monitoraggio aiuta a distinguere:

La sorgente è naturalmente silenziosa

da

La replicazione ha smesso di fare progressi.

Bandiera rossa

L'unico controllo di integrità consiste nel verificare se il processo di replica è attivo.

5. Chi sta già utilizzando dati obsoleti?

Molti problemi dei CDC iniziano come problemi tecnici e in seguito si trasformano in problemi aziendali:

La sorgente potrebbe essere ancora funzionante. La destinazione potrebbe essere ancora disponibile. La replica potrebbe essere ancora in esecuzione. Ma report, dashboard, API, sistemi operativi e ambienti di analisi potrebbero già basarsi su dati sempre più obsoleti.

Questo crea una delle modalità di fallimento più pericolose per i CDC: gli schermi sono accesi, ma i dati diventano obsoleti.

Chiedere

• Quali applicazioni dipendono dal bersaglio interessato?
• Quali report o dashboard lo utilizzano?
• I dati vengono ancora utilizzati per analisi, API, sistemi operativi o carichi di lavoro di intelligenza artificiale?
• Qualcuno a valle sa che il flusso di dati è obsoleto?
• Si sta avvicinando una scadenza importante per la rendicontazione, la liquidazione, l'elaborazione di un lotto, la gestione di un cliente o un'operazione?
• L'utilizzo a valle deve essere sospeso o limitato durante le indagini sul problema?

Perché è importante

Diverse cose molto diverse tra loro possono essere vere contemporaneamente:

• La fonte è sana.
• L'obiettivo è disponibile.
• L'oleodotto è in ritardo.
• Le persone continuano a utilizzare il bersaglio.

Ciò può rendere più difficile rilevare l'esposizione a dati obsoleti rispetto a un'interruzione completa del servizio.

Che aspetto ha il bene

Il team può rispondere:

"Ecco quanto sono obsoleti i dati, questi sono i consumatori interessati e queste persone conoscono la situazione attuale."

6. Avvisi, errori o eventi ambientali ci indicano che qualcosa sta cambiando?

Non ogni avvertimento corrisponde a una crisi.

Inoltre, ricevere notifiche per ogni singolo messaggio può generare un rumore di fondo tale da indurre gli operatori a perdere fiducia nel sistema di monitoraggio.

L'obiettivo è identificare gli eventi rilevanti nel proprio ambiente e interpretarli nel loro contesto.

I segnali utili possono includere

• errori di connettività ripetuti
• errori di applicazione del target
• tentativi
• modifiche all'autenticazione o alle autorizzazioni
• cambiamenti insoliti nel ritardo
• manutenzione della fonte o della destinazione
• messaggi diagnostici specifici della piattaforma

Osservate l'ambiente circostante l'oleodotto.

Un cambiamento nel comportamento di replicazione che coincide con:

• un evento Db2
• una IPL
• manutenzione delle infrastrutture
• un cambiamento di rete
• una modifica della sicurezza
• un aggiornamento dello schema o della configurazione
• un periodo di carico di lavoro importante

potrebbe essere necessario interpretarlo in modo diverso rispetto a un evento di replicazione isolato.

Ciò non significa che l'evento di origine abbia necessariamente causato il problema del CDC.

Significa che gli operatori dovrebbero essere in grado di visualizzare un contesto sufficiente per indagare sulla relazione.

Che aspetto ha il bene

Il team sa:

• cosa richiede un intervento immediato
• cosa necessita di indagine
• cosa si può osservare
• quando è giustificata un'escalation più ampia

Bandiera rossa

Uno dei due estremi:

Ogni avvertimento sveglia qualcuno

or

Gli avvertimenti vengono ignorati fino all'arresto dell'oleodotto.

Come si dovrebbero impostare le soglie di allerta per i ritardi del CDC?

Quanto ritardo del CDC è eccessivo?

Non esiste una soglia universale che funzioni in tutti gli ambienti CDC dei mainframe.

Una soglia di allerta efficace dovrebbe riflettere fattori quali:

• volume normale delle transazioni
• valuta dei dati previsti
• tolleranza a valle per i dati obsoleti
• disponibilità della cronologia delle fonti
• obiettivi di recupero
• modelli di carico di lavoro
• tempo di risposta del team
• orari di chiusura aziendali
• conseguenze della mancata risposta

Invece di copiare una regola generica come:

"Avviso dopo 30 minuti di ritardo."

chiedere:

“A che punto questa condizione inizia a minacciare i requisiti di validità dei dati, operativi o di ripristino di cui disponiamo effettivamente?”

Quella è la soglia attorno alla quale vale la pena progettare.

Crea avvisi basati sulle decisioni, non solo sui numeri.

Un avviso utile dovrebbe aiutare qualcuno a decidere cosa fare dopo.

Un modello semplice è il seguente:

Indagare

Qualcosa si è spostato al di fuori dell'intervallo previsto dall'ambiente.

Alcuni esempi possono includere:

• il ritardo inizia a mostrare una tendenza al rialzo
• rallentamento del processo di elaborazione
• ripetuti avvertimenti
• cambiamenti inspiegabili nella produttività

Il compito immediato è capire il perché.

Atto

La condizione sta influenzando in modo significativo un requisito operativo o aumentando la complessità del ripristino.

Le azioni possono includere:

• indagine su un collo di bottiglia target
• esaminare le condizioni della fonte o dell'infrastruttura
• coinvolgendo una squadra adiacente
• revisione delle informazioni di origine da cui dipende il percorso di ripristino
• proteggere gli utenti a valle dai dati obsoleti
• preparazione per un recupero controllato

Inasprire

Il problema ha superato le normali competenze operative del team tecnico o ha iniziato a influenzare decisioni più ampie in materia di business, rischi o servizi.

Ciò potrebbe richiedere il coinvolgimento di:

• leadership in materia di dati o piattaforme
• operazioni mainframe
• proprietari del sistema a valle
• parti interessate aziendali
• governance o rischio
• gestione degli incidenti

Le soglie saranno diverse.

Il percorso decisionale dovrebbe già esistere prima che venga attivato l'allarme.

Il test di osservabilità del CDC in due minuti: il vostro team è in grado di rispondere a queste cinque domande?

Una dashboard di monitoraggio non è utile solo perché visualizza delle metriche. È utile perché aiuta gli operatori a prendere decisioni. Provate questo test: un operatore normale riuscirebbe a rispondere alle seguenti cinque domande in meno di due minuti senza dover contattare uno specialista della piattaforma?

Ciò è in linea con le linee guida operative più ampie di Google Site Reliability Engineering, che considerano il monitoraggio come un modo per valutare lo stato di salute del servizio, diagnosticare i problemi, identificare le tendenze e confrontare il comportamento nel tempo, non semplicemente per raccogliere o visualizzare metriche.*

1. Quanto siamo indietro?

L'operatore è in grado di identificare il ritardo o l'arretrato attuale?

2. La situazione sta migliorando o peggiorando?

Sono in grado di stabilire se l'arretrato sta aumentando, rimanendo stabile o diminuendo rapidamente?

3. L'elaborazione è effettivamente in corso?

Possono identificare le attività recenti che hanno avuto successo, invece di affidarsi a uno stato generico "In esecuzione"?

4. Se questo evento dovesse richiedere un intervento di recupero, comprendiamo da cosa dipende tale recupero?

Sono in grado di determinare quali informazioni storiche, statali o di altro tipo sarebbero rilevanti?

5. Chi è già stato colpito?

Sono in grado di identificare quali sistemi o team a valle potrebbero basarsi su dati obsoleti?

Se l'operatore non è in grado di rispondere a queste cinque domande in circa due minuti, chiedi:

• Quali informazioni mancano?
• Cos'è distribuito su troppi strumenti?
• Cosa richiede un'interpretazione specialistica?
• Quale contesto esiste solo nella testa di qualcuno?
• Quale procedura di monitoraggio o operativa deve essere modificata?
• La suddivisione in due minuti è un'euristica operativa pratica, non un parametro di riferimento del settore.
• Ciò che conta è il principio:

La persona che interviene sul luogo dell'incidente deve essere in grado di comprendere la situazione con sufficiente rapidità per poter agire.

Per una pipeline di importanza operativa, un monitoraggio che può essere interpretato solo da uno specialista di piattaforma non è sufficiente.

Come monitorare il recupero del CDC dopo un'interruzione

Come fai a sapere se il CDC sta effettivamente recuperando il ritardo? Il monitoraggio non si interrompe una volta che il processo riprende. Durante il recupero, chiediti:

• L'arretrato si sta riducendo?
• Con che velocità si sta riducendo?
• Continuano ad arrivare nuove attività da fonti?
• L'elaborazione riesce a tenere il passo con le nuove attività, riducendo al contempo il divario?
• Si verificano errori o tentativi di ripetizione?
• Che impatto sta avendo il processo di recupero sulla fonte e sul bersaglio?
• I sistemi a valle utilizzano ancora dati obsoleti?
• Quali prove ci diranno che il recupero è effettivamente completo?

La distinzione fondamentale è:

correre di nuovo

rapporto

raggiunto

rapporto

recuperato e convalidato.

Non si tratta necessariamente dello stesso stato.

I modelli di carico di lavoro dei mainframe possono cambiare l'aspetto della "normalità".

Gli ambienti mainframe spesso presentano periodi di funzionamento distinti:

• picco di elaborazione online
• lotto notturno
• fine della giornata
• fine mese
• chiusura finanziaria
• picchi stagionali
• manutenzione programmata

Un ritardo che risulta normale in un determinato periodo può segnalare un problema in un altro.

• Lo stesso vale per:
• carico di lavoro di origine
• registrare o modificare il volume
• pressione bersaglio
• capacità di recupero disponibile
• controversia sulle infrastrutture

Evitate di definire "sano" basandovi su un singolo valore medio.

Monitorare la pipeline nel contesto del carico di lavoro che supporta.

Quando il sistema di monitoraggio rileva un problema: qual è la prima cosa da fare?

Il monitoraggio offre ai team qualcosa che, prima o poi, manca a ogni sforzo di recupero: il tempo.

Quanto prima si individua un problema in fase iniziale, tanto maggiori saranno le opzioni di recupero disponibili.

Conferma cosa sta effettivamente accadendo

La condizione è transitoria o persistente?

In quale punto del percorso di replica il processo rallenta o si arresta?

Stabilire la tempistica

Da quanto tempo si verifica questo problema?

Quando è stata confermata l'ultima attività andata a buon fine?

Comprendere l'arretrato

Quanto sei indietro?

Sta crescendo o bruciando?

Identificare l'esposizione a valle

Chi sta già puntando su questo obiettivo?

Devono sapere che i dati potrebbero essere obsoleti?

Preservare lo stato attuale

Prima di apportare modifiche sostanziali, è importante acquisire informazioni rilevanti su stato, errori, timestamp, diagnostica e altri elementi di prova.

Decidere se si tratta ancora di una questione di monitoraggio o se è diventata una decisione di recupero.

Se la condotta si ferma o le condizioni si deteriorano a tal punto da rendere necessarie azioni di recupero, è preferibile adottare un processo di recupero strutturato piuttosto che improvvisare.

Il mio programma di sviluppo del CDC è in ritardo. Riuscirò a recuperare?

Il ritardo di per sé non significa che i dati siano andati persi.

Un arretrato in aumento non significa automaticamente che sarà necessario un riavvio completo.

Ma il ritardo potrebbe trasformarsi in un problema di recupero quando il team non è in grado di rispondere con sicurezza a domande come:

• Quanto siamo indietro?
• L'arretrato si sta riducendo?
• Qual è lo stato di ripristino/processo attuale?
• Da quale fonte storica dipenderebbe il recupero?
• Quanto tempo ci vorrà probabilmente per recuperare il tempo perduto?
• Chi sta consumando dati obsoleti?
• Cosa succede se l'oleodotto si ferma completamente?
• Come dimostreremo in seguito che il bersaglio è affidabile?

A quel punto, la domanda utile cambia da:

"La replica è in esecuzione?"

A:

"Sappiamo ancora come potremmo riprenderci dalla situazione attuale?"

Come Rocket Data Replicate & Sync supporta la visibilità operativa

Rocket Data Replicate & Sync (RDRS) offre funzionalità di monitoraggio operativo e diagnostica che possono aiutare i team a comprendere lo stato degli ambienti di replica supportati.

La convalida tecnica di RDRS identifica le seguenti capacità:

• informazioni sullo stato del processo
• informazioni sulla mobilità
• tracce
• controlli di latenza
• stato di riavvio/processo memorizzato per le configurazioni supportate

Le metriche esatte visualizzate dall'operatore, le coordinate di riavvio, gli avvisi e il comportamento di monitoraggio possono variare in base a origine, destinazione, versione, topologia e configurazione.

I team che valutano RDRS dovrebbero quindi chiedere a Rocket di dimostrare l'esperienza di monitoraggio nel loro specifico ambiente.

Tra le domande utili figurano:

• Cosa può vedere l'operatore quando la replica inizia a rimanere indietro?
• Quali informazioni sulla latenza o sullo stato del processo sono disponibili?
• Come può il team capire se la replicazione sta procedendo bene?
• Quali errori e diagnostici vengono rilevati?
• Quali stati di riavvio/processo salvati possono ispezionare gli operatori?
• Cosa può vedere il team durante la fase di recupero o di ripartenza?
• In che modo il monitoraggio si integra nel modello operativo più ampio dell'organizzazione?
• Quali cambiamenti nel comportamento del sistema dovrebbero essere misurati durante la fase di recupero ad alto volume?

Le affermazioni relative all'impatto sulla produzione dovrebbero essere valutate anche utilizzando dati specifici per ciascuna fonte, sia in condizioni di carico di lavoro normale che di recupero.

Lo standard utile non è:

"Il sistema RDRS è monitorato?"

È:

"Il nostro operatore abituale è in grado di capire cosa sta succedendo con sufficiente rapidità da poter prendere la decisione giusta?"

Lista di controllo per la preparazione al monitoraggio del CDC

Prima di affidarsi a una pipeline CDC su mainframe per dati importanti da elaborare a valle, chiedetevi:

• Possiamo vedere quanto è indietro la replicazione?
• Possiamo stabilire se l'arretrato è in aumento, stabile o in diminuzione?
• Possiamo stabilire se l'elaborazione sta effettivamente procedendo?
• Comprendiamo da quali informazioni di origine potrebbe dipendere il percorso di ripristino supportato?
• Sappiamo quali sistemi a valle dipendono dal bersaglio interessato?
• Possiamo individuare quando questi sistemi potrebbero utilizzare dati obsoleti?
• Sono visibili errori e informazioni diagnostiche significative?
• Possiamo correlare il comportamento di replica a eventi rilevanti relativi alla sorgente, alla destinazione o all'infrastruttura?
• Le soglie di allerta si basano sul nostro ambiente o su valori predefiniti generici?
• Ogni avviso significativo corrisponde a un'azione o a una decisione di escalation?
• Possiamo monitorare i progressi durante il periodo di recupero?
• Il normale team operativo è in grado di rispondere rapidamente alle principali domande sullo stato di salute senza l'aiuto di specialisti?

Se diverse risposte sono negative, è possibile che tu disponga di dati di monitoraggio.

Potresti non avere ancora una visibilità operativa sufficiente.

In definitiva

La maggior parte dei problemi di ripresa del CDC non inizia con un'interruzione completa. Iniziano con un flusso di lavoro in ritardo, un arretrato che nessuno ha spiegato e un obiettivo che diventa sempre più obsoleto mentre il processo appare ancora in buone condizioni.

Un buon monitoraggio aiuta i team a rispondere a queste domande:

• Quanto siamo indietro?
• L'arretrato sta aumentando o diminuendo?
• La replicazione sta effettivamente facendo progressi?
• Chi è già esposto a dati obsoleti?
• Se questo dovesse trasformarsi in un evento di recupero, saremmo ancora consapevoli delle opzioni a nostra disposizione?

L'obiettivo non è raccogliere più dati statistici.

Si tratta di individuare un problema in fase di sviluppo con sufficiente anticipo da consentire agli operatori di intervenire quando il ripristino è ancora semplice.

*Google SRE: Monitoraggio dei sistemi distribuiti

Successivamente: Prima di riavviare

Se la pipeline si interrompe, o il ritardo è tale da richiedere un intervento di ripristino, è necessario passare dalla fase di monitoraggio a una decisione strutturata in merito al ripristino.

Prima di riavviare una pipeline CDC fallita: 7 domande a cui rispondere

Analizza nel dettaglio il punto in cui la replica si è interrotta, dove può riprendere, cosa è successo durante l'interruzione, se potrebbe essere necessario un recupero o una risincronizzazione più ampia e come dimostrerai in seguito che il sistema di destinazione è affidabile.