Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.
Riduzione al minimo dei tempi di inattività ElastiCache utilizzando Multi-AZ con Valkey e Redis OSS
Esistono diversi casi in cui ElastiCache con Valkey e Redis OSS potrebbe essere necessario sostituire un nodo primario, tra cui alcuni tipi di manutenzione pianificata e l'improbabile eventualità di un guasto del nodo primario o della zona di disponibilità.
Questa sostituzione comporta alcuni tempi di inattività per il cluster, ma se la funzione Multi-AZ è abilitata, il tempo di inattività viene ridotto al minimo. Il ruolo del nodo primario eseguirà automaticamente il failover su una delle repliche di lettura. Non è necessario creare ed effettuare il provisioning di un nuovo nodo primario, in quanto ElastiCache gestirà la situazione in modo trasparente. Questo failover e la promozione delle repliche garantiscono la possibilità di ricominciare a scrivere nel nuovo nodo primario non appena la promozione è terminata.
ElastiCache propaga anche il nome Domain Name Service (DNS) della replica promossa. Questo perché se l'applicazione scrive nell'endpoint primario, allora non è richiesta alcuna modifica dell'endpoint nell'applicazione. Tuttavia, poiché la lettura viene eseguita da singoli endpoint, occorre assicurarsi di modificare l'endpoint di lettura della replica promossa al nodo primario nel nuovo endpoint della replica.
In caso di sostituzioni dei nodi pianificati, iniziati a causa di aggiornamenti di manutenzione o aggiornamenti self-service, fare attenzione a quanto segue:
Per i OSS cluster ElastiCache Valkey e Redis, le sostituzioni pianificate dei nodi vengono completate mentre il cluster soddisfa le richieste di scrittura in entrata.
Per i cluster Valkey e Redis disabilitati in modalità OSS cluster con Multi-AZ abilitato che funzionano sul motore 5.0.6 o successivo, le sostituzioni pianificate dei nodi vengono completate mentre il cluster gestisce le richieste di scrittura in entrata.
Per i cluster Valkey e Redis disabilitati in modalità OSS cluster con Multi-AZ abilitato che funzionano sul motore 4.0.10 o precedente, potresti notare una breve interruzione di scrittura associata agli aggiornamenti. DNS Questa interruzione potrebbe richiedere fino a pochi secondi. Questo processo è molto più veloce rispetto a dover ricreare e rieseguire il provisioning di un nuovo primario, come accade nel caso in cui la funzione Multi-AZ non viene abilitata.
È possibile abilitare Multi-AZ utilizzando la console di gestione, o il ElastiCache . AWS CLI ElastiCache API
L'abilitazione di ElastiCache Multi-AZ sul OSS cluster Valkey o Redis (nel gruppo di replica API e CLI nel gruppo di replica) migliora la tolleranza agli errori. Questo vale in particolare nei casi in cui il cluster principale di lettura/scrittura del cluster diventa irraggiungibile o si guasta per qualche motivo. Multi-AZ è supportato solo sui OSS cluster Valkey e Redis con più di un nodo in ogni shard.
Argomenti
Abilitazione della funzione Multi-AZ
È possibile abilitare Multi-AZ quando si crea o si modifica un cluster (APIo CLI un gruppo di replica) utilizzando la console o il. ElastiCache AWS CLI ElastiCache API
È possibile abilitare Multi-AZ solo su cluster Valkey o Redis OSS (modalità cluster disabilitata) che dispongono di almeno una replica di lettura disponibile. I cluster senza repliche di lettura non forniscono alta disponibilità o tolleranza ai guasti. Per informazioni sulla creazione di un cluster con replica, consulta Creazione di un gruppo di replica Valkey o Redis OSS. Per informazioni sull'aggiunta di una replica di lettura a un cluster con replica, consulta Aggiungere una replica di lettura per Valkey o Redis OSS (modalità cluster disabilitata).
Argomenti
Abilitazione del Multi-AZ (console)
È possibile abilitare Multi-AZ utilizzando la ElastiCache console quando si crea un nuovo cluster Valkey o Redis o modificando un OSS cluster esistente con la replica.
Multi-AZ è abilitato per impostazione predefinita sui cluster Valkey o OSS Redis (modalità cluster abilitata).
Importante
ElastiCache abiliterà automaticamente Multi-AZ solo se il cluster contiene almeno una replica in una zona di disponibilità diversa da quella principale in tutti gli shard.
Abilitazione di Multi-AZ durante la creazione di un cluster utilizzando la console ElastiCache
Per ulteriori informazioni su questo processo, consulta Creazione di un cluster Valkey (modalità cluster disabilitata) (console). Assicurati di disporre di una o più repliche e di abilitare la funzione Multi-AZ.
Abilitazione della funzione Multi-AZ in un cluster esistente (console)
Per ulteriori informazioni su questo processo, consulta Usando il ElastiCache AWS Management Console nella sezione relativa alla modifica di un cluster.
Abilitazione di Multi-AZ (AWS CLI)
Il seguente esempio di codice utilizza AWS CLI per abilitare Multi-AZ per il gruppo di replica. redis12
Importante
Il gruppo di replica redis12 deve esistere già e disporre di almeno una replica di lettura.
Per Linux, macOS o Unix:
aws elasticache modify-replication-group \ --replication-group-idredis12\ --automatic-failover-enabled \ --multi-az-enabled \ --apply-immediately
Per Windows:
aws elasticache modify-replication-group ^ --replication-group-idredis12^ --automatic-failover-enabled ^ --multi-az-enabled ^ --apply-immediately
L'JSONoutput di questo comando dovrebbe essere simile al seguente.
{
"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": {}
}
}Per ulteriori informazioni, consulta questi argomenti nel Riferimento ai comandi AWS CLI :
-
modify-replication-groupnel AWS CLI Command Reference.
Abilitazione di Multi-AZ (ElastiCache API)
Il seguente esempio di codice utilizza ElastiCache API per abilitare Multi-AZ per il gruppo di replica. redis12
Nota
Per utilizzare questo esempio, il gruppo di replica redis12 deve esistere già e disporre di almeno una replica di lettura.
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>
Per ulteriori informazioni, consulta questi argomenti nella Guida di riferimento: ElastiCache API
Risposte per scenari di errore relativi alla funzione Multi-AZ
Prima dell'introduzione di Multi-AZ, ElastiCache rilevava e sostituiva i nodi guasti di un cluster ricreando e rifornendo il nodo guasto. Abilitando la funzione Multi-AZ, un nodo primario non riuscito esegue il failover nella replica con il ritardo di replica minimo. La replica selezionata viene promossa automaticamente al nodo primario. Questa è un'operazione molto più rapida rispetto alla creazione e al provisioning di un nuovo nodo primario. Questo processo richiede in genere pochi secondi prima che sia possibile scrivere nuovamente nel cluster.
Quando Multi-AZ è abilitato, monitora ElastiCache continuamente lo stato del nodo primario. Se il nodo primario non riesce, viene eseguita una delle seguenti operazioni a seconda del tipo di errore.
Argomenti
Scenari di errore quando solo il nodo primario non riesce
Se il nodo primario non riesce, la replica di lettura con il tempo di replica minimo viene promossa al cluster primario. Viene quindi creata una replica di lettura sostitutiva e viene eseguito il provisioning nella stessa zona di disponibilità del nodo primario non riuscito.
Quando si verifica un errore solo nel nodo primario, ElastiCache Multi-AZ esegue le seguenti operazioni:
Il nodo primario non riuscito viene portato offline.
La replica di lettura con il tempo di replica minimo viene promossa al nodo primario.
Le scritture possono riprendere non appena il processo di promozione viene completato, in genere pochi secondi. Se l'applicazione sta scrivendo sull'endpoint primario, non è necessario modificare l'endpoint per operazioni di scrittura o lettura. ElastiCachepropaga il DNS nome della replica promossa.
Una replica di lettura sostitutiva viene avviata e sottoposta a provisioning.
La replica di lettura sostitutiva viene avviata nella zona di disponibilità in cui si trovava il nodo primario non riuscito, in modo da mantenere la distribuzione dei nodi.
Le repliche si sincronizzano con il nuovo nodo primario.
Dopo che la nuova replica è disponibile, tieni presente questi effetti:
-
Endpoint primario: non è necessario apportare modifiche all'applicazione, poiché il DNS nome del nuovo nodo primario viene propagato all'endpoint primario.
-
Endpoint di lettura - L'endpoint di lettura viene aggiornato automaticamente per puntare ai nuovi nodi di replica.
Per informazioni sull'individuazione degli endpoint di un cluster, consulta i seguenti argomenti:
Scenari di errore quando il nodo primario e alcune repliche di lettura non riescono
Se il nodo primario e almeno una replica di lettura non riescono, la replica disponibile con il ritardo di replica minimo viene promossa al cluster primario. Nuove repliche di lettura vengono inoltre create e sottoposte a provisioning nelle stesse zone di disponibilità dei nodi non riusciti e della replica che è stata promossa al nodo primario.
Quando il nodo primario e alcune repliche di lettura falliscono, ElastiCache Multi-AZ esegue le seguenti operazioni:
Il nodo primario non riuscito e le repliche di lettura non riuscite vengono portate offline.
La replica disponibile con il tempo di replica minimo viene promossa al nodo primario.
Le scritture possono riprendere non appena il processo di promozione viene completato, in genere pochi secondi. Se l'applicazione sta scrivendo sull'endpoint primario, non è necessario modificare l'endpoint per le scritture. ElastiCache propaga il DNS nome della replica promossa.
Repliche sostitutive vengono create e sottoposte a provisioning.
Le repliche sostitutive vengono create nelle zone di disponibilità dei nodi non riusciti, in modo da mantenere la distribuzione dei nodi.
Tutti i cluster si sincronizzano con il nuovo nodo primario.
Dopo che i nuovi nodi sono disponibili, occorre apportare le seguenti modifiche all'applicazione:
-
Endpoint primario - Non apportare modifiche all'applicazione. Il DNS nome del nuovo nodo primario viene propagato all'endpoint primario.
-
Endpoint di lettura - L'endpoint di lettura viene aggiornato automaticamente per puntare ai nuovi nodi di replica.
Per informazioni sull'individuazione degli endpoint di un gruppo di replica, consulta i seguenti argomenti:
Scenari di fallimento quando l'intero cluster non riesce
In caso di errore generale, tutti i nodi vengono ricreati e sottoposti a provisioning nelle stesse zone di disponibilità dei nodi originali.
In questo scenario, tutti i dati nel cluster vengono persi a causa del guasto di ogni nodo nel cluster. Questa eventualità è rara.
In caso di guasto dell'intero cluster, ElastiCache Multi-AZ esegue le seguenti operazioni:
Il nodo primario e le repliche di lettura non riusciti vengono portati offline.
Un nodo primario sostitutivo viene creato e sottoposto a provisioning.
Repliche sostitutive vengono create e sottoposte a provisioning.
Le sostituzioni vengono create nelle zone di disponibilità dei nodi non riusciti, in modo da mantenere la distribuzione dei nodi.
Poiché l'intero cluster non è riuscito, i dati vengono persi e tutti i nuovi nodi vengono avviati come inattivi.
Poiché ciascuno dei nodi sostitutivi ha lo stesso endpoint del nodo che sta sostituendo, non occorre apportare modifiche all'endpoint nell'applicazione.
Per informazioni sull'individuazione degli endpoint di un gruppo di replica, consulta i seguenti argomenti:
Ti consigliamo di creare il nodo primario e le repliche di lettura in zone di disponibilità diverse per aumentare il livello di tolleranza ai guasti.
Test del failover automatico
Dopo aver abilitato il failover automatico, è possibile testarlo utilizzando la ElastiCache console AWS CLI, il e il. ElastiCache API
Durante il test, tieni presente quanto segue:
-
È possibile utilizzare questa operazione per testare il failover automatico su un massimo di 15 shard (chiamati gruppi di nodi in the ElastiCache API and AWS CLI) in un periodo di 24 ore consecutive.
-
Se si chiama questa operazione su shard in cluster diversi (denominati gruppi di replica in API andCLI), è possibile effettuare le chiamate contemporaneamente.
-
In alcuni casi, è possibile richiamare questa operazione più volte su shard diversi nello stesso gruppo di replica Valkey o Redis OSS (modalità cluster abilitata). In questi casi, la sostituzione del primo nodo deve essere completata prima di effettuare una chiamata successiva.
-
Per determinare se la sostituzione del nodo è completa, controlla gli eventi utilizzando la ElastiCache console Amazon, il AWS CLI, o il ElastiCache API. Cerca i seguenti eventi correlati al failover automatico, elencati qui in ordine di occorrenza:
-
Messaggio del gruppo di replica:
Test Failover API called for node group <node-group-id> -
Messaggio del cluster di cache:
Failover from primary node <primary-node-id> to replica node <node-id> completed -
Messaggio del gruppo di replica:
Failover from primary node <primary-node-id> to replica node <node-id> completed -
Messaggio del cluster di cache:
Recovering cache nodes <node-id> -
Messaggio del cluster di cache:
Finished recovery for cache nodes <node-id>
Per ulteriori informazioni, consulta gli argomenti seguenti:
-
Visualizzazione ElastiCache degli eventi nella Guida per l'utente di ElastiCache
-
DescribeEventsnel ElastiCache APIReference
-
describe-events nel Riferimento ai comandi AWS CLI .
-
APIÈ progettato per testare il comportamento dell'applicazione in caso di ElastiCache failover. Non è progettato per essere uno strumento operativo per l'avvio di un failover per risolvere un problema con il cluster. Inoltre, in determinate condizioni, come eventi operativi su larga scala, AWS potrebbe bloccarlo. API
Argomenti
Test del failover automatico utilizzando AWS Management Console
Utilizza la procedura seguente per testare il failover automatico con la console.
Per testare il failover automatico
-
Accedi a AWS Management Console e apri la ElastiCache console all'indirizzo https://console.aws.amazon.com/elasticache/
. -
Nel pannello di navigazione, scegli Valkey o Redis OSS.
-
Dall'elenco dei cluster, scegli la casella a sinistra del cluster che desideri testare. Questo cluster deve disporre almeno di un nodo di replica di lettura.
-
Nell'area Dettagli, conferma che questo cluster è abilitato per Multi-AZ. Se il cluster non è abilitato per la funzione Multi-AZ, scegliere un cluster diverso o modificare questo cluster per abilitare la funzione Multi-AZ. Per ulteriori informazioni, consulta Usando il ElastiCache AWS Management Console.
Per Valkey o Redis OSS (modalità cluster disabilitata), scegli il nome del cluster.
Per Valkey o Redis OSS (modalità cluster abilitata), procedi come segue:
-
Seleziona il nome del cluster.
-
Nella pagina Shards, per lo shard (chiamato gruppo di nodi in API andCLI) su cui desiderate testare il failover, scegliete il nome dello shard.
-
-
Nella pagina dei nodi, scegli Failover Primary (Failover primario).
-
Scegli Continua per eseguire il failover nel nodo primario o Annulla per annullare l'operazione e non eseguire il failover nel nodo primario.
Durante il processo di failover, la console continua a visualizzare lo stato del nodo come disponibile. Per monitorare l'avanzamento del test di failover, scegli Eventi dal riquadro di navigazione della console. Nella scheda Eventi, cerca gli eventi che indicano che il failover è stato avviato (
Test Failover API called) e completato (Recovery completed).
Test del failover automatico utilizzando AWS CLI
È possibile testare il failover automatico su qualsiasi cluster dotato di Multi-AZ utilizzando l' AWS CLI operazione. test-failover
Parametri
-
--replication-group-id– Obbligatorio. Il gruppo di replica (sulla console, cluster) da testare. -
--node-group-id– Obbligatorio. Il nome del gruppo di nodi sui cui testare il failover automatico. È possibile testare un massimo di 15 gruppi di nodi in un periodo continuativo di 24 ore.
L'esempio seguente lo utilizza AWS CLI per testare il failover automatico sul gruppo di nodi redis00-0003 nel cluster Valkey o Redis OSS (modalità cluster abilitata). redis00
Esempio Test del failover automatico
Per Linux, macOS o Unix:
aws elasticache test-failover \ --replication-group-idredis00\ --node-group-idredis00-0003
Per Windows:
aws elasticache test-failover ^ --replication-group-idredis00^ --node-group-idredis00-0003
L'aspetto dell'output del comando precedente è simile al seguente.
{
"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": {}
}
}Per tenere traccia dell'avanzamento del failover, utilizza l'operazione. AWS CLI describe-events
Per ulteriori informazioni, consulta gli argomenti seguenti:
-
test-failover nel Riferimento ai comandi AWS CLI .
-
describe-events nel Riferimento ai comandi AWS CLI .
Test del failover automatico utilizzando ElastiCache API
È possibile testare il failover automatico su qualsiasi cluster abilitato con Multi-AZ utilizzando l' ElastiCache APIoperazione. TestFailover
Parametri
-
ReplicationGroupId– Obbligatorio. Il gruppo di replica (sulla console, cluster) da testare. -
NodeGroupId– Obbligatorio. Il nome del gruppo di nodi sui cui testare il failover automatico. È possibile testare un massimo di 15 gruppi di nodi in un periodo continuativo di 24 ore.
L'esempio seguente esegue il test del failover automatico sul gruppo di nodi redis00-0003 nel gruppo di replica (sulla console, cluster) redis00.
Esempio Test del failover automatico
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>
Per tenere traccia dell'avanzamento del failover, utilizzate l' ElastiCache DescribeEventsAPIoperazione.
Per ulteriori informazioni, consulta gli argomenti seguenti:
-
TestFailovernel riferimento ElastiCache API
-
DescribeEventsnel ElastiCache APIriferimento
Limitazioni su Multi-AZ
Tieni presente le seguenti limitazioni per Multi-AZ:
-
Multi-AZ è supportato su Valkey e sulla OSS versione Redis 2.8.6 e successive.
-
Multi-AZ non è supportato sui tipi di nodi T1.
-
La replica di Valkey e Redis è OSS asincrona. Pertanto, quando un nodo primario esegue il failover in una replica, si può verificare una piccola perdita di dati a causa del ritardo di replica.
Quando si sceglie la replica da promuovere a principale, ElastiCache sceglie la replica con il minor ritardo di replica. ovvero quella più attuale. Ciò consente di ridurre al minimo la quantità di dati persi. La replica con il ritardo di replica minimo si può trovare nella stessa zona di disponibilità del nodo primario con errore o in una zona diversa.
-
Quando promuovi manualmente le repliche di lettura a primarie su cluster Valkey o Redis con la modalità OSS cluster disabilitata, puoi farlo solo quando Multi-AZ e il failover automatico sono disabilitati. Per promuovere una replica di lettura a nodo primario, procedi come indicato di seguito:
-
Disabilitare la funzione Multi-AZ nel cluster.
-
Disabilitare il failover automatico nel cluster. È possibile eseguire questa operazione tramite la console deselezionando la casella di controllo Auto failover per il gruppo di replica. È inoltre possibile eseguire questa operazione AWS CLI impostando la
AutomaticFailoverEnabledproprietà sufalsequando si chiama l'operazione.ModifyReplicationGroup -
Promuovere la replica di lettura al nodo primario.
-
Riattivare la funzione Multi-AZ.
-
-
ElastiCache (RedisOSS) Multi-AZ e append-only file (AOF) si escludono a vicenda. Se si abilita una, non si può abilitare l'altra.
-
Un guasto del nodo può essere causato dal raro evento di errore di un'intera zona di disponibilità. In questo caso, la replica che sostituisce il nodo primario in errore viene creata solo quando la zona di disponibilità viene ripristinata. Ad esempio, considerare un gruppo di replica con il nodo primario in AZ e le repliche in AZ-b e AZ-c. Se il nodo primario non riesce, la replica con il tempo di replica minimo viene promossa al cluster primario. Quindi, ElastiCache crea una nuova replica in az-A (dove si trovava il file primario guasto) solo quando Az-a è di nuovo attivo e disponibile.
-
Un riavvio di un nodo primario iniziato dal cliente non attiva il failover automatico. Altri riavvi ed guasti attivano il failover automatico.
-
Ogni volta che il nodo primario viene riavviato, i dati vengono cancellati quando ritorna online. Quando le repliche di lettura rilevano il cluster primario cancellato, cancellano la loro copia dei dati causando perdita dei dati.
-
Dopo che una replica di lettura è stata promossa, le altre repliche si sincronizzano con il nuovo nodo primario. Dopo la sincronizzazione iniziale, il contenuto delle repliche viene eliminato e vengono sincronizzati i dati dal nuovo nodo primario. Questo processo di sincronizzazione causa una breve interruzione, durante la quale le repliche non sono accessibili. Il processo di sincronizzazione causa anche un incremento di carico temporaneo sul nodo primario durante la sincronizzazione con le repliche. Questo comportamento è nativo di Valkey e Redis e non è OSS esclusivo di Multi-AZ. ElastiCache Per i dettagli su questo comportamento, consulta Replication
sul sito Web di Valkey.
Importante
Per Valkey 7.2.6 e versioni successive o Redis OSS versione 2.8.22 e successive, non è possibile creare repliche esterne.
Per OSS le versioni Redis precedenti alla 2.8.22, si consiglia di non connettere una replica esterna a un cluster con funzionalità Multi-AZ. ElastiCache Questa configurazione non supportata può creare problemi che impediscono la corretta esecuzione del failover e del ElastiCache ripristino. Per connettere una replica esterna a un ElastiCache cluster, assicurati che Multi-AZ non sia abilitato prima di effettuare la connessione.
