Tous les produits
Search
Centre de documentation

ApsaraMQ for Kafka:Single-zone disaster recovery for ApsaraMQ for Kafka

Dernière mise à jour :Aug 11, 2026

Une instance ApsaraMQ for Kafka déployée dans une seule zone risque de devenir indisponible et de perdre des données en cas de défaillance au niveau de la zone. Pour vous prémunir contre ce scénario, utilisez l'intégration de l'écosystème de connecteurs d'ApsaraMQ for Kafka afin de sauvegarder les messages vers une instance secondaire située dans une autre région. En cas de panne, basculez le trafic vers l'instance secondaire et rétablissez le service en réinitialisant les offsets.

Fonctionnement

Cette architecture de reprise après sinistre s'appuie sur deux instances ApsaraMQ for Kafka déployées dans des régions distinctes :

  1. Une instance principale reçoit et gère l'ensemble du trafic de production.

  2. Un connecteur sink sauvegarde continuellement les messages de l'instance principale vers une instance secondaire située dans une autre région.

  3. Lorsqu'une défaillance au niveau de la zone perturbe l'instance principale, les clients basculent leurs endpoints vers l'instance secondaire.

  4. Les consommateurs réinitialisent leurs offsets sur l'instance secondaire et reprennent le traitement.

Architecture diagram

Prérequis

Avant de commencer, assurez-vous de disposer des éléments suivants :

  • Deux instances ApsaraMQ for Kafka situées dans des régions différentes

  • Une connectivité réseau entre les deux régions via Cloud Enterprise Network (CEN)

  • (Recommandé) Un nom de domaine personnalisé pour le basculement du trafic basé sur un enregistrement CNAME

Points d'attention essentiels

  • Déployez les instances principale et secondaire dans des régions différentes afin de vous protéger contre les pannes affectant une région entière.

  • Après un basculement, les consommateurs réinitialisent les offsets sur l'instance secondaire et peuvent retraiter certains messages. Implémentez l'idempotence des messages dans vos consommateurs pour gérer les consommations en double.

  • Utilisez un enregistrement CNAME pour mapper un nom de domaine personnalisé à l'endpoint de l'instance principale. En cas de panne, mettez à jour la cible de l'enregistrement CNAME pour qu'elle pointe vers l'instance secondaire. Cette opération permet de basculer le trafic sans redémarrer vos applications.

Configuration de la reprise après sinistre

Étape 1 : Créer un connecteur sink

Créez un connecteur sink ApsaraMQ for Kafka pour répliquer continuellement les messages de l'instance principale vers l'instance secondaire.

Pour obtenir des instructions, consultez la rubrique Création de connecteurs sink ApsaraMQ for Kafka.

Étape 2 : (Facultatif) Ajouter un enregistrement CNAME

Pour permettre un basculement rapide du trafic sans redémarrage des applications, ajoutez un enregistrement CNAME qui mappe votre nom de domaine personnalisé au nom de domaine de l'instance principale.

Pour obtenir des instructions, consultez la rubrique Enregistrement CNAME.

Étape 3 : Configurer l'endpoint du client

Choisissez l'une des approches suivantes selon que vous avez ou non configuré un enregistrement CNAME :

Mode CNAME (recommandé)

  1. Configurez votre client pour qu'il pointe vers le nom de domaine personnalisé associé à l'enregistrement CNAME.

  2. En cas de panne, mettez à jour la cible de l'enregistrement CNAME avec le nom de domaine de l'instance secondaire. Le trafic bascule automatiquement sans nécessiter le redémarrage de vos applications.

Mode standard

  1. Configurez votre client pour qu'il pointe directement vers l'endpoint de l'instance principale.

  2. En cas de panne, mettez à jour la configuration du client avec l'endpoint de l'instance secondaire, puis redémarrez l'application.

Important

Pour accéder aux instances ApsaraMQ for Kafka situées dans différentes régions, connectez les Virtual Private Clouds (VPC) de ces régions via Cloud Enterprise Network (CEN). Pour plus de détails, consultez la rubrique Connexion de VPC dans différentes régions.