ApsaraDB for MongoDB s'appuie sur une architecture de haute disponibilité (HA). Lorsque le système HA détecte qu'un nœud est indisponible, il déclenche automatiquement un basculement primaire/secondaire et vous en informe par SMS ou via un message interne.
Exemple de notification
[Alibaba Cloud] Cher \\\\ : Votre instance ApsaraDB for MongoDB dds-bp\\\\ (nom : \\\\) rencontre une erreur. Un basculement a été déclenché afin de garantir la stabilité de votre instance. Nous vous recommandons de vérifier que votre application est toujours connectée à l'instance et de configurer celle-ci pour qu'elle se reconnecte automatiquement.
Fonctionnement
Une instance de type replica set comporte trois nœuds par défaut. Chaque shard d'une instance de type sharded cluster dispose également de trois nœuds. Les nœuds primaires et secondaires gèrent les connexions des applications, tandis que les nœuds cachés servent de cibles de secours pour le basculement. Pour plus d'informations, consultez les rubriques Instances de type Replica Set ou Instances de type Sharded Cluster.
Raisons du déclenchement d'un basculement
Deux situations peuvent déclencher un basculement primaire/secondaire :
Nœud indisponible : Le système de surveillance de l'état des nœuds détecte qu'un nœud ne répond pas et promeut un nœud caché au rang de primaire.
Hôte hors ligne : Une anomalie survient sur l'hôte exécutant le nœud primaire. Le système HA bascule vers un hôte sain pour éviter une interruption prolongée du service.
Dépannage de la cause d'un basculement HA
Une utilisation excessive des ressources, telle qu'une forte consommation de CPU ou de mémoire, peut rendre un nœud indisponible et provoquer un basculement HA. Pour évaluer si la pression sur les ressources a contribué au basculement, examinez les métriques de performance durant la période concernée.
Dans la console ApsaraDB for MongoDB, ouvrez l'instance cible. Dans le volet de navigation de gauche, choisissez DAS Performance Trend.
-
Sélectionnez la plage horaire correspondant au moment du basculement. Passez en revue les métriques suivantes et comparez leurs variations avec l'heure du basculement :
CPU utilization et memory utilization : Une utilisation élevée soutenue ou un pic soudain peuvent indiquer que la pression sur les ressources a affecté la réactivité du nœud.
Affected Documents et Scanned Indexes and Documents : Des augmentations anormales peuvent révéler des requêtes inefficaces qui consomment les ressources de l'instance.
Repl Opcounters et Oplog Retention Period : Des valeurs anormales vous aident à évaluer l'activité et l'état de la réplication.
Si l'utilisation du CPU ou de la mémoire est anormale, choisissez Monitoring Information dans le volet de navigation de gauche. Sélectionnez le nœud concerné ainsi que la plage horaire correspondante pour consulter son historique.
Mettez en corrélation la période d'anomalie des métriques avec l'heure du basculement. Un pic d'utilisation du CPU suivi d'une interruption des données de surveillance constitue un indice diagnostique suggérant que la pression sur les ressources a pu contribuer au basculement de l'instance ; analysez cet élément conjointement avec les autres métriques avant d'identifier la cause racine.
DAS Performance Trend est le nouveau nom de l'ancienne fonctionnalité de diagnostic de performance Dukang-Telescope.
En cas d'utilisation anormale du CPU, poursuivez l'investigation en consultant la rubrique Dépannage d'une utilisation élevée du CPU sur une instance ApsaraDB for MongoDB.
Impact d'un basculement
Le basculement entraîne une interruption transitoire de la connexion inférieure à 30 secondes.
Si votre application se connecte directement à l'endpoint du nœud primaire, les opérations de lecture/écriture sont affectées pendant la fenêtre de basculement.
Actions recommandées
Pour résoudre les problèmes de reconnexion immédiate : Configurez votre application pour qu'elle se reconnecte automatiquement après une déconnexion. La plupart des pilotes MongoDB prennent en charge la reconnexion automatique par défaut.
Pour les environnements de production : Utilisez une URI de chaîne de connexion pour vous connecter à l'instance, afin que votre application bascule automatiquement vers un nœud sain, maintenant ainsi la disponibilité des opérations de lecture/écriture même lors du changement de nœud primaire. Pour plus d'informations, consultez les rubriques Connexion à une instance de type Replica Set ou Connexion à une instance de type Sharded Cluster.