Le cluster source devient indisponible

Examinons ce qui se passe si un sinistre survient dans la région du cluster source.

Il incombe au propriétaire de l'instance Event Streams de déterminer si l'impact de l'événement est tel qu'il faille déclarer une catastrophe. Le propriétaire de l'instance de service doit coordonner la reprise en ligne des applications, y compris leur reconfiguration, leur redéploiement et leur redémarrage, si nécessaire.

Reprise en ligne des producteurs

Pour effectuer une reprise en ligne, procédez comme suit:

1. Arrêtez les producteurs qui pointaient vers le cluster A.
2. Si le cluster A et le lien entre A et le cluster B sont toujours opérationnels, assurez-vous que le plus grand nombre possible de données est mis en miroir en vérifiant que le décalage de ces sujets sur le cluster B est nul.
3. Redémarrer les producteurs pour qu'ils pointent vers les points d'extrémité du cluster B.
4. Désactivez toute mise en miroir qui est toujours activée sur les rubriques du cluster A au cluster B. Pour ce faire, utilisez les commandes utilisateur.

Le producteur a été basculé sur le cluster B et envoie des messages à une nouvelle rubrique locale portant le même nom que celle d'origine.

Reprise en ligne des consommateurs

Pour effectuer une reprise en ligne, procédez comme suit:

1. Si le cluster A et le lien de A vers le cluster B sont toujours opérationnels, autorisez les consommateurs à lire toutes les données de message dans les rubriques du cluster A et à valider leurs décalages à la fin de la rubrique.
2. Arrêter les consommateurs qui pointaient vers le groupe A.
3. Redémarrez les consommateurs pour qu'ils pointent vers les points d'extrémité du cluster B.

Le consommateur est maintenant en mesure de continuer à consommer les messages existants du sujet accounting.invoices.A du cluster B pendant que de nouveaux messages arrivent de accounting.invoices

Si l'application exige un ordre strict, les sujets distants doivent d'abord être entièrement consommés avant de commencer à consommer les sujets locaux. De cette façon, les messages sont traités dans l'ordre selon lequel ils ont été produits.

Réinitialisation d'un environnement de mise en miroir

Le propriétaire de l'instance de service Event Streams est chargé de déterminer ce qui se passe lorsque le cluster A est récupéré.

Dans le cas où le cluster A n'est pas récupérable, le propriétaire de l'instance de service Event Streams est responsable de l'activation de la mise en miroir entre le cluster B et une instance nouvellement mise à disposition. Pour activer la mise en miroir sur une nouvelle instance, procédez comme suit:

• Reprise des producteurs et des consommateurs de A à B, comme décrit précédemment.
• Désactivez la mise en miroir en cours du cluster A vers le cluster B. Pour plus d'informations, voir Désactivation de la mise en miroir.
• Une fois la mise en miroir désactivée, activez la mise en miroir entre le cluster B (maintenant la source) et le nouveau cluster mis à disposition (la cible). Pour plus d'informations, voir Activation de la mise en miroir.

Par ailleurs, si le cluster A s'est rétabli, l'utilisateur renvoie généralement les opérations au cluster A. Procédez comme suit pour renvoyer les opérations principales au cluster A.

Avant le retour, la mise en miroir doit être activée dans la direction opposée :

• Vérifiez que le cluster A est pleinement opérationnel.
• Désactivez la mise en miroir en cours du cluster A vers le cluster B. Pour plus d'informations, voir Désactivation de la mise en miroir.
• Une fois la mise en miroir désactivée, activez la mise en miroir entre le cluster B (maintenant la source) et le cluster A (maintenant la cible). Pour plus d'informations, voir Activation de la mise en miroir.
• Le cluster source A devient maintenant le cluster cible.
• Le cluster cible B devient le nouveau cluster source.
• Activez toutes les rubriques devant être mises en miroir du cluster B vers le cluster A. Pour ce faire, utilisez les contrôles utilisateur.

Ensuite, assurez-vous que les données sont répliquées dans le cluster A en examinant les rubriques du cluster B figurant sur le cluster A. Ces thèmes portent le suffixe du nouveau cluster source, B.

Ne renvoyez pas en miroir le sujet cible d'origine sur le cluster B, car cela provoquerait un effet cyclique indésirable. Comme le montre le diagramme, nous mettons en miroir accounting.invoices du cluster B vers le cluster A, et non accounting.invoices.A

Failback

La décision d'effectuer une reprise par restauration revient une fois de plus au propriétaire de l'instance Event Streams. Le propriétaire de l'instance de service doit coordonner la reprise par restauration des applications, y compris leur reconfiguration, leur redéploiement et leur redémarrage, si nécessaire.

Contrairement au cas de basculement, il n'y a pas eu de sinistre sur le cluster B. Par conséquent, la reprise par restauration est une opération contrôlée et peut être réalisée avec une perte de données minimale ou un retraitement des données.

Enfin, rétablissez la configuration initiale de la mise en miroir, ce qui signifie que le cluster A est à nouveau la source et que le cluster B redevient la cible.

• Vérifiez que le cluster A et le cluster B sont pleinement opérationnels.
• Désactivez la mise en miroir en cours du cluster B vers le cluster A. Pour plus d'informations, voir Désactivation de la mise en miroir.
• Une fois la mise en miroir désactivée, activez la mise en miroir entre le cluster A (maintenant la source) et le cluster B (maintenant la cible). Pour plus d'informations, voir Activation de la mise en miroir.