Minimiser les temps d'arrêt dans MemoryDB avec Multi-AZ

Dans un certain nombre de cas, MemoryDB peut avoir besoin de remplacer un nœud principal ; il s'agit notamment de certains types de maintenance planifiée et de l'éventualité peu probable d'une défaillance d'un nœud principal ou d'une zone de disponibilité.

La réponse à une défaillance d'un nœud dépend du nœud défaillant. Cependant, dans tous les cas, MemoryDB garantit qu'aucune donnée n'est perdue lors du remplacement ou du basculement des nœuds. Par exemple, si une réplique échoue, le nœud défaillant est remplacé et les données sont synchronisées à partir du journal des transactions. En cas de défaillance du nœud principal, un basculement est déclenché vers une réplique cohérente, ce qui garantit qu'aucune donnée n'est perdue pendant le basculement. Les écritures sont désormais effectuées depuis le nouveau nœud principal. L'ancien nœud principal est ensuite remplacé et synchronisé à partir du journal des transactions.

Si un nœud principal tombe en panne sur une partition à nœud unique (pas de répliques), MemoryDB cesse d'accepter les écritures jusqu'à ce que le nœud principal soit remplacé et synchronisé à partir du journal des transactions.

Le remplacement du nœud peut entraîner un certain temps d'arrêt pour le cluster, mais si Multi-AZ est actif, le temps d'arrêt est minimisé. Le rôle du nœud principal basculera automatiquement vers l'une des répliques. Il n'est pas nécessaire de créer et de provisionner un nouveau nœud principal, car MemoryDB gérera cela de manière transparente. Ce basculement et la promotion d'un réplica vous permettent de recommencer à écrire dans le nouveau nœud principal dès que la promotion est terminée.

Dans le cas de remplacements de nœuds planifiés initiés en raison de mises à jour de maintenance ou de mises à jour de service, sachez que les remplacements de nœuds prévus sont terminés pendant que le cluster traite les demandes d'écriture entrantes.

Le multi-AZ sur vos clusters MemoryDB améliore votre tolérance aux pannes. Cela est particulièrement vrai dans les cas où les nœuds principaux de votre cluster deviennent inaccessibles ou tombent en panne pour une raison quelconque. Le mode multi-AZ sur les clusters MemoryDB nécessite que chaque partition possède plusieurs nœuds et est automatiquement activé.

Scénarios de défaillance avec réponses multi-AZ

Si Multi-AZ est actif, un nœud principal défaillant bascule vers une réplique disponible. La réplique est automatiquement synchronisée avec le journal des transactions et devient principale, ce qui est beaucoup plus rapide que la création et le reprovisionnement d'un nouveau nœud principal. Ce processus dure généralement quelques secondes pendant lesquelles vous ne pouvez pas écrire sur le cluster.

Lorsque Multi-AZ est actif, MemoryDB surveille en permanence l'état du nœud principal. En cas de défaillance du nœud principal, l'une des actions suivantes est effectuée selon le type de la défaillance.

Scénarios d'échec lorsque seul le nœud primaire échoue

Si seul le nœud principal tombe en panne, une réplique deviendra automatiquement le nœud principal. Une réplique de remplacement est ensuite créée et mise en service dans la même zone de disponibilité que la réplique principale défaillante.

Lorsque seul le nœud principal tombe en panne, MemoryDB Multi-AZ effectue les opérations suivantes :

Pour plus d'informations sur la recherche des points de terminaison d'un cluster, consultez les rubriques suivantes :

Scénarios de défaillance en cas de défaillance du nœud principal et de certaines répliques

Si le principal et au moins un réplica échouent, un up-to-date réplica est promu en cluster principal. De nouvelles répliques sont également créées et approvisionnées dans les mêmes zones de disponibilité que les nœuds défaillants.

Lorsque le nœud principal et certaines répliques échouent, MemoryDB Multi-AZ effectue les opérations suivantes :

Scénarios d'échec lorsque l'ensemble du cluster tombe en panne

En cas de défaillance générale, tous les nœuds sont recréés et mis en service dans les mêmes zones de disponibilité que les nœuds initiaux.

Il n'y a aucune perte de données dans ce scénario car les données étaient conservées dans le journal des transactions.

Lorsque l'ensemble du cluster échoue, MemoryDB Multi-AZ effectue les opérations suivantes :

Pour plus d'informations sur la recherche des points de terminaison d'un cluster, consultez les rubriques suivantes :

Test du basculement automatique

Vous pouvez tester le basculement automatique à l'aide de la console MemoryDB, du AWS CLI, et du MemoryDB. API

Lors du test, tenez compte des points suivants :

Test du basculement automatique à l'aide du AWS Management Console

Utilisez la procédure suivante pour tester le basculement automatique avec la console.

Test du basculement automatique à l'aide du AWS CLI

Vous pouvez tester le basculement automatique sur n'importe quel cluster compatible Multi-AZ à l'aide de l' AWS CLI opération failover-shard.

L'exemple suivant utilise l'appel AWS CLI to failover-shard sur le shard 0001 du cluster MemoryDB. my-cluster

Pour Linux, macOS ou Unix :

aws memorydb failover-shard \
   --cluster-name my-cluster \
   --shard-name 0001

Pour Windows :

aws memorydb failover-shard ^
   --cluster-name my-cluster ^
   --shard-name 0001

Pour suivre la progression de votre basculement, utilisez l' AWS CLI describe-eventsopération.

Il renverra la JSON réponse suivante :

{
    "Events": [
        {
            "SourceName": "my-cluster",
            "SourceType": "cluster",
            "Message": "Failover to replica node my-cluster-0001-002 completed",
            "Date": "2021-08-22T12:39:37.568000-07:00"
        },
        {
            "SourceName": "my-cluster",
            "SourceType": "cluster",
            "Message": "Starting failover for shard 0001",
            "Date": "2021-08-22T12:39:10.173000-07:00"
        }
    ]
}
 

Pour plus d’informations, consultez les ressources suivantes :

Test du basculement automatique à l'aide de MemoryDB API

L'exemple suivant fait FailoverShard appel à la partition 0003 du clustermemorydb00.

https://memory-db.us-east-1.amazonaws.com/
    ?Action=FailoverShard
    &ShardName=0003
    &ClusterName=memorydb00
    &Version=2021-01-01
    &SignatureVersion=4
    &SignatureMethod=HmacSHA256
    &Timestamp=20210801T192317Z
    &X-Amz-Credential=<credential>

Pour suivre la progression de votre basculement, utilisez l'opération MemoryDB DescribeEventsAPI.

Pour plus d’informations, consultez les ressources suivantes :