L’erreur la plus dangereuse du CDC en matière de reprise après incident survient après l’échec.

Lorsqu'un pipeline CDC tombe en panne, le réflexe est automatique: le remettre en marche. Vite.

Parallèlement, le système source peut continuer à traiter des transactions. Le nombre de tâches en attente peut continuer à augmenter. Les rapports, les applications et les processus en aval peuvent déjà fonctionner avec des données obsolètes.

Et tôt ou tard, quelqu'un pose la question: et si on redémarrait tout simplement ?

C'est généralement à ce moment-là que la récupération devient plus difficile.

Car le véritable problème n'est souvent pas la panne elle-même, mais tout ce qui s'est passé pendant que la réplication était interrompue.

• Que s'est-il passé pendant cet intervalle ?
• Pouvons-nous reprendre sans risque là où nous en étions ?
• Faut-il une resynchronisation ou un rechargement complet ?
• Comment savoir si rien n'a été oublié ?

Un redémarrage réussi ne prouve qu'une seule chose: la réplication est de nouveau en marche.

Cela ne prouve pas que la cible soit complète, à jour ou correcte.

Les pannes de CDC les plus dangereuses ne sont pas toujours celles où la réplication s'arrête. Ce sont celles où la réplication redémarre et où personne ne peut expliquer ce qui s'est passé pendant l'interruption ni garantir la fiabilité des données récupérées.

L'objectif n'est pas simplement de redémarrer au plus vite, mais d'éviter qu'un échec n'entraîne une reprise plus complexe. L'arrêt d'une tâche de réplication n'implique pas automatiquement la perte de transactions, et un redémarrage réussi ne garantit pas que la cible soit correcte.

Comment vérifier si une défaillance du pipeline CDC a entraîné une perte de données et si un redémarrage est possible en toute sécurité ?

La première étape consiste à ne pas appuyer sur Redémarrer.

Les directives actuelles du NIST en matière de réponse aux incidents distinguent la détection, la réponse, la récupération et l'amélioration continue. Cette approche plus globale permet d'établir ce qui s'est passé et de préserver suffisamment de contexte pour prendre une décision de récupération justifiée avant de modifier l'environnement.*

Il s'agit d'établir où le traitement s'est arrêté, ce qui a continué à se produire à la source, quel est l'état actuel des données pour la récupération et quelles preuves seront nécessaires par la suite.

Prises dans l'ordre, les sept questions ci-dessous vous aideront à mener à bien ce processus.

Qu'est-ce qui a exactement échoué et à quel moment ?

Le message « La réplication s’est arrêtée » n’est pas suffisamment précis pour choisir une voie de récupération.

Il faut d'abord déterminer où le problème s'est produit. La réplication a-t-elle été possible ?

• complètement arrêté ?
• Vous courez toujours, mais vous prenez du retard ?
• Vous parvenez à enregistrer les modifications, mais vous ne pouvez pas les faire avancer ?
• Impossible d'appliquer les modifications à la cible ?
• affecté par un événement du système source ?
• affecté par la cible, le réseau ou un autre élément de l'environnement ?

Ensuite, établissez la chronologie. Le moment où quelqu'un a constaté le problème ne correspond pas forcément au moment où le problème a commencé.

Vérifier

• Quand a eu lieu la dernière activité de réplication réussie confirmée ?
• La capture des sources est-elle toujours en cours ?
• Le traitement en aval progresse-t-il ?
• L'application de la cible progresse-t-elle ?
• La source a-t-elle continué à traiter les transactions ?
• La cible est-elle disponible ?
• Y a-t-il eu des changements à peu près au même moment — schéma, configuration, sécurité, infrastructure, maintenance ou charge de travail ?

Pourquoi c'est important

Un échec de capture, un échec d'application, un retard croissant et une panne de la cible sont des problèmes distincts. Ils peuvent nécessiter des équipes et des actions de récupération différentes. Vous êtes prêt à passer à l'étape suivante lorsque vous pouvez dire: « Voici où le traitement s'est arrêté, voici quand cela s'est produit et voici ce qui est affecté. » Et non pas simplement: « La réplication est défaillante quelque part. »

Où la réplication peut-elle reprendre en toute sécurité ?

Il s'agit d'une des questions les plus importantes en matière de reprise après incident. Les plateformes de réplication peuvent stocker l'état des processus ou des redémarrages, ce qui permet de déterminer où le traitement peut reprendre après une interruption.

Selon la source et la plateforme, vous pourriez rencontrer des termes tels que:

• État de redémarrage
• Point de contrôle
• Signet
• Position du bûche
• Poste de reprise
• Une autre coordonnée de récupération spécifique à la source

Ne présumez pas que ces termes ont exactement la même signification sur toutes les plateformes. L'important est de savoir si vous pouvez identifier où le traitement s'est arrêté et si cette information est suffisamment fiable pour permettre une reprise.

Marqueurs de récupération CDC mainframe: état de redémarrage, positions du journal et RBA/LRSN Db2 pour z/OS

Selon la source et la plateforme de réplication, les équipes peuvent rencontrer différents marqueurs de récupération et une terminologie de position de traitement différente. Pour les environnements Db2 pour z/OS, ces concepts peuvent inclure RBA ou LRSN.

La question essentielle est de savoir si des informations de récupération sauvegardées valides existent et si l'équipe comprend leur signification. Pour les processus de capture de données modifiées RDRS pris en charge, les informations d'état sauvegardées permettent de poursuivre le traitement à l'emplacement source approprié après redémarrage. Cet emplacement et la terminologie dépendent de la technologie source.

Vérifier

• L'état de redémarrage/processus enregistré est-il disponible ?
• Que représente exactement cet état ?
• Quand a-t-il été mis à jour pour la dernière fois ?
• Cela correspond-il à l'état de traitement attendu ?
• L'historique source pertinent est-il toujours disponible ?
• Y a-t-il eu un événement au niveau de la cible qui modifie les hypothèses de reprise ?

Pourquoi c'est important

Connaître la position de reprise du processus est très différent de reconstituer l'endroit où le processus s'est arrêté lors d'un incident. Vous êtes prêt à passer à l'étape suivante lorsque l'équipe a identifié l'état de redémarrage/processus et comprend ses implications pour la source et la cible.

Que s'est-il passé pendant l'arrêt de la réplication, et l'historique source requis est-il toujours disponible ?

Si la source est restée active, les transactions ont pu se poursuivre tandis que la cible a cessé de recevoir les modifications. L'équipe doit donc comprendre à la fois l'écart de réplication et son impact en aval.

Vérifier l'écart

• De combien de temps la cible est-elle en retard ?
• Quelle est l'ampleur du retard accumulé ?
• Le carnet de commandes est-il en croissance, stable ou en diminution ?
• Quelles sources historiques restent disponibles pour la période concernée ?
• Des insertions, des mises à jour, des suppressions ou des modifications de schéma prises en charge ont-elles eu lieu ?
• La plateforme propose-t-elle une voie de rattrapage prise en charge pour cette combinaison source et cible ?

Pour la capture des données modifiées (CDC) basée sur les journaux, vérifiez la conservation des journaux sources et l'historique archivé. Dans certains environnements CDC basés sur les journaux, les journaux sources conservés ou archivés peuvent être pertinents pour le traitement des modifications accumulées pendant une interruption. Les prérequis exacts varient selon:

• source  
• plate-forme
• configuration  
• histoire conservée
• topologie
• durée et nature de l'interruption

Ne présumez pas que l'existence de journaux archivés garantit automatiquement la disponibilité de toutes les méthodes de récupération. Vérifiez les fonctionnalités prises en charge par la plateforme pour l'environnement spécifique. Assurez-vous également que personne n'utilise déjà la cible.

• Quelles applications, quels rapports, quelles analyses, quelles API ou quels processus opérationnels en dépendent ?
• Utilisent-ils encore ces données ?
• Ces équipes savent-elles que le produit pourrait être périmé ?
• Une échéance de règlement, de reporting, de traitement par lots, de client ou autre échéance commerciale approche-t-elle ?

Pourquoi c'est important

Un pipeline peut encore être techniquement récupérable même si des données obsolètes en aval commencent déjà à poser problème à l'entreprise. Vous êtes prêt à aller de l'avant lorsque vous comprenez ce qui s'est passé pendant l'interruption, l'ampleur du retard et les personnes potentiellement impactées.

Redémarrage au point de contrôle ou resynchronisation complète: quelle méthode de récupération s’applique ?

C’est souvent à ce stade que les équipes se sentent obligées de prendre une décision rapide. Selon la plateforme, l’état de récupération enregistré peut être appelé point de contrôle, signet, état de redémarrage, position de traitement, ou autrement.

L'important est de savoir s'il existe une procédure de récupération prise en charge pour le scénario de panne réel. Parfois, la réplication peut reprendre à partir d'un état enregistré et rattraper son retard. Parfois, une comparaison plus ciblée ou une resynchronisation est nécessaire. Et parfois, un rechargement plus complet est approprié.

En fonction de la source, de la cible, de la configuration, de l'historique conservé et du scénario de défaillance, les chemins disponibles peuvent inclure:

• Redémarrer à partir de l'état de processus enregistré
• Le processus a conservé les modifications historiques
• Comparer la source et la cible pour identifier les différences
• Réparer ou resynchroniser les données affectées à l'aide d'une méthode appropriée
• Resynchroniser partiellement les ensembles de données affectés
• Effectuez une resynchronisation plus large ou un rechargement complet

Comment redémarrer un pipeline CDC après une panne sans charge initiale complète

Dans certains environnements, une charge initiale complète peut ne pas être nécessaire. La possibilité de poursuivre la récupération sans charge initiale dépend de conditions telles que:

• État de redémarrage/processus utilisable
• L'historique source requis reste disponible
• L'état de la cible
• Comportements source et cible pris en charge
• Le type de défaillance
• Les mécanismes de récupération documentés de la plateforme de réplication

L'objectif n'est pas d'éviter un rechargement à tout prix, mais de déterminer si un redémarrage pris en charge ou une procédure de rattrapage est approprié dans ce cas précis.

Vérifier

• L'état de redémarrage/processus enregistré est-il disponible et compris ?
• L'historique des sources nécessaire à la récupération proposée est-il toujours disponible ?
• L'objectif se trouve-t-il dans un état qui permette une reprise en cours ?
• Y a-t-il eu un événement au niveau de la source ou de la cible qui modifie les hypothèses de récupération ?
• Une comparaison peut-elle permettre de déterminer si seule une partie des données est affectée ?
• Combien de temps faudra-t-il pour rattraper le retard ?
• Les systèmes en aval peuvent-ils tolérer cette période d'inactivité ?
• Quels sont les chemins de récupération pris en charge par la plateforme pour cette configuration source/cible précise ?

Pourquoi c'est important

Les experts décrivent très clairement l'alternative, aussi pénible soit-elle: « redémarrage complet » ou même « resynchronisation à partir de zéro ». La question à se poser est: quand peut-on récupérer sans tout recommencer, et quand ne le peut-on pas ? Vous êtes prêt à passer à l'étape suivante lorsque l'équipe peut expliquer pourquoi la méthode de récupération choisie est adaptée à cet incident précis.

Qu'est-ce qui pourrait manquer, être dupliqué, supprimé, obsolète ou désorganisé ?

Un redémarrage réussi ne prouve pas à lui seul que la cible est correcte. En fonction des données et de l'architecture, les équipes doivent rechercher:

• Changements manquants
• Modifications dupliquées ou retraitées
• Suppressions manquantes
• Valeurs obsolètes
• Incohérences partielles ou liées entre les enregistrements
• Problèmes d'ordonnancement où la séquence importe
• Modifications de schéma prises en charge survenues autour de l'incident

Un problème particulièrement facile à négliger est la suppression. Un pipeline peut sembler fonctionner correctement alors qu'un enregistrement supprimé à la source se trouve toujours dans la cible.

Vérifier

• Quels comportements de transaction/modification la plateforme documente-t-elle pour cette source et cette cible ?
• Que se passe-t-il lors d'une nouvelle tentative ou d'un retraitement ?
• Comment les suppressions de sources sont-elles gérées ?
• Quels scénarios de modification de schéma sont pris en charge ?
• Quels comportements d'ordonnancement sont importants pour votre charge de travail ?
• Qu'est-ce qu'un contrôle d'état normal pourrait ne pas détecter ?

Pourquoi c'est important

« Tout est de nouveau en marche » ne vous dit rien sur le fait qu'un élément ait pu être négligé. Vous êtes prêt à aller de l'avant lorsque vous savez quels modes de défaillance sont importants dans votre environnement et quels indices pourraient les révéler.

Comment prouverons-nous que rien n'a été perdu ?

N’attendez pas la fin de la récupération pour décider de la méthode de validation. Avant de redémarrer, définissez les preuves nécessaires pour indiquer aux équipes en aval que la cible est de nouveau opérationnelle. Selon l’environnement, la validation peut impliquer:

• Comparaison source-cible prise en charge
• Clés d'archives ou d'entreprise
• Comptes
• Hachages ou sommes de contrôle, le cas échéant
• Horodatages ou positions de traitement
• Diagnostic de la plateforme de réplication
• Exemples de transactions critiques pour l'entreprise
• validation en aval

Aucune méthode ne prouve à elle seule tout. La question essentielle pour tout contrôle de validation est:

Qu’est-ce que cela prouve — et qu’est-ce que cela ne prouve pas ?

Demander

• Quelle est la période de récupération concernée ?
• Quelles données doivent être vérifiées ?
• Quels contrôles permettent de répondre aux risques identifiés à la question 5 ?
• Quelles anomalies nécessiteraient un examen plus approfondi ?
• Qui doit examiner le résultat ?
• Quelles preuves doivent être conservées ?

Pourquoi c'est important

L'erreur que commettent souvent les équipes de récupération est de supposer que « la réplication est de nouveau en marche » et « la cible est de nouveau digne de confiance » sont la même conclusion.

Ils ne le sont pas.

L'un concerne l'état du système, l'autre l'intégrité des données. La récupération n'est pas complète tant que vous ne disposez pas de preuves pour les deux. Vous pouvez passer à l'étape suivante lorsque l'équipe a mis en place une méthode de validation adaptée à la source, à la cible, à l'incident et au risque pour l'entreprise.

Comment savoir si la guérison est réellement complète ?

Un pipeline peut être en cours d'exécution malgré la présence de données en attente. Il peut rattraper son retard alors que les données en aval restent obsolètes. Et il peut afficher un état de processus normal alors que des questions concernant les données récupérées demeurent sans réponse. Avant de clore l'incident, vérifiez à la fois le processus et le résultat.

Vérifier

• Le délai de latence revient-il à la plage attendue ?
• Le nombre de dossiers en attente diminue-t-il réellement ?
• La réplication continue-t-elle de progresser ?
• Des erreurs ou des tentatives de réessai se produisent-elles encore ?
• Les données cibles pertinentes ont-elles été validées ?
• Les propriétaires en aval concernés ont-ils été informés des produits qu'ils peuvent utiliser en toute sécurité ?
• Existe-t-il encore des divergences ou des exceptions en suspens ?
• L'incident a-t-il été documenté ?
• Comprenons-nous suffisamment ce qui s'est passé pour mieux réagir si cela se reproduit ?

Pourquoi c'est important

Clôturer un incident trop tôt peut laisser des données, des validations ou des questions d'impact en aval non résolues, masquées par un statut de processus satisfaisant. Vous pouvez clôturer l'incident lorsque l'équipe peut affirmer que la réplication est stable, que les données pertinentes ont été validées, que les équipes en aval comprennent l'état actuel et que nous pouvons expliquer ce qui s'est passé.

Planification de la reprise vs validation de la reprise

Les sept questions de cet article permettent d'identifier les causes potentielles du problème et les éléments essentiels à la récupération. Elles ne prouvent pas que la cible récupérée soit fiable. Après la récupération, l'étape suivante consiste à déterminer si les risques encourus se sont effectivement concrétisés et si la cible est digne de confiance.

Ressource associée: Le pipeline fonctionne à nouveau. Peut-on se fier aux données ?

La décision que vous prenez réellement

Ces sept questions ne portent pas sur la possibilité de redémarrer. Elles visent à déterminer si vous pouvez répondre aux questions suivantes: Où pouvons-nous reprendre ? Que s’est-il passé pendant l’interruption ? Pouvons-nous nous rétablir sans tout recommencer ? Et comment prouverons-nous que rien n’a été perdu ?

C'est toute la différence entre remettre le pipeline en marche et revenir à un état fiable.

Liste de contrôle des décisions de rétablissement du CDC

Quand un problème de récupération devient un problème de plateforme

Chaque plateforme CDC connaîtra tôt ou tard des pannes, des interruptions ou des opérations de récupération.

La question n'est pas de savoir si des incidents se produisent. La question est de savoir quels efforts, quelle incertitude et quels risques en découlent.

Un incident malheureux ne justifie pas automatiquement le changement de plateforme CDC. En revanche, des difficultés de convalescence répétées méritent une discussion approfondie.

Demandez-vous si vous voyez régulièrement:

• Un arriéré croissant sur la source
• Rechargements complets ou resynchronisations générales car aucune autre voie de récupération n'est jugée fiable.
• Une guérison qui dépend d'une ou deux personnes connaissant les bonnes étapes
• Des heures passées à déterminer si le problème se situe à la source, au niveau de la réplication ou au niveau de la cible.
• Validation manuelle ou incohérente de la source à la cible
• Incertitude quant à savoir si des modifications ou des suppressions ont été manquées
• Mauvaise visibilité sur l'état du pipeline ou de la récupération
• Impact du système source pendant le traitement normal ou la mise à jour
• Des questions récurrentes se posent en aval quant à la fiabilité des données.

Pour les environnements mainframe où Db2 pour z/OS, VSAM, IMS ou ADABAS sont des systèmes d'enregistrement, le comportement de récupération doit être évalué pour la source spécifique et non pas supposé à partir d'une affirmation générique de « prise en charge mainframe ».

À ce stade, la question passe de « Comment résoudre cet incident ? » à « Notre approche de réplication actuelle nous offre-t-elle la capacité de récupération et la visibilité dont nous avons réellement besoin ? »

Où Rocket Data Replicate & Sync trouve sa place

La capacité de récupération est l'une des plus importantes à évaluer dans toute plateforme CDC.

Rocket Data Replicate & Sync (RDRS) gère la réplication d'entreprise entre les environnements mainframe et les plateformes distribuées et cloud modernes.

Si vous évaluez RDRS pour un environnement comme celui décrit ci-dessus, appliquez la même norme que vous appliqueriez à n'importe quelle plateforme de réplication.

Les sept questions posées dans cet article: qu’est-ce qui a échoué, où pouvons-nous reprendre, que s’est-il passé pendant l’interruption, quel chemin de récupération s’applique, qu’est-ce qui pourrait ne pas fonctionner, comment allons-nous le prouver et comment savons-nous que nous avons terminé ? Ce sont les mêmes questions auxquelles il faut répondre pour toute plateforme, y compris RDRS, avant de faire confiance à une cible récupérée.

Demandez une démonstration du fonctionnement de la récupération dans votre configuration source et cible spécifique:

• Le traitement peut reprendre après une interruption.
• Qu’advient-il des changements qui s’accumulent pendant l’intervalle ?
• Ce que les opérateurs peuvent voir pendant la reprise et le rattrapage.
• Quelles sont les options disponibles lorsqu'un redémarrage normal ne suffit pas ?
• Quelles sont les capacités de comparaison ou de validation source-cible disponibles ?
• Que se passe-t-il au niveau de l'impact sur le système source pendant le fonctionnement normal et la phase de rattrapage ?
• Quelles preuves l'équipe peut-elle utiliser avant d'annoncer aux utilisateurs finaux que les données sont à nouveau prêtes ?

La possibilité de récupérer une panne particulière sans resynchronisation plus large ou rechargement complet dépend de la source, de la cible, de la topologie, de l'historique conservé, de la configuration et de la nature de la panne.

La question la plus utile n'est pas: « La plateforme prend-elle en charge la récupération ? »

Il s'agit de: « Montrez-nous comment fonctionne la reprise dans les scénarios de défaillance auxquels notre environnement est réellement confronté. »

*NIST SP 800-61 Rév. 3: Recommandations et considérations relatives à la réponse aux incidents

Prochaine étape: prouver la récupération

Relancer la réplication n'est qu'une partie du travail. La question suivante est:

Comment prouver que les données récupérées sont complètes ?

Apprenez à définir la fenêtre de récupération, à déterminer les preuves disponibles, à enquêter sur les incohérences et à établir quand la cible est prête pour une utilisation ultérieure.