Activation du multi-AZ Scénarios de défaillance avec réponses multi-AZ Test du basculement automatique Notes sur Multi-AZ

Réduction des temps d'arrêt dans ElastiCache for Redis avec Multi-AZ

Il existe plusieurs instances dans lesquelles ElastiCache for Redis peut avoir besoin de remplacer un nœud primaire, notamment certains types de maintenance planifiée et l'événement peu probable d'un échec du nœud primaire ou de la zone de disponibilité.

Ce remplacement entraîne un certain temps d'arrêt pour le cluster, mais si Multi-AZ est activé, le temps d'arrêt est réduit. Le rôle du nœud primaire bascule automatiquement sur l'un des réplicas en lecture. Il n'est pas nécessaire de créer et allouer un nouveau nœud primaire, car ElastiCache gère 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.

ElastiCache propage également le nom DNS du réplica promu. De cette façon, si votre application écrit dans le point de terminaison principal, aucun changement du point de terminaison ne sera nécessaire dans le cadre de votre application. Si vous lisez à partir de points de terminaison individuels, veillez à modifier le point de terminaison de lecture du réplica promu en principal en point de terminaison du nouveau réplica.

Dans le cas de remplacements de nœuds planifiés, initiés en raison de mises à jour de maintenance ou de mises à jour en libre service, soyez conscient des points suivants :

Pour ElastiCache pour Redis Cluster, les remplacements de nœuds planifiés sont maintenant terminés pendant que le cluster répond aux demandes d'écriture entrantes.
Pour les clusters dont le mode de cluster Redis est désactivé avec le déploiement multi-AZ activé et s'exécutant sur un moteur de version 5.0.6 ou ultérieure, les remplacements de nœuds planifiés sont exécutés pendant que le cluster répond aux demandes d'écriture entrantes.
Pour les clusters désactivés en mode de cluster Redis avec le déploiement multi-AZ activé qui s'exécutent sur un moteur 4.0.10 ou antérieur, vous pouvez remarquer une brève interruption d'écriture associée aux mises à jour DNS. Cette interruption peut prendre jusqu'à quelques secondes. Ce processus est nettement plus rapide que celui qui consiste à recréer et mettre en service un nouveau nœud primaire, processus appliqué si vous n'activez pas le mode Multi-AZ.

Vous pouvez activer Multi-AZ à l'aide de la console de gestion , de la AWS CLI ou de l'API ElastiCache.

L'activation du mode Multi-AZ ElastiCache sur votre cluster Redis (dans l'API et la CLI, groupe de réplication) améliore votre tolérance aux pannes. C'est surtout le cas lorsque le cluster principal en lecture/écriture de votre cluster devient inaccessible ou fait l'objet d'une défaillance pour quelque raison que ce soit. Multi-AZ n'est pris en charge que sur les clusters Redis qui ont plus d'un nœud dans chaque partition.

Rubriques

Activation du multi-AZ
Scénarios de défaillance avec réponses multi-AZ
Test du basculement automatique
Restrictions sur Redis Multi-AZ

Activation du multi-AZ

Vous pouvez activer l'option Multi-AZ lorsque vous créez ou modifiez un cluster (API ou CLI, groupe de réplication) à l'aide de la console ElastiCache, de la AWS CLI ou de l'API ElastiCache.

Vous pouvez activer Multi-AZ uniquement sur les clusters Redis (mode cluster désactivé) qui disposent d'au moins un réplica en lecture disponible. Les clusters sans réplica en lecture n'offrent pas une haute disponibilité ni la tolérance aux pannes. Pour plus d'informations sur la création d'un cluster avec réplication, consultez Création d'un groupe de réplication Redis. Pour plus d'informations sur l'ajout d'un réplica à un cluster avec réplication, consultez Ajout d'un réplica en lecture, pour les groupes de réplication Redis (mode cluster désactivé).

Activation du multi-AZ (console)

Vous pouvez activer l'option Multi-AZ via la console ElastiCache lorsque vous créez un cluster Redis ou modifiez un cluster Redis existant avec la réplication.

Multi-AZ est activé par défaut sur les clusters Redis (mode cluster activé).

Important

ElastiCache active automatiquement l'option Multi-AZ uniquement si le cluster contient au moins un réplica dans une zone de disponibilité différente de celle du serveur principal dans toutes les partitions.

Activation de Multi-AZ lors de la création d'un cluster à l'aide de la console ElastiCache

Pour plus d'informations sur ce processus, consultez Création d'un cluster Redis (mode cluster activé) (console). Assurez-vous d'avoir un ou plusieurs réplicas et activez Multi-AZ.

Activation du multi-AZ sur un cluster existant (console)

Pour plus d'informations sur ce processus, consultez Modification d'un cluster À l'aide du AWS Management Console.

Activation de Multi-AZ (AWS CLI)

L'exemple de code suivant utilise la AWS CLI pour activer Multi-AZ pour le groupe de réplication redis12.

Important

Le groupe de réplication redis12 doit déjà exister et avoir au moins un réplica en lecture disponible.

Pour Linux, macOS ou Unix :


aws elasticache modify-replication-group \
    --replication-group-id redis12 \
    --automatic-failover-enabled \
    --multi-az-enabled \
    --apply-immediately

Pour Windows :


aws elasticache modify-replication-group ^
    --replication-group-id redis12 ^
    --automatic-failover-enabled ^
    --multi-az-enabled ^
    --apply-immediately

Le résultat JSON de cette commande devrait ressembler à cet exemple.


{
    "ReplicationGroup": {
        "Status": "modifying", 
        "Description": "One shard, two nodes", 
        "NodeGroups": [
            {
                "Status": "modifying", 
                "NodeGroupMembers": [
                    {
                        "CurrentRole": "primary", 
                        "PreferredAvailabilityZone": "us-west-2b", 
                        "CacheNodeId": "0001", 
                        "ReadEndpoint": {
                            "Port": 6379, 
                            "Address": "redis12-001.v5r9dc.0001.usw2.cache.amazonaws.com"
                        }, 
                        "CacheClusterId": "redis12-001"
                    }, 
                    {
                        "CurrentRole": "replica", 
                        "PreferredAvailabilityZone": "us-west-2a", 
                        "CacheNodeId": "0001", 
                        "ReadEndpoint": {
                            "Port": 6379, 
                            "Address": "redis12-002.v5r9dc.0001.usw2.cache.amazonaws.com"
                        }, 
                        "CacheClusterId": "redis12-002"
                    }
                ], 
                "NodeGroupId": "0001", 
                "PrimaryEndpoint": {
                    "Port": 6379, 
                    "Address": "redis12.v5r9dc.ng.0001.usw2.cache.amazonaws.com"
                }
            }
        ], 
        "ReplicationGroupId": "redis12", 
        "SnapshotRetentionLimit": 1, 
        "AutomaticFailover": "enabling", 
        "MultiAZ": "enabled", 
        "SnapshotWindow": "07:00-08:00", 
        "SnapshottingClusterId": "redis12-002", 
        "MemberClusters": [
            "redis12-001", 
            "redis12-002"
        ], 
        "PendingModifiedValues": {}
    }
}

Pour plus d'informations, consultez ces rubriques dans la Référence des commandes de l'AWS CLI :

create-cache-cluster
create-replication-group
modify-replication-group dans la Référence des commandes de l'AWS CLI.

Activation du multi-AZ (API ElastiCache)

L'exemple de code suivant utilise l'API ElastiCache pour activer Multi-AZ pour le groupe de réplication redis12.

Note

Pour que vous puissiez utiliser cet exemple, le groupe de réplication redis12 doit déjà exister et avoir au moins un réplica en lecture disponible.


https://elasticache.us-west-2.amazonaws.com/
    ?Action=ModifyReplicationGroup
    &ApplyImmediately=true
    &AutoFailover=true
    &MultiAZEnabled=true
    &ReplicationGroupId=redis12
    &Version=2015-02-02
    &SignatureVersion=4
    &SignatureMethod=HmacSHA256
    &Timestamp=20140401T192317Z
    &X-Amz-Credential=<credential>

Pour plus d'informations, veuillez consulter ces rubriques dans la référence de l'API ElastiCache :

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

Avant l'introduction du mode Multi-AZ, ElastiCache détectait et remplaçait les nœuds défaillants d'un cluster en recréant et en réallouant le nœud défaillant. Si vous activez Multi-AZ, un cluster principal défaillant bascule vers le réplica ayant le moindre décalage de réplication. Le réplica sélectionné est automatiquement promu au rang de principal, ce qui est beaucoup plus rapide que de créer et de remettre en service 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 activé, ElastiCache contrôle en permanence l'état du nœud primaire. En cas de défaillance du nœud principal, l'une des actions suivantes est effectuée selon le type de la défaillance.

Rubriques

Scénarios d'échec lorsque seul le nœud primaire échoue
Scénarios de défaillance en cas de défaillance du nœud primaire et de certains réplicas en lecture
Scénarios d'échec lorsque l'ensemble du cluster tombe en panne

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

Si seul le nœud principal échoue, le réplica en lecture ayant le moindre décalage de réplication est promu au rang de principal. Un réplica en lecture de remplacement est ensuite créé et provisionné dans la même zone de disponibilité que le principal défaillant.

Lorsque seul le nœud primaire échoue, ElastiCache Multi-AZ effectue les opérations suivantes :

Le nœud principal défaillant est mis hors ligne.
Le réplica en lecture ayant le moindre décalage de réplication est promu au rang de principal.

Les écritures peuvent reprendre dès que le processus de promotion est terminé, généralement au bout de quelques secondes. Si votre application écrit sur le point de terminaison primaire, il n'est pas nécessaire de changer le point de terminaison pour les écritures et les lectures. ElastiCache propage également le nom DNS du réplica promu.
Un réplica en lecture de remplacement est lancé et mis en service.

Le réplica en lecture de remplacement est lancé dans la zone de disponibilité où se trouvait le nœud principal défaillant afin que la distribution de nœuds soit maintenue.
La synchronisation des autres réplicas avec le nouveau nœud principal se produit.

Lorsque le nouveau réplica est disponible, vous devez être conscient des effets suivants :

Point de terminaison principal : vous n'avez besoin d'effectuer aucune modification sur votre application, dans la mesure où le nom DNS du nouveau nœud primaire est propagé au point de terminaison principal.
Point de terminaison de lecture : le point de terminaison du lecteur est automatiquement mis à jour de manière à pointer vers les nouveaux nœuds de réplica.

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 primaire et de certains réplicas en lecture

Lorsque le nœud principal et au moins un réplica en lecture sont défaillants, le réplica disponible avec le moindre décalage de réplication est promu cluster principal. De nouveaux réplicas en lecture sont également créés et mis en service dans les mêmes zones de disponibilité que les nœuds défaillants et le réplica promu cluster principal.

Lorsque le nœud primaire et certains réplicas en lecture échouent, ElastiCache Multi-AZ effectue les opérations suivantes :

Le nœud principal et les réplicas en lecture ayant échoué sont mis hors ligne.
Le réplica en lecture disponible ayant le moindre décalage de réplication est promu au rang de nœud principal.

Les écritures peuvent reprendre dès que le processus de promotion est terminé, généralement au bout de quelques secondes. Si votre application écrit sur le point de terminaison primaire, il n'est pas nécessaire de changer le point de terminaison pour les écritures. ElastiCache propage également le nom DNS du réplica promu.
Des réplicas de remplacement sont créés et provisionnés.

Les réplicas de remplacement sont créés dans les zones de disponibilité des nœuds ayant échoué afin que la distribution des nœuds soit maintenue.
Tous les clusters sont synchronisés avec le nouveau nœud principal.

Vous devez apporter les modifications suivantes à votre application, une fois que les nouveaux nœuds sont disponibles :

Point de terminaison principal : n'apportez aucune modification à votre application. Le nom DNS du nouveau nœud principal est propagé au point de terminaison principal.
Point de terminaison de lecture : le point de terminaison de lecture est automatiquement mis à jour de manière à pointer vers les nouveaux nœuds de réplica.

Pour plus d'informations sur la recherche des points de terminaison d'un groupe de réplication, consultez les rubriques 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.

Dans ce scénario, toutes les données du cluster sont perdues en raison de la défaillance au niveau de chaque nœud du cluster. Cela se produit rarement.

Lorsque l'ensemble du cluster tombe en panne, ElastiCache Multi-AZ procède comme suit :

Le nœud principal et les réplicas en lecture ayant échoué sont mis hors ligne.
Un nœud principal de remplacement est créé et mis en service.
Des réplicas de remplacement sont créés et provisionnés.

Les remplacements sont créés dans les zones de disponibilité des nœuds ayant échoué afin que la distribution des nœuds soit maintenue.

Etant donné que la totalité du cluster a échoué, les données sont perdues et tous les nouveaux nœuds démarrent à vide.

Comme chacun des nœuds de remplacement a le même point de terminaison que le nœud qu'il remplace, il n'est pas nécessaire de modifier le point de terminaison de votre application.

Pour plus d'informations sur la recherche des points de terminaison d'un groupe de réplication, consultez les rubriques suivantes :

Nous vous recommandons de créer le nœud principal et les réplicas dans différentes zones de disponibilité pour augmenter votre niveau de tolérance aux pannes.

Test du basculement automatique

Une fois que vous avez activé le basculement automatique, vous pouvez le tester avec la console ElastiCache, la AWS CLI et l'API ElastiCache.

Lors du test, tenez compte des points suivants :

Vous pouvez utiliser cette opération pour tester le basculement automatique sur un maximum de 5 partitions (nommées groupes de nœuds dans l'API ElastiCache et la AWS CLI) au cours de n'importe quelle période de 24 heures.
Si vous appelez cette opération sur des partitions de différents clusters (nommés groupes de réplication dans l'API et la CLI), vous pouvez effectuer des appels simultanément.
Dans certains cas, vous pouvez appeler cette opération plusieurs fois sur différentes partitions du même groupe de réplication Redis (Mode cluster activé). Dans de tels cas, le premier remplacement de nœud doit se terminer avant qu'un appel ultérieur puisse être effectué.
Pour déterminer si le remplacement de nœud est terminé, vérifiez les événements à l'aide de la console Amazon ElastiCache, de la AWS CLI ou de l'API ElastiCache. Recherchez les événements suivants liés au basculement automatique, répertoriés ici dans leur ordre d'occurrence probable :
1. Message du groupe de réplication : Test Failover API called for node group <node-group-id>
2. Message du cluster de cache : Failover from primary node <primary-node-id> to replica node <node-id> completed
3. Message du groupe de réplication : Failover from primary node <primary-node-id> to replica node <node-id> completed
4. Message du cluster de cache : Recovering cache nodes <node-id>
5. Message du cluster de cache : Finished recovery for cache nodes <node-id>
Pour plus d'informations, veuillez consulter les ressources suivantes :
- Affichage des événements ElastiCache dans le Guide de l'utilisateur ElastiCache
- DescribeEvents dans la Référence de l'API ElastiCache
- describe-events dans la Référence des commandes de l'AWS CLI.
Cette API est conçue pour tester le comportement de votre application en cas de basculement ElastiCache. Elle n’a pas été conçue pour être un outil opérationnel permettant de lancer un basculement pour résoudre un problème avec le cluster. De plus, il arrive que, dans certaines conditions telles que des événements opérationnels à grande échelle, AWS peut bloquer cette API.

Rubriques

Test du basculement automatique à l'aide de la AWS Management Console
Test du basculement automatique à l'aide de la AWS CLI
Test du basculement automatique à l'aide de l'API ElastiCache

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

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

Pour tester le basculement automatique

Connectez-vous à la AWS Management Console et ouvrez la console ElastiCache à l'adresse https://console.aws.amazon.com/elasticache/.
Dans le volet de navigation, choisissez Redis.
Dans la liste des clusters Redis, cochez la case située à gauche du nom du cluster Redis que vous souhaitez tester. Ce cluster doit avoir au moins un nœud de réplica en lecture.
Dans la zone Détails vérifiez que la fonctionnalité Multi-AZ est activée pour ce cluster. Si tel n'est pas le cas, choisissez un autre cluster ou modifiez-le afin d'activer Multi-AZ. Pour de plus amples informations, veuillez consulter À l'aide du AWS Management Console.
Pour Redis (mode cluster désactivé), choisissez le nom du cluster.

Pour Redis (mode cluster activé), procédez comme suit :
1. Choisissez le nom du cluster.
2. Sur la page Partitions, pour la partition (nommée groupe de nœuds dans l'API ou la CLI) sur laquelle vous souhaitez tester le basculement, choisissez le nom de la partition.
Sur la page Nœuds, choisissez Failover Primary.
Choisissez Continuer pour basculer le nœud principal, ou sur Annuler pour annuler l'opération et ne pas basculer le nœud principal.

Au cours du processus de basculement, la console continue à afficher le statut available du nœud. Pour suivre l'avancement du test de basculement, choisissezÉvénements dans le volet de navigation de la console. Sous l'onglet Événements, recherchez les événements indiquant que le basculement a commencé (Test Failover API called) et est terminé (Recovery completed).

Test du basculement automatique à l'aide de la AWS CLI

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

Paramètres

--replication-group-id : obligatoire. Groupe de réplication (sur la console, cluster) qui va être testé.
--node-group-id : obligatoire. Nom du groupe de nœuds sur lequel vous souhaitez tester le basculement automatique. Vous pouvez tester un maximum de cinq groupes de nœuds au cours d'une période de 24 heures.

L'exemple suivant utilise la AWS CLI pour tester le basculement automatique sur le groupe de nœuds redis00-0003 dans le cluster Redis (mode cluster activé) redis00.

Exemple Test du basculement automatique

Pour Linux, macOS ou Unix :


aws elasticache test-failover \
   --replication-group-id redis00 \
   --node-group-id redis00-0003

Pour Windows :


aws elasticache test-failover ^
   --replication-group-id redis00 ^
   --node-group-id redis00-0003

Le résultat de la commande précédente doit ressembler à ce qui suit.


{
    "ReplicationGroup": {
        "Status": "available", 
        "Description": "1 shard, 3 nodes (1 + 2 replicas)", 
        "NodeGroups": [
            {
                "Status": "available", 
                "NodeGroupMembers": [
                    {
                        "CurrentRole": "primary", 
                        "PreferredAvailabilityZone": "us-west-2c", 
                        "CacheNodeId": "0001", 
                        "ReadEndpoint": {
                            "Port": 6379, 
                            "Address": "redis1x3-001.7ekv3t.0001.usw2.cache.amazonaws.com"
                        }, 
                        "CacheClusterId": "redis1x3-001"
                    }, 
                    {
                        "CurrentRole": "replica", 
                        "PreferredAvailabilityZone": "us-west-2a", 
                        "CacheNodeId": "0001", 
                        "ReadEndpoint": {
                            "Port": 6379, 
                            "Address": "redis1x3-002.7ekv3t.0001.usw2.cache.amazonaws.com"
                        }, 
                        "CacheClusterId": "redis1x3-002"
                    }, 
                    {
                        "CurrentRole": "replica", 
                        "PreferredAvailabilityZone": "us-west-2b", 
                        "CacheNodeId": "0001", 
                        "ReadEndpoint": {
                            "Port": 6379, 
                            "Address": "redis1x3-003.7ekv3t.0001.usw2.cache.amazonaws.com"
                        }, 
                        "CacheClusterId": "redis1x3-003"
                    }
                ], 
                "NodeGroupId": "0001", 
                "PrimaryEndpoint": {
                    "Port": 6379, 
                    "Address": "redis1x3.7ekv3t.ng.0001.usw2.cache.amazonaws.com"
                }
            }
        ], 
        "ClusterEnabled": false, 
        "ReplicationGroupId": "redis1x3", 
        "SnapshotRetentionLimit": 1, 
        "AutomaticFailover": "enabled", 
        "MultiAZ": "enabled",
        "SnapshotWindow": "11:30-12:30", 
        "SnapshottingClusterId": "redis1x3-002", 
        "MemberClusters": [
            "redis1x3-001", 
            "redis1x3-002", 
            "redis1x3-003"
        ], 
        "CacheNodeType": "cache.m3.medium", 
        "DataTiering": "disabled",
        "PendingModifiedValues": {}
    }
}

Pour suivre la progression du basculement, utilisez l'opération describe-events de l'AWS CLI.

Pour plus d'informations, veuillez consulter les ressources suivantes :

test-failover dans la Référence des commandes de l'AWS CLI.
describe-events dans la Référence des commandes de l'AWS CLI.

Test du basculement automatique à l'aide de l'API ElastiCache

Vous pouvez tester le basculement automatique sur n'importe quel cluster pour lequel l'option Multi-AZ est activée à l'aide de l'opération TestFailover de l'API ElastiCache.

Paramètres

ReplicationGroupId : obligatoire. Groupe de réplication (sur la console, le cluster) qui va être testé.
NodeGroupId : obligatoire. Nom du groupe de nœuds sur lequel vous souhaitez tester le basculement automatique. Vous pouvez tester un maximum de cinq groupes de nœuds au cours d'une période de 24 heures.

L'exemple suivant teste le basculement automatique sur le groupe de nœuds redis00-0003 dans le groupe de réplication (sur la console, cluster) redis00.

Exemple Test du basculement automatique


https://elasticache.us-west-2.amazonaws.com/
    ?Action=TestFailover
    &NodeGroupId=redis00-0003
    &ReplicationGroupId=redis00
    &Version=2015-02-02
    &SignatureVersion=4
    &SignatureMethod=HmacSHA256
    &Timestamp=20140401T192317Z
    &X-Amz-Credential=<credential>

Pour suivre la progression du basculement, utilisez l'opération DescribeEvents de l'API ElastiCache.

Pour plus d'informations, veuillez consulter les ressources suivantes :

TestFailover dans la Référence de l'API ElastiCache
DescribeEvents dans la Référence de l'API ElastiCache

Restrictions sur Redis Multi-AZ

Soyez conscient des limitations suivantes pour Redis Multi-AZ :

Multi-AZ est pris en charge sur la version Redis 2.8.6 et versions ultérieures.
Redis Multi-AZ n'est pas pris en charge sur les types de nœuds T1.
La réplication Redis est asynchrone. Par conséquent, lorsqu'un nœud principal bascule vers un réplica, une petite quantité de données peut être perdue en raison d'un décalage de réplication.

Lorsque vous choisissez le réplica à promouvoir en réplica principal, ElastiCache choisit le réplica ayant le moindre décalage de réplication. En d'autres termes, il choisit le réplica le plus à jour. Cela permet de réduire la quantité de données perdues. Le réplica dont le décalage de réplication est le moins important peut se trouver dans la même zone de disponibilité que le nœud principal défaillant ou dans une zone de disponibilité différente.
Lorsque vous promouvez manuellement des réplicas en lecture en réplica principal sur Redis (mode cluster désactivé), vous ne pouvez le faire que si le mode Multi-AZ avec basculement automatique est désactivé. Pour promouvoir un réplica en lecture en réplica principal, procédez comme suit :
1. Désactivez Multi-AZ sur le cluster.
2. Désactivez le basculement automatique sur le cluster. Vous pouvez effectuer cette opération à l'aide de la console Redis en désactivant la fonctionnalité Basculement automatique pour le groupe de réplication. Pour ce faire, vous pouvez utiliser l'outil AWS CLI en définissant la propriété AutomaticFailoverEnabled à false lors de l'appel de l'opération ModifyReplicationGroup.
3. Promouvez le réplica en lecture en réplica principal.
4. Réactivez Multi-AZ.
ElastiCache for Redis Multi-AZ et append-only file (AOF) sont mutuellement exclusifs. Si vous en activez une, vous ne pouvez pas activer l'autre.
La défaillance d'un nœud peut être provoquée par une improbable panne générale de la zone de disponibilité. Dans ce cas, le réplica remplaçant le réplica principal ayant échoué n'est créé que si la zone de disponibilité est rétablie. Par exemple, imaginons un groupe de réplication avec le principal dans AZ-a et des réplicas dans AZ-b et AZ-c. En cas de défaillance du principal, le réplica ayant le moindre décalage de réplication sera promu au rang de cluster principal. Puis, ElastiCache crée un nouveau réplica dans AZ-a (où le principal ayant échoué se trouvait) uniquement quand AZ-a est rétablie et disponible.
Un redémarrage lancé par le client d'un principal n'entraîne de basculement automatique. D'autres redémarrages et défaillances déclenchent un basculement automatique.
Lorsque le principal est redémarré, ses données sont effacées dès qu'il est à nouveau en ligne. Lorsque les réplicas en lecture voient le cluster principal effacé, ils effacent leur copie de données, ce qui entraîne une perte des données.
Une fois qu'un réplica en lecture a été promu, les autres réplicas se synchronisent avec le nouveau principal. Après la synchronisation initiale, le contenu des réplicas est supprimé et ils synchronisent les données du nouveau principal. Ce processus de synchronisation provoque une brève interruption, au cours de laquelle les réplicas ne sont pas accessibles. Le processus de synchronisation entraîne également une augmentation de la charge temporaire sur le cluster principal lors de la synchronisation avec les réplicas. Ce comportement est inhérent à Redis et n'est pas spécifique à la fonctionnalité Multi-AZ ElastiCache. Pour de plus amples informations sur ce comportement Redis, veuillez consulter Réplication sur le site web Redis.

Important

Pour Redis version 2.8.22 et ultérieure, vous ne pouvez pas créer de réplicas externes.

Pour les versions Redis antérieures à la version 2.8.22, nous vous recommandons de ne pas connecter un réplica Redis externe à un cluster ElastiCache pour lequel Multi-AZ est activé. Il s'agit d'une configuration non prise en charge qui peut créer des problèmes pouvant empêcher ElastiCache d'exécuter correctement les mécanismes de basculement et de récupération. Pour connecter un réplica Redis externe à un cluster ElastiCache, assurez-vous que Multi-AZ n'est pas activé avant d'établir la connexion.

Avertissement JavaScript est désactivé ou n'est pas disponible dans votre navigateur.

Pour que vous puissiez utiliser la documentation AWS, Javascript doit être activé. Vous trouverez des instructions sur les pages d'aide de votre navigateur.

Conventions de rédaction

Réplication : Redis (mode cluster désactivé) vs Redis (mode cluster activé)

Implémentation de la sauvegarde et de la synchronisation