Aktivieren von Multi-AZ Fehlerszenarien mit Multi-AZ-Antworten Testen des automatischen Failovers Hinweise zu Multi-AZ

Minimierung von Ausfallzeiten durch die Verwendung ElastiCache von Multi-AZ mit Valkey und Redis OSS

Es gibt eine Reihe von Fällen, in denen ElastiCache bei Valkey und Redis OSS möglicherweise ein primärer Knoten ausgetauscht werden muss. Dazu gehören bestimmte Arten von geplanten Wartungsarbeiten und der unwahrscheinliche Fall eines Ausfalls eines Primärknotens oder einer Availability Zone.

Dieser Austausch führt zu einer gewissen Ausfallzeit für den Cluster, aber wenn Multi-AZ aktiviert ist, wird die Ausfallzeit minimiert. Die Rolle des primären Knotens wird automatisch auf eines der Read Replicas übertragen. Es ist nicht erforderlich, einen neuen Primärknoten zu erstellen und bereitzustellen, da dies transparent ElastiCache gehandhabt wird. Dieser Failover und die Replikatheraufstufung stellen sicher, dass Sie weiter in den neuen primären Knoten schreiben können, sobald die Heraufstufung abgeschlossen wurde.

ElastiCache gibt auch den Namen des Domain Name Service (DNS) des beworbenen Replikats weiter. Auf diese Weise ist in Ihrer Anwendung, falls sie in den primären Endpunkt schreibt, keine Endpunktänderung erforderlich. Wenn Sie aus individuellen Endpunkten lesen, müssen Sie den Leseendpunkt des zum primären Knoten heraufgestuften Replikats in den Endpunkt des neuen Replikats ändern.

Im Falle eines geplanten Knotenaustauschs, der aufgrund von Wartungs- oder Self-Service-Aktualisierungen eingeleitet wird, beachten Sie Folgendes:

Bei ElastiCache Valkey- und OSS Redis-Clustern werden die geplanten Knotenersetzungen abgeschlossen, während der Cluster eingehende Schreibanforderungen bearbeitet.
Bei deaktivierten OSS Clustern im Valkey- und Redis-Clustermodus mit aktiviertem Multi-AZ, die auf der Engine 5.0.6 oder höher ausgeführt werden, werden die geplanten Knotenersetzungen abgeschlossen, während der Cluster eingehende Schreibanforderungen bearbeitet.
Bei deaktivierten OSS Clustern im Valkey- und Redis-Clustermodus mit aktiviertem Multi-AZ, die auf der Engine 4.0.10 oder früher ausgeführt werden, stellen Sie möglicherweise eine kurze Schreibunterbrechung im Zusammenhang mit Updates fest. DNS Diese Unterbrechung kann bis zu einigen Sekunden dauern. Dieser Vorgang ist viel schneller als die Neuerstellung und Bereitstellung einer neuen Primärdatenbank, was geschieht, wenn Sie Multi-AZ nicht aktivieren.

Sie können Multi-AZ mithilfe der ElastiCache Management Console, dem oder dem aktivieren. AWS CLI ElastiCache API

Die Aktivierung von ElastiCache Multi-AZ auf Ihrem Valkey- oder OSS Redis-Cluster (in der Replikationsgruppe API undCLI) verbessert Ihre Fehlertoleranz. Dies gilt insbesondere dann, wenn der Ihrem Cluster zugehörige primäre Cluster für Lese- und Schreibvorgänge nicht verfügbar ist oder ausfällt. Multi-AZ wird nur auf Valkey- und OSS Redis-Clustern mit mehr als einem Knoten in jedem Shard unterstützt.

Aktivieren von Multi-AZ

Sie können Multi-AZ aktivieren, wenn Sie einen Cluster (oder eine Replikationsgruppe) mithilfe der ElastiCache Konsole API oder CLI der erstellen oder ändern. AWS CLI ElastiCache API

Sie können Multi-AZ nur auf Valkey- oder Redis-Clustern OSS (Clustermodus deaktiviert) aktivieren, für die mindestens eine Read Replica verfügbar ist. Cluster ohne Read Replicas bieten keine hohe Verfügbarkeit oder Fehlertoleranz. Weitere Informationen zum Erstellen eines Clusters mit Replikation finden Sie unter Eine Valkey- oder OSS Redis-Replikationsgruppe erstellen. Weitere Informationen zum Hinzufügen einer Read Replica zu einem Cluster mit Replikation finden Sie unter Hinzufügen einer Read Replica für Valkey oder Redis OSS (Cluster-Modus deaktiviert).

Themen

Aktivieren von Multi-AZ (Konsole)
Aktivieren von Multi-AZ (AWS CLI)
Aktivieren von Multi-AZ (ElastiCache API)

Aktivieren von Multi-AZ (Konsole)

Sie können Multi-AZ mithilfe der ElastiCache Konsole aktivieren, wenn Sie einen neuen Valkey- oder OSS Redis-Cluster erstellen oder indem Sie einen vorhandenen Cluster mit Replikation ändern.

Multi-AZ ist standardmäßig auf Valkey- oder Redis-Clustern OSS (Clustermodus aktiviert) aktiviert.

Wichtig

ElastiCache aktiviert Multi-AZ automatisch nur dann, wenn der Cluster in allen Shards mindestens ein Replikat in einer anderen Availability Zone als der primären enthält.

Multi-AZ wird aktiviert, wenn ein Cluster mithilfe der Konsole erstellt wird ElastiCache

Weitere Informationen zu diesem Vorgang finden Sie unter Erstellen eines Valkey-Clusters (Cluster-Modus deaktiviert) (Konsole). Achten Sie darauf, dass mehr als ein Replikat vorhanden und Multi-AZ aktiviert ist.

Aktivieren von Multi-AZ auf einem vorhandenen Cluster (Konsole)

Weitere Informationen zu diesem Prozess finden Sie unter „Ändern eines Clusters“ Unter Verwendung der ElastiCache AWS Management Console.

Aktivieren von Multi-AZ (AWS CLI)

Das folgende Codebeispiel verwendet den AWS CLI , um Multi-AZ für die Replikationsgruppe zu aktivieren. redis12

Wichtig

Die Replikationsgruppe redis12 muss bereits vorhanden sein und mindestens eine verfügbare Read Replica besitzen.

Für Linux, macOS oder Unix:


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

Für Windows:


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

Die JSON Ausgabe dieses Befehls sollte etwa wie folgt aussehen.


{
    "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": {}
    }
}

Weitere Informationen zu diesen Themen finden Sie in der AWS CLI -Befehlsreferenz:

create-cache-cluster
create-replication-group
modify-replication-groupin der AWS CLI Befehlsreferenz.

Aktivieren von Multi-AZ (ElastiCache API)

Das folgende Codebeispiel verwendet den ElastiCache API, um Multi-AZ für die Replikationsgruppe redis12 zu aktivieren.

Anmerkung

Zur Verwendung dieses Beispiels muss die Replikationsgruppe redis12 bereits vorhanden sein und mindestens ein verfügbares Lesereplikat besitzen.


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>

Weitere Informationen finden Sie in der ElastiCache APIReferenz zu den folgenden Themen:

Fehlerszenarien mit Multi-AZ-Antworten

Vor der Einführung von Multi-AZ wurden die ausgefallenen Knoten eines Clusters ElastiCache erkannt und ersetzt, indem der ausgefallene Knoten neu erstellt und neu bereitgestellt wurde. Wenn Sie Multi-AZ aktivieren, wird bei einem ausgefallenen primärer Knoten ein Failover auf das Replikat mit der geringsten Replikationsverzögerung durchgeführt. Das ausgewählte Replikat wird automatisch zum primären Knoten heraufgestuft. Dies ist sehr viel schneller, als einen neuen primären Knoten zu erstellen und neu bereitzustellen. Bei diesem Vorgang dauert gewöhnlich nur wenige Sekunden, bis Sie wieder in den Cluster schreiben können.

Wenn Multi-AZ aktiviert ist, wird der Status des ElastiCache Primärknotens kontinuierlich überwacht. Sollte der primäre Knoten ausfallen, wird abhängig von der Art des Ausfalls eine der folgenden Aktionen durchgeführt.

Themen

Fehlerszenarien, wenn nur der Primärknoten ausfällt
Fehlerszenarien, wenn der Primärknoten und einige Read Replicas (Lesereplikate) fehlschlagen
Fehlerszenarien, wenn der gesamte Cluster ausfällt

Fehlerszenarien, wenn nur der Primärknoten ausfällt

Wenn nur der primäre Knoten ausfällt, wird das Read Replica mit der geringsten Replikationsverzögerung wird zum primären Cluster heraufgestuft. Ein Ersatz-Read Replica wird dann in derselben Availability Zone wie der ausgefallene primäre Knoten erstellt und bereitgestellt .

Wenn nur der Primärknoten ausfällt, geht ElastiCache Multi-AZ wie folgt vor:

Der ausgefallene primäre Knoten wird in den Offline-Zustand versetzt.
Die Read Replica mit der geringsten Replikationsverzögerung wird zum primären Knoten heraufgestuft.

Die Schreibvorgänge können fortgesetzt werden, sobald der Vorgang der Heraufstufung abgeschlossen ist. Dies dauert in der Regel nur einige Sekunden. Wenn Ihre Anwendung auf den primären Endpunkt schreibt, müssen Sie den Endpunkt für Schreib- oder Lesevorgänge nicht ändern. ElastiCachegibt den DNS Namen des hochgestuften Replikats weiter.
Ein Ersatz-Read Replica wird gestartet und bereitgestellt.

Die Ersatz-Read Replica wird in der Availability Zone gestartet, in der sich der ausgefallene Knoten befand. Die Verteilung der Knoten bleibt daher erhalten.
Die anderen Replikate werden mit dem neuen primären Knoten synchronisiert.

Nachdem das neue Replikat verfügbar ist, beachten Sie die folgenden Effekte:

Primärer Endpunkt — Sie müssen keine Änderungen an Ihrer Anwendung vornehmen, da der DNS Name des neuen primären Knotens an den primären Endpunkt weitergegeben wird.
Lese-Endpunkt – Der Lese-Endpunkt wird automatisch aktualisiert, sodass er auf die neuen Replikatknoten verweist.

Weitere Informationen zum Suchen der Endpunkte eines Clusters finden Sie in den folgenden Themen:

Fehlerszenarien, wenn der Primärknoten und einige Read Replicas (Lesereplikate) fehlschlagen

Bei Ausfall des primären Clusters und mindestens einer Read Replica wird das verfügbare Replikat mit der geringsten Replikationsverzögerung zum primären Cluster heraufgestuft. Zudem werden in denselben Availability Zones, in der sich die ausgefallenen Knoten und das zum primären Cluster heraufgestufte Replikat befanden, neue Read Replicas erstellt und bereitgestellt.

Wenn der Primärknoten und einige Read Replicas ausfallen, geht ElastiCache Multi-AZ wie folgt vor:

Der ausgefallene primäre Knoten und ausgefallenen die Read Replicas werden in den Offline-Zustand versetzt.
Das verfügbare Replikat mit der geringsten Replikationsverzögerung wird zum primären Knoten heraufgestuft.

Die Schreibvorgänge können fortgesetzt werden, sobald der Vorgang der Heraufstufung abgeschlossen ist. Dies dauert in der Regel nur einige Sekunden. Wenn Ihre Anwendung auf den primären Endpunkt schreibt, müssen Sie den Endpunkt für Schreibvorgänge nicht ändern. ElastiCache propagiert den DNS Namen des hochgestuften Replikats.
Ersatzreplikate werden erstellt und bereitgestellt.

Die Ersatzreplikate werden in den Availability Zones der ausgefallenen Knoten erstellt, sodass die Verteilung der Knoten erhalten bleibt.
Alle Cluster werden mit dem neuen primären Knoten synchronisiert.

Nehmen Sie die folgenden Änderungen an Ihrer Anwendung vor, wenn die neuen Knoten verfügbar sind:

Primärer Endpunkt – Nehmen Sie keine Änderungen an Ihrer Anwendung vor. Der DNS Name des neuen Primärknotens wird an den primären Endpunkt weitergegeben.
Lese-Endpunkt – Der Lese-Endpunkt wird automatisch so aktualisiert, dass er auf die neuen Replikatknoten verweist.

Weitere Informationen zum Suchen der Endpunkte einer Replikationsgruppe finden Sie in den folgenden Themen:

Fehlerszenarien, wenn der gesamte Cluster ausfällt

Bei einem umfassenden Ausfall werden in denselben Availability Zones, der sich die Originalknoten befanden, alle Knoten neu erstellt und bereitgestellt.

In diesem Szenario gehen alle Daten im Cluster aufgrund des Ausfalls eines jeden Knotens im Cluster verloren. Ein solches Ereignis ist selten.

Wenn der gesamte Cluster ausfällt, geht ElastiCache Multi-AZ wie folgt vor:

Der ausgefallene primäre Knoten und die Read Replicas werden in den Offline-Zustand versetzt.
Es wird ein primäre Ersatzknoten erstellt und bereitgestellt.
Ersatzreplikate werden erstellt und bereitgestellt.

Die Ersetzungen werden in den Availability Zones der ausgefallenen Knoten erstellt, sodass die Verteilung der Knoten erhalten bleibt.

Da der gesamte Cluster ausgefallen ist, kam es zu Datenverlust. Alle neuen Knoten werden kalt gestartet.

Da jeder Ersatzknoten denselben Endpunkt wie der Knoten hat, der durch ihn ersetzt wird, müssen in Ihrer Anwendung keine Endpunktänderungen vorgenommen werden.

Weitere Informationen zum Suchen der Endpunkte einer Replikationsgruppe finden Sie in den folgenden Themen:

Es wird empfohlen, den primären Knoten und die Read Replicas in verschiedenen Availability Zones zu erstellen. Dadurch wird der Grad der Fehlertoleranz erhöht.

Testen des automatischen Failovers

Nachdem Sie das automatische Failover aktiviert haben, können Sie es mit der ElastiCache Konsole AWS CLI, dem und dem testen. ElastiCache API

Beim Testen ist Folgendes zu beachten:

Sie können diesen Vorgang verwenden, um das automatische Failover auf bis zu 15 Shards (im ElastiCache API und als Knotengruppen bezeichnet AWS CLI) in einem beliebigen Zeitraum von 24 Stunden zu testen.
Wenn Sie diesen Vorgang für Shards in verschiedenen Clustern (im API und als Replikationsgruppen bezeichnetCLI) aufrufen, können Sie die Aufrufe gleichzeitig tätigen.
In einigen Fällen können Sie diesen Vorgang mehrmals auf verschiedenen Shards in derselben Valkey- oder Redis-Replikationsgruppe OSS (Clustermodus aktiviert) aufrufen. In solchen Fällen muss die erste Knotenersetzung abgeschlossen werden, bevor ein nachfolgender Aufruf ausgeführt werden kann.
Um festzustellen, ob der Knotenaustausch abgeschlossen ist, überprüfen Sie die Ereignisse mithilfe der ElastiCache Amazon-Konsole AWS CLI, der oder der ElastiCache API. Suchen Sie nach den folgenden Ereignissen im Zusammenhang mit automatischem Failover, die hier nach der Wahrscheinlichkeit ihres Auftretens aufgelistet werden:
1. Meldung der Repliakationsgruppe: Test Failover API called for node group <node-group-id>
2. Meldung des Cache-Clusters: Failover from primary node <primary-node-id> to replica node <node-id> completed
3. Meldung der Repliakationsgruppe: Failover from primary node <primary-node-id> to replica node <node-id> completed
4. Meldung des Cache-Clusters: Recovering cache nodes <node-id>
5. Meldung des Cache-Clusters: Finished recovery for cache nodes <node-id>
Weitere Informationen finden Sie hier:
- ElastiCache Ereignisse anzeigen im ElastiCache -Benutzerhandbuch
- DescribeEventsin der ElastiCache APIReferenz
- describe-events in der AWS CLI -Befehlsreferenz.
Dies API dient dazu, das Verhalten Ihrer Anwendung im Falle eines ElastiCache Failovers zu testen. Sie wurde nicht als Betriebstool zum Einleiten eines Failovers konzipiert, um ein Problem mit dem Cluster zu beheben. Darüber hinaus AWS kann dies unter bestimmten Bedingungen, z. B. bei großen Betriebsereignissen, blockiert werden. API

Themen

Testen des automatischen Failovers mit dem AWS Management Console
Testen Sie den automatischen Failover mit dem AWS CLI
Testen Sie den automatischen Failover mit dem ElastiCache API

Testen des automatischen Failovers mit dem AWS Management Console

Verwenden Sie das folgende Verfahren, um das automatische Failover mit der Konsole zu testen.

So testen Sie das automatische Failover

Melden Sie sich bei der an AWS Management Console und öffnen Sie die ElastiCache Konsole unter https://console.aws.amazon.com/elasticache/.
Wählen Sie im Navigationsbereich Valkey oder OSSRedis aus.
Wählen Sie in der Clusterliste das Feld links neben dem Cluster aus, den Sie testen möchten. Dieser Cluster muss mindestens einen Read Replica-Knoten enthalten.
Bestätigen Sie im Bereich Details, dass dieser Cluster Multi-AZ-fähig ist. Wenn der Cluster nicht Multi-AZ-fähig ist, wählen Sie einen anderen Cluster aus oder bearbeiten Sie diesen Cluster so, dass Multi-AZ aktiviert wird. Weitere Informationen finden Sie unter Unter Verwendung der ElastiCache AWS Management Console.
Wählen Sie für Valkey oder Redis OSS (Clustermodus deaktiviert) den Namen des Clusters.

Gehen Sie für Valkey oder Redis OSS (Clustermodus aktiviert) wie folgt vor:
1. Wählen Sie den Cluster-Namen aus.
2. Wählen Sie auf der Seite Shards für den Shard (im API und als Knotengruppe bezeichnetCLI), auf dem Sie den Failover testen möchten, den Namen des Shards aus.
Wählen Sie auf der Seite „Nodes“ Failover Primary.
Wählen Sie Continue, um ein Failover des primären Knotens auszuführen, oder wählen Sie Cancel, um die Operation ohne ein Failover des primären Knotens abzubrechen.

Während des Failover-Vorgangs zeigt die Konsole den Status des Knotens weiterhin als available an. Um den Status des Failover-Tests zu verfolgen, wählen Sie im Navigationsbereich der Konsole Events aus. Suchen Sie auf der Registerkarte Events nach Ereignissen, für die angegeben wird, dass Ihr Failover gestartet (Test Failover API called) und abgeschlossen (Recovery completed) wurde.

Testen Sie den automatischen Failover mit dem AWS CLI

Mithilfe dieses Vorgangs können Sie das automatische Failover auf jedem Multi-AZ-fähigen Cluster testen. AWS CLI test-failover

Parameter

--replication-group-id – Erforderlich. Die Replikationsgruppe (auf der Konsole als Cluster bezeichnet), die getestet werden soll.
--node-group-id – Erforderlich. Der Name der Knotengruppe, auf der das automatische Failover getestet werden soll. Sie können maximal 15 Knotengruppen in einem fortlaufenden Zeitraum von 24 Stunden testen.

Im folgenden Beispiel wird der verwendet AWS CLI , um den automatischen Failover für die Knotengruppe redis00-0003 im Valkey- oder Redis-Cluster OSS (Clustermodus aktiviert) zu testen. redis00

Beispiel Testen des automatischen Failovers

Für Linux, macOS oder Unix:


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

Für Windows:


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

Die Ausgabe des vorhergehenden Befehls sieht in etwa wie folgt aus.


{
    "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": {}
    }
}

Verwenden Sie den Vorgang, um den Fortschritt Ihres Failovers zu verfolgen. AWS CLI describe-events

Weitere Informationen finden Sie hier:

test-failover in der AWS CLI -Befehlsreferenz.
describe-events in der AWS CLI -Befehlsreferenz.

Testen Sie den automatischen Failover mit dem ElastiCache API

Mithilfe dieses Vorgangs können Sie das automatische Failover auf jedem Cluster testen, für den ElastiCache API Multi-AZ aktiviert ist. TestFailover

Parameter

ReplicationGroupId – Erforderlich. Die Replikationsgruppe (auf der Konsole als Cluster bezeichnet), die getestet werden soll.
NodeGroupId – Erforderlich. Der Name der Knotengruppe, auf der das automatische Failover getestet werden soll. Sie können maximal 15 Knotengruppen in einem fortlaufenden Zeitraum von 24 Stunden testen.

Das folgende Beispiel testet das automatische Failover auf der Knotengruppe redis00-0003 in der Replikationsgruppe (auf der Konsole im Cluster) redis00.

Beispiel Testen des automatischen Failovers


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>

Verwenden Sie den ElastiCache DescribeEvents API Vorgang, um den Fortschritt Ihres Failovers zu verfolgen.

Weitere Informationen finden Sie hier:

TestFailoverin der Referenz ElastiCache API
DescribeEventsin der ElastiCache APIReferenz

Einschränkungen bei Multi-AZ

Beachten Sie die folgenden Einschränkungen für Multi-AZ:

Multi-AZ wird auf Valkey und auf Redis OSS Version 2.8.6 und höher unterstützt.
Multi-AZ wird auf T1-Knotentypen nicht unterstützt.
Die Valkey- und OSS Redis-Replikation erfolgt asynchron. Daher kann es passieren, dass bei dem Failover eines primären Clusters auf ein Replikat aufgrund der Replikationsverzögerung eine kleine Datenmenge verloren geht.

Bei der Auswahl des Replikats, das zum Primärreplikat heraufgestuft werden soll, wird das Replikat mit ElastiCache der geringsten Verzögerung bei der Replikation ausgewählt. Es wird also das neueste Replikat ausgewählt. Hierdurch kann die Menge verlorener Daten reduziert werden. Das Replikat mit der geringsten Replikationsverzögerung kann sich in der gleichen oder in einer anderen Availability Zone als der ausgefallene primäre Knoten befinden.
Wenn Sie Read Replicas auf Valkey- oder OSS Redis-Clustern mit deaktiviertem Clustermodus manuell zu primär heraufstufen, können Sie dies nur tun, wenn Multi-AZ und automatisches Failover deaktiviert sind. So stufen Sie eine Read Replica zum primären Knoten herauf:
1. Deaktivieren Sie Multi-AZ auf dem Cluster.
2. Deaktivieren Sie das automatische Failover auf dem Cluster. Sie können dies über die Konsole tun, indem Sie das Kontrollkästchen Auto Failover für die Replikationsgruppe deaktivieren. Sie können dies auch tun, AWS CLI indem Sie die AutomaticFailoverEnabled Eigenschaft false beim Aufrufen des ModifyReplicationGroup Vorgangs auf setzen.
3. Stufen Sie das Lesereplikat zum primären Knoten herauf.
4. Multi-AZ wieder aktivieren.
ElastiCache (RedisOSS) Multi-AZ und Datei (AOF), die nur anhängen, schließen sich gegenseitig aus. Wenn Sie eine dieser Funktionen aktivieren, kann die andere nicht aktiviert werden.
Der Ausfall eines Knotens kann durch den Ausfall einer gesamten Availability Zone verursacht werden. In diesem Fall wird das Replikat, das den ausgefallenen primären Knoten ersetzt, nur bei Verfügbarkeit der Availability Zone erstellt. Betrachten Sie beispielsweise eine Replikationsgruppe mit den primären Knoten in AZ-a und Replikaten in AZ-b und AZ-c. Wenn der primäre Konten ausfällt, wird das Replikat mit der geringsten Replikationsverzögerung wird zum primären Cluster heraufgestuft. ElastiCache Erstellt dann nur dann ein neues Replikat in AZ-a (wo sich die ausgefallene Primärreplikation befand), wenn AZ-a gesichert und verfügbar ist.
Ein vom Kunden initiierter Neustart des primären Clusters löst kein automatisches Failover aus. Andere Neustarts und Ausfälle hingegen lösen ein automatisches Failover aus.
Wenn der primäre Cluster neu gestartet wird, werden seine Daten gelöscht, wenn er wieder online ist. Wenn die Read Replicas den gelöschten primären Cluster sehen, löschen sie ihre Kopie der Daten, was zu Datenverlust führt.
Nachdem die Read Replica heraufgestuft wurde, werden die anderen Replikate mit dem neuen primären Cluster synchronisiert. Nach der ersten Synchronisierung wird der Inhalt der Replikate gelöscht, und sie synchronisieren die Daten aus dem neuen primären Cluster. Dieser Synchronisierungsvorgang führt zu einer kurzen Unterbrechung, bei der auf die Replikate nicht zugegriffen werden kann. Dieser Synchronisierungsvorgang bewirkt eine temporäre Zunahme der Arbeitslast auf dem primären Cluster, während er mit den Replikaten synchronisiert wird. Dieses Verhalten ist typisch für Valkey und Redis OSS und gilt nicht nur für Multi-AZ. ElastiCache Einzelheiten zu diesem Verhalten finden Sie unter Replikation auf der Valkey-Website.

Wichtig

Für Valkey 7.2.6 und höher oder Redis OSS Version 2.8.22 und höher können Sie keine externen Replikate erstellen.

Für OSS Redis-Versionen vor 2.8.22 empfehlen wir, kein externes Replikat mit einem Cluster zu verbinden, der Multi-AZ-fähig ist. ElastiCache Diese nicht unterstützte Konfiguration kann zu Problemen führen, die eine ordnungsgemäße Durchführung von Failover und Wiederherstellung ElastiCache verhindern. Um ein externes Replikat mit einem ElastiCache Cluster zu verbinden, stellen Sie sicher, dass Multi-AZ nicht aktiviert ist, bevor Sie die Verbindung herstellen.

Warnung JavaScript ist in Ihrem Browser nicht verfügbar oder deaktiviert.

Zur Nutzung der AWS-Dokumentation muss JavaScript aktiviert sein. Weitere Informationen finden auf den Hilfe-Seiten Ihres Browsers.

Dokumentkonventionen

Replikation: Valkey- und OSS Redis-Clustermodus deaktiviert oder aktiviert

So werden Synchronisation und Backup implementiert