L'errore più pericoloso nel recupero del CDC si verifica dopo il fallimento

Quando una pipeline del CDC si blocca, l'istinto è automatico: farla ripartire. In fretta.

Nel frattempo, la fonte potrebbe essere ancora impegnata nell'elaborazione delle transazioni. L'arretrato potrebbe continuare ad aumentare. Report, applicazioni e processi a valle potrebbero già funzionare con dati obsoleti.

E prima o poi qualcuno si pone la domanda: possiamo semplicemente riavviarlo?

È solitamente in quel momento che la guarigione diventa più difficile.

Perché il vero problema spesso non è il guasto in sé, ma tutto ciò che è accaduto mentre la replica non era in funzione.

• Cosa è successo durante questo periodo di interruzione?
• Possiamo riprendere in sicurezza da dove avevamo interrotto?
• Abbiamo bisogno di una risincronizzazione o di un riavvio completo?
• Come facciamo a sapere che non ci è sfuggito nulla?

Un riavvio riuscito dimostra una sola cosa: la replica è di nuovo in funzione.

Ciò non dimostra che l'obiettivo sia completo, aggiornato o corretto.

I guasti più pericolosi dei CDC non sono sempre quelli in cui la replica si interrompe. Sono quelli in cui la replica riprende e nessuno è in grado di spiegare cosa sia successo durante l'interruzione o di dimostrare che i dati recuperati siano affidabili.

L'obiettivo non è semplicemente riavviare il sistema il più rapidamente possibile, ma evitare che un singolo errore si trasformi in un ripristino più complesso. Un processo di replica interrotto non significa automaticamente che le transazioni siano andate perse. E un riavvio riuscito non significa automaticamente che la destinazione sia corretta.

Come verificare se un errore nella pipeline del CDC ha causato la perdita di dati e se è possibile riavviarla in sicurezza.

Il primo passo è non premere Riavvia.

Le attuali linee guida del NIST per la gestione degli incidenti separano le fasi di rilevamento, risposta, ripristino e miglioramento continuo. Questa disciplina più ampia favorisce la comprensione dell'accaduto e la conservazione di un contesto sufficiente per prendere una decisione di ripristino difendibile prima di modificare l'ambiente.*

Serve a stabilire dove si è interrotta l'elaborazione, cosa è continuato ad accadere alla fonte, qual è la situazione attuale ai fini del recupero e quali prove saranno necessarie in seguito.

Considerate nell'ordine corretto, le sette domande seguenti vi aiuteranno a svolgere questo processo.

Cosa esattamente non ha funzionato e quando?

Il messaggio "Replica interrotta" non è sufficientemente specifico per scegliere un percorso di ripristino.

Innanzitutto, individua dove si è verificato il problema. Si è verificato un problema di replica?

• completamente fermato?
• Continuo a correre ma sono in ritardo?
• Riuscite a cogliere i cambiamenti ma non a portarli avanti?
• Impossibile applicare le modifiche al target?
• interessato da un evento del sistema sorgente?
• influenzato dal target, dalla rete o da un'altra parte dell'ambiente?

Quindi, stabilite la cronologia degli eventi. Il momento in cui qualcuno ha notato il problema potrebbe non coincidere con il momento in cui il problema è effettivamente iniziato.

Controllo

• Quando si è verificata l'ultima attività di replicazione confermata con successo?
• L'acquisizione della sorgente è ancora in corso?
• La fase di elaborazione a valle sta procedendo?
• La procedura di candidatura a Target sta procedendo?
• La fonte ha continuato a elaborare le transazioni?
• L'obiettivo è disponibile?
• È cambiato qualcosa nello stesso periodo: schema, configurazione, sicurezza, infrastruttura, manutenzione o carico di lavoro?

Perché è importante

Un errore di acquisizione, un errore di applicazione, un backlog in crescita e un'interruzione del sistema di destinazione sono problemi diversi. Potrebbero richiedere team diversi e azioni di ripristino diverse. Si è pronti a procedere quando si può affermare: "Ecco dove si è interrotto il processo, ecco quando è successo e ecco cosa è interessato". Non semplicemente: "La replica è interrotta da qualche parte".

Dove è possibile riprendere la replica in sicurezza?

Questa è una delle domande più importanti nel processo di ripristino. Le piattaforme di replica possono memorizzare lo stato del processo o del riavvio, il che aiuta a determinare da dove l'elaborazione può riprendere dopo un'interruzione.

A seconda della fonte e della piattaforma, potresti imbatterti in termini come:

• Riavvia lo stato
• Checkpoint  
• Segnalibro
• Log di attacco
• Posizione di curriculum vitae
• Un'altra coordinata di recupero specifica della fonte

Non date per scontato che questi termini abbiano esattamente lo stesso significato su ogni piattaforma. La questione importante è se sia possibile identificare il punto in cui l'elaborazione si è interrotta e se tali informazioni siano sufficientemente affidabili da consentire il ripristino.

Indicatori di ripristino CDC per mainframe: stato di riavvio, posizioni dei log e Db2 per z/OS RBA/LRSN

A seconda della sorgente e della piattaforma di replica, i team potrebbero incontrare diversi marcatori di ripristino e terminologie relative alla posizione di elaborazione. Per gli ambienti Db2 per z/OS, questi concetti possono includere RBA o LRSN.

La questione fondamentale è se esistano informazioni di ripristino valide e salvate e se il team comprenda cosa rappresentino tali informazioni. Per i processi RDRS Change Data Capture supportati, le informazioni di stato salvate consentono di riprendere l'elaborazione nella posizione corretta specifica per la sorgente dopo il riavvio. La posizione e la terminologia dipendono dalla tecnologia di origine.

Controllo

• È possibile salvare lo stato di riavvio/processo?
• Che cosa rappresenta esattamente quello stato?
• Quando è stato aggiornato l'ultima volta?
• Corrisponde allo stato di elaborazione previsto?
• La cronologia della fonte pertinente è ancora disponibile?
• È accaduto qualcosa nell'area di destinazione che possa modificare le ipotesi di recupero?

Perché è importante

Una posizione nota al momento del ripristino è molto diversa dal ricostruire dove si pensa che la pipeline si sia interrotta durante un incidente. Sei pronto ad andare avanti quando il team ha uno stato di riavvio/processo identificabile e comprende cosa significa per questa origine e destinazione.

Cosa è successo durante l'interruzione della replica e la cronologia di origine necessaria è ancora disponibile?

Se la sorgente ha continuato a funzionare, le transazioni potrebbero essere proseguite mentre la destinazione ha smesso di ricevere modifiche. Ciò significa che il team deve comprendere sia il divario di replica sia l'impatto a valle.

Controlla il divario

• Da quanto tempo l'obiettivo è in ritardo?
• Quanto è grande l'arretrato?
• L'arretrato è in aumento, stabile o in diminuzione?
• Quali fonti storiche sono ancora disponibili per il periodo in questione?
• Si sono verificati inserimenti, aggiornamenti, eliminazioni o modifiche dello schema supportate?
• La piattaforma offre un percorso di recupero supportato per questa combinazione di origine e destinazione?

Per la CDC basata su log, verificare la conservazione dei log di origine e la cronologia archiviata. In alcuni ambienti CDC basati su log, i log di origine conservati o archiviati possono essere rilevanti per l'elaborazione delle modifiche accumulate durante un'interruzione. I prerequisiti esatti variano a seconda di:

• fonte
• piattaforma
• configurazione
• storia conservata
• topologia
• durata e natura dell'interruzione

Non dare per scontato che l'esistenza di log archiviati significhi automaticamente che ogni percorso di ripristino rimanga disponibile. Verifica cosa supporta la piattaforma per l'ambiente specifico. Controlla chi sta già utilizzando la destinazione:

• Quali applicazioni, report, analisi, API o processi operativi dipendono da esso?
• Stanno ancora consumando i dati?
• Quelle squadre sanno che potrebbe essere obsoleto?
• Si avvicina una scadenza per la liquidazione, la rendicontazione, l'elaborazione di un lotto, la gestione di un cliente o altre attività aziendali?

Perché è importante

Una pipeline può essere tecnicamente ancora recuperabile, mentre i dati obsoleti a valle stanno già diventando un problema aziendale. Sei pronto ad andare avanti quando hai capito cosa è successo durante l'interruzione, quanto sei indietro e chi potrebbe essere già stato coinvolto.

Riavvio da checkpoint o risincronizzazione completa: quale percorso di ripristino è più indicato?

È in questa fase che i team spesso sentono la pressione di dover prendere una decisione rapida. A seconda della piattaforma, lo stato di ripristino salvato può essere chiamato checkpoint, segnalibro, stato di riavvio, posizione di elaborazione o in altro modo.

Ciò che conta è se esiste un percorso di ripristino supportato per lo scenario di errore effettivo. A volte la replica può riprendere dallo stato salvato e recuperare il ritardo. Altre volte è necessario un confronto o una risincronizzazione più mirati. E a volte è opportuno un ricaricamento più ampio.

A seconda dell'origine, della destinazione, della configurazione, della cronologia conservata e dello scenario di errore, i percorsi disponibili possono includere:

• Riavvia dallo stato del processo salvato
• Processo mantenuto modifiche storiche
• Confrontare la fonte e la destinazione per identificare le differenze
• Riparare o risincronizzare i dati interessati utilizzando un metodo appropriato.
• Risincronizzare parzialmente i set di dati interessati
• Eseguire una risincronizzazione più ampia o un ricaricamento completo.

Come riavviare una pipeline CDC dopo un guasto senza un carico iniziale completo

In alcuni ambienti, un carico iniziale completo potrebbe non essere necessario. La possibilità di procedere al ripristino senza di esso dipende da condizioni quali:

• Stato di riavvio/processo utilizzabile
• Cronologia delle fonti richieste ancora disponibile
• Lo stato del bersaglio
• Comportamento di origine e destinazione supportato
• Il tipo di guasto
• I meccanismi di ripristino documentati della piattaforma di replica

L'obiettivo non è evitare a tutti i costi un riavvio, bensì determinare se un percorso di riavvio o recupero supportato sia appropriato per questo specifico problema.

Controllo

• Lo stato di riavvio/processo salvato è disponibile e compreso?
• La cronologia delle origini dati necessaria per il ripristino proposto è ancora disponibile?
• L'obiettivo si trova in una condizione che favorisca la ripresa futura?
• Si è verificato qualcosa nel luogo di origine o in quello di destinazione che modifichi le ipotesi di recupero?
• Un confronto può aiutare a stabilire se solo una parte dei dati è interessata?
• Quanto tempo si prevede che ci vorrà per recuperare il tempo perduto?
• I sistemi a valle possono tollerare un periodo di stagnazione simile?
• Quali percorsi di ripristino supporta la piattaforma per questa specifica configurazione di origine/destinazione?

Perché è importante

Gli esperti descrivono l'alternativa, per quanto dolorosa, in modo molto chiaro: "riavvio completo" o addirittura "risincronizzazione da zero". La domanda a cui rispondere è: quando possiamo ripristinare il sistema senza ricominciare da capo e quando no? Si può procedere quando il team è in grado di spiegare perché il percorso di ripristino scelto è adatto a questo specifico incidente.

Cosa potrebbe mancare, essere duplicato, cancellato, obsoleto o fuori posto?

Un riavvio riuscito non dimostra di per sé che l'obiettivo sia corretto. A seconda dei dati e dell'architettura, i team dovrebbero verificare:

• Modifiche mancanti
• Modifiche duplicate o rielaborate
• Eliminazioni mancanti
• valori obsoleti
• Incoerenze parziali o relative ai record
• Problemi di ordinamento in cui la sequenza è importante
• Modifiche allo schema supportate che si sono verificate in concomitanza con l'incidente

Un problema particolarmente facile da non notare è la cancellazione. Una pipeline può apparire integra mentre un record che è stato eliminato nell'origine è ancora presente nella destinazione.

Controllo

• Quali comportamenti di transazione/modifica vengono documentati dalla piattaforma per questa origine e destinazione?
• Cosa succede durante un nuovo tentativo o una nuova elaborazione?
• Come vengono gestite le eliminazioni dei sorgenti?
• Quali scenari di modifica dello schema sono supportati?
• Quali comportamenti di ordinamento sono importanti per il tuo carico di lavoro?
• Cosa potrebbe non rilevare un normale controllo dello stato?

Perché è importante

"Ora tutto funziona di nuovo" non ti dice se qualcosa è sfuggito lungo il percorso. Sei pronto ad andare avanti quando sai quali modalità di guasto sono rilevanti nel tuo ambiente e quali prove potrebbero rivelarle.

Come dimostreremo che non è andato perduto nulla?

Non aspettare la fase di ripristino per decidere come validare il sistema. Prima di riavviare, definisci quali prove saranno necessarie prima che i team a valle vengano informati che il sistema di destinazione è nuovamente pronto per l'uso. A seconda dell'ambiente, la validazione può includere:

• Confronto sorgente-destinazione supportato
• Registri o chiavi aziendali
• conti
• Hash o checksum, ove appropriato
• Timestamp o posizioni di elaborazione
• Diagnostica della piattaforma di replica
• Esempi di transazioni critiche per l'attività aziendale
• Validazione a valle

Nessun singolo metodo dimostra tutto. La domanda importante per ogni verifica di validazione è:

Cosa dimostra tutto ciò e cosa non dimostra?

Chiedere

• Qual è il periodo di recupero previsto?
• Quali dati devono essere controllati?
• Quali controlli affrontano i rischi identificati nella domanda 5?
• Quali discrepanze richiederebbero ulteriori indagini?
• Chi deve esaminare il risultato?
• Quali prove devono essere conservate?

Perché è importante

L'errore che i team di ripristino commettono spesso è quello di presumere che "La replica è di nuovo in esecuzione" e "Il target è di nuovo affidabile" siano la stessa cosa.

Non lo sono.

Uno riguarda lo stato di salute del sistema. L'altro riguarda l'integrità dei dati. Il ripristino non è completo finché non si dispone di prove per entrambi. Si è pronti a procedere quando il team ha definito un approccio di convalida adeguato alla fonte, alla destinazione, all'incidente e al rischio aziendale.

Come facciamo a sapere se la guarigione è effettivamente completa?

Una pipeline può essere in esecuzione mentre il backlog è ancora presente. Può essere in fase di recupero mentre i dati a valle rimangono obsoleti. E può mostrare uno stato di processo sano mentre rimangono irrisolti i dubbi sui dati recuperati. Prima di chiudere l'incidente, verifica sia il processo che l'esito.

Controllo

• Il ritardo sta tornando nell'intervallo previsto?
• L'arretrato si sta effettivamente riducendo?
• La replicazione continua a progredire?
• Si verificano ancora errori o tentativi di ripetizione?
• I dati di destinazione pertinenti sono stati convalidati?
• Ai proprietari a valle interessati è stato comunicato cosa è sicuro utilizzare?
• Ci sono ancora discrepanze o eccezioni aperte?
• Lo stato dell'incidente è stato documentato?
• Abbiamo compreso a sufficienza l'accaduto per poter reagire meglio qualora si ripetesse?

Perché è importante

Chiudere un incidente troppo presto può lasciare irrisolti problemi relativi a dati, convalide o impatti a valle, nascosti dietro uno stato di processo apparentemente corretto. È possibile chiudere l'incidente quando il team può affermare che la replica è stabile, i dati rilevanti sono stati convalidati, i team a valle comprendono lo stato attuale e si può spiegare cosa è successo.

Pianificazione del recupero vs. validazione del recupero

Le sette domande presentate in questo articolo aiutano a identificare cosa potrebbe essere andato storto e da cosa dipende il recupero. Non dimostrano che l'obiettivo recuperato sia corretto. Dopo il recupero, il passo successivo consiste nel determinare se qualcuno di questi rischi si sia effettivamente verificato e se ci si possa fidare dell'obiettivo.

Risorsa correlata: La pipeline è di nuovo in funzione. Ci si può fidare dei dati?

La decisione che stai realmente prendendo

Queste sette domande non riguardano la possibilità di premere Riavvia. Riguardano la capacità di rispondere a: Da dove possiamo riprendere? Cosa è successo durante l'interruzione? Possiamo recuperare senza ricominciare da capo? E come dimostreremo che nulla è andato perso?

Questa è la differenza tra far ripartire la pipeline e ripristinarla a uno stato affidabile.

Lista di controllo per le decisioni di ripresa del CDC

Quando un problema di ripristino diventa un problema della piattaforma

Ogni piattaforma del CDC prima o poi subirà guasti, interruzioni o eventi di ripristino.

La questione non è se gli incidenti accadono. La questione è quanto impegno, incertezza e rischio comportano quando accadono.

Un singolo episodio negativo non significa automaticamente che sia necessario un diverso approccio al trattamento. Tuttavia, il dolore ricorrente durante il periodo di recupero merita un'analisi più approfondita.

Chiediti se stai riscontrando ripetutamente:

• Un arretrato crescente sulla fonte
• Riavviare completamente il sistema o risincronizzare ampiamente il sistema perché non si considera affidabile nessun altro percorso di ripristino.
• Una guarigione che dipende dal fatto che una o due persone conoscano i passi giusti
• Ore trascorse a capire se il problema risiede nella sorgente, nel livello di replica o nella destinazione.
• Validazione manuale o incoerente dalla sorgente alla destinazione
• Incertezza sul fatto che modifiche o cancellazioni siano state omesse
• Scarsa visibilità sullo stato della pipeline o del ripristino
• Impatto del sistema sorgente durante la normale elaborazione o il recupero
• Domande ricorrenti a valle sulla possibilità di fidarsi dei dati

Negli ambienti mainframe in cui Db2 per z/OS, VSAM, IMS o ADABAS sono i sistemi di registrazione, il comportamento di ripristino deve essere valutato per la specifica origine dati, e non dedotto da una generica affermazione di "supporto mainframe".

A quel punto, la domanda cambia da "Come risolviamo questo incidente?" a "Il nostro attuale approccio di replica ci fornisce la capacità di ripristino e la visibilità di cui abbiamo effettivamente bisogno?"

Dove si inserisce Rocket Data Replicate & Sync

La capacità di recupero è una delle funzionalità più importanti da valutare in qualsiasi piattaforma CDC.

Rocket Data Replicate & Sync (RDRS) gestisce la replica aziendale tra ambienti mainframe e moderne piattaforme distribuite e cloud.

Se stai valutando RDRS per un ambiente come quello descritto sopra, applica gli stessi criteri che applicheresti a qualsiasi piattaforma di replica.

Le sette domande poste in questo articolo – cosa è andato storto, da dove possiamo riprendere, cosa è successo durante l'interruzione, quale percorso di ripristino si applica, cosa potrebbe non funzionare, come lo dimostreremo e come saremo certi di aver completato il processo – sono le stesse domande a cui rispondere per qualsiasi piattaforma, incluso RDRS, prima di poter considerare affidabile un target ripristinato.

Richiedi una dimostrazione di come funziona il ripristino nella tua specifica configurazione di origine e destinazione:

• Dove l'elaborazione può riprendere dopo un'interruzione
• Che cosa succede ai cambiamenti che si accumulano durante l'intervallo?
• Cosa possono vedere gli operatori durante le fasi di recupero e riallineamento
• Quali opzioni esistono quando un normale riavvio non è sufficiente?
• Quali funzionalità di confronto o convalida tra origine e destinazione sono disponibili?
• Cosa succede all'impatto sul sistema sorgente durante il normale funzionamento e il recupero
• Quali prove può utilizzare il team prima di comunicare agli utenti a valle che i dati sono di nuovo pronti?

La possibilità di recuperare da un particolare guasto senza una risincronizzazione più ampia o un riavvio completo dipende dall'origine, dalla destinazione, dalla topologia, dalla cronologia conservata, dalla configurazione e dalla natura del guasto.

La domanda più utile non è: "La piattaforma supporta il ripristino?"

La richiesta è: "Mostrateci come funziona il ripristino negli scenari di errore che il nostro ambiente si trova effettivamente ad affrontare."

*NIST SP 800-61 Rev. 3: Raccomandazioni e considerazioni per la risposta agli incidenti

Successivamente: dimostrare la guarigione

Rimettere in moto la replica è solo una parte del lavoro. La domanda successiva è:

Come possiamo dimostrare che i dati recuperati sono completi?

Impara a definire la finestra di recupero, a determinare quali prove sono disponibili, a indagare sulle discrepanze e a stabilire quando il bersaglio è pronto per l'utilizzo successivo.