Tair (Redis® OSS-Compatible):Présentation de la haute disponibilité

Causes

• Défaillances des hôtes d'instance

  Lorsqu'Alibaba Cloud détecte une défaillance sur l'hôte sous-jacent d'une instance, telle qu'un arrêt anormal des processus ou des anomalies mémoire dues à une charge élevée, le système déclenche immédiatement un basculement maître-réplica. Cette réaction rapide permet de rétablir l'instance dans les meilleurs délais et de minimiser la durée de toute perturbation causée par la panne.

  Vous êtes informé de ces événements par par des messages internes ou des e-mails selon le format suivant :

  [Alibaba Cloud] Cher**** : Une anomalie a été détectée sur votre instance Tair r-bp1zxszhcgatnx** (nom : **). Un basculement est déclenché pour assurer le bon fonctionnement de l'instance. Nous vous recommandons de vérifier si votre application est toujours connectée à votre instance et de configurer celle-ci pour qu'elle se reconnecte automatiquement.

• Risques latents sur les hôtes d'instance

  Si Alibaba Cloud identifie des risques sur l'hôte sous-jacent d'une instance, tels que des fluctuations réseau ou des anomalies de disque, cela indique un risque potentiel d'impact futur sur le fonctionnement normal de l'instance. Dans ce cas, le système lance automatiquement des tâches de maintenance proactive pour traiter ces risques et déclenche un basculement maître-réplica durant la fenêtre de maintenance afin de remplacer les nœuds hôtes à risque.

  Toutefois, pour les événements nécessitant une correction urgente des risques, le système prend des mesures rapides pour résoudre les problèmes et initier un basculement maître-réplica. Par exemple, si un bogue critique est identifié dans la communauté Redis, l'instance concernée fait l'objet d'une mise à jour mineure proactive. Vous pouvez consulter l'historique de ces actions. Pour plus d'informations, reportez-vous à Interroger l'historique des événements. Vous pouvez également gérer les événements de basculement maître-réplica en attente. Pour plus d'informations, consultez Afficher et gérer les événements planifiés.

Impacts

L'instance termine automatiquement l'intégralité du processus de basculement. Une fois le basculement achevé, l'instance fonctionne comme prévu.

Cependant, pendant le processus de basculement, les situations suivantes peuvent survenir :

• Les nœuds de données concernés par le basculement sont déconnectés pendant quelques secondes et peuvent rester en lecture seule pendant jusqu'à 30 secondes.

• Une fois que l'instance passe à l'état Switching, vous ne pouvez pas la gérer. Par exemple, vous ne pouvez pas modifier les configurations de l'instance ni migrer l'instance vers une autre zone. Une fois le basculement maître-réplica terminé, l'état de l'instance passe à Running.

Actions recommandées

• Assurez-vous que votre application est configurée pour se reconnecter automatiquement à l'instance ou pour gérer les exceptions. Sinon, l'un des messages d'erreur suivants peut être renvoyé lors d'un basculement : READONLY You can't write against a read only instance ou DISABLE You can't write or read against a disable instance.

• Lorsqu'un basculement maître-réplica est déclenché pour une instance, celle-ci termine automatiquement l'ensemble du processus en promouvant le nœud réplica pour qu'il devienne le nouveau nœud maître et en créant un autre nœud réplica pour la synchronisation des données entre les nœuds maître et réplica. Aucune opération de votre part n'est nécessaire durant ce processus.

  Remarque

  Après la fin du basculement maître-réplica pour une instance multizone, le nœud maître réside dans la zone secondaire et le nœud réplica dans la zone primaire. Cela peut entraîner un accès interzones entre l'instance et d'autres services. Pour résoudre ce problème, vous pouvez changer manuellement de zones sur la page Service availability de la console.

Rubriques connexes

Tair (Redis OSS-compatible) prend également en charge les basculements maître-réplica manuels. Cette fonctionnalité peut être utilisée pour des exercices de reprise après sinistre ou pour se connecter au nœud le plus proche dans les déploiements multizones de disponibilité. Pour plus d'informations, consultez Effectuer manuellement un basculement maître-réplica.

FAQ

• Quel est le principe du basculement maître-réplica déclenché par une défaillance d'instance ?

  Le système de haute disponibilité s'appuie sur son mécanisme de détection de vivacité pour identifier les pannes. Le tableau ci-dessous décrit ce mécanisme.

  Événement majeur	Description
  Vérification de l'état	Le système de haute disponibilité vérifie si les nœuds maître et réplica sont sains.
  Panne du nœud maître	Lorsqu'un nœud maître est jugé indisponible, un nœud réplica agit en tant que nœud maître. En même temps, l'adresse IP virtuelle (VIP) du nœud réplica est utilisée, mais l'endpoint de l'instance reste inchangé. Un autre nœud réplica est créé pour garantir la synchronisation des données.
  Panne du nœud réplica	Lorsqu'un nœud réplica est jugé indisponible, un autre nœud réplica est automatiquement créé pour garantir la synchronisation des données et maintenir la persistance des données de l'architecture maître-réplica.

  Remarque

  Des données spécifiques récemment écrites sur un nœud maître peuvent être perdues car la synchronisation entre les nœuds maître et réplica est asynchrone.

• Q : Comment puis-je consulter mon historique de basculement maître-réplica (HA) ?

  R :

  1. Accédez au Centre d'événements dans la console et sélectionnez une région en haut de la page.

  2. Cliquez sur Abnormal Events.

  3. Sélectionnez la plage horaire souhaitée.

  4. Définissez Archive Status sur All pour afficher les enregistrements de instance failover et leurs causes, telles que Master unavailable.

• Q : Si un basculement maître-réplica se produit sur une instance à répartition lecture/écriture, les réplicas en lecture sont-ils affectés ?

  R : Pendant le basculement, le nombre de réplicas en lecture disponibles diminue temporairement d'une unité et revient à la normale une fois l'opération terminée.

• Q : Pour une instance à architecture cluster, le basculement d'un shard de données affecte-t-il l'ensemble de l'instance ?

  R : Non. Seul le shard de données concerné est impacté.