Minimierung von Ausfallzeiten in MemoryDB mit Multi-AZ - Amazon MemoryDB
Fehlerszenarien mit Multi-AZ-AntwortenTesten des automatischen Failovers

Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Minimierung von Ausfallzeiten in MemoryDB mit Multi-AZ

Es gibt eine Reihe von Fällen, in denen MemoryDB möglicherweise einen Primärknoten austauschen muss. Dazu gehören bestimmte Arten von geplanten Wartungsarbeiten und der unwahrscheinliche Fall eines Ausfalls eines Primärknotens oder einer Availability Zone.

Die Reaktion auf einen Knotenausfall hängt davon ab, welcher Knoten ausgefallen ist. In allen Fällen stellt MemoryDB jedoch sicher, dass beim Austausch von Knoten oder beim Failover keine Daten verloren gehen. Wenn beispielsweise ein Replikat ausfällt, wird der ausgefallene Knoten ersetzt und Daten aus dem Transaktionslog synchronisiert. Wenn der primäre Knoten ausfällt, wird ein Failover auf ein konsistentes Replikat ausgelöst, wodurch sichergestellt wird, dass beim Failover keine Daten verloren gehen. Die Schreibvorgänge werden jetzt vom neuen Primärknoten aus bedient. Der alte Primärknoten wird dann ersetzt und anhand des Transaktionsprotokolls synchronisiert.

Wenn ein primärer Knoten auf einem einzelnen Knoten-Shard (keine Replikate) ausfällt, akzeptiert MemoryDB keine Schreibvorgänge mehr, bis der primäre Knoten ersetzt und mit dem Transaktionslog synchronisiert wird.

Der Austausch eines Knotens kann zu einigen Ausfallzeiten für den Cluster führen, aber wenn Multi-AZ aktiv ist, werden die Ausfallzeiten minimiert. Die Rolle des primären Knotens wird automatisch auf eines der Replikate übertragen. Es ist nicht erforderlich, einen neuen Primärknoten zu erstellen und bereitzustellen, da MemoryDB dies transparent handhabt. Dieser Failover und die Replikatheraufstufung stellen sicher, dass Sie weiter in den neuen primären Knoten schreiben können, sobald die Heraufstufung abgeschlossen wurde.

Bei geplanten Knotenersetzungen, die aufgrund von Wartungsupdates oder Service-Updates initiiert werden, sollten Sie sich bewusst sein, dass der geplante Knotenaustausch abgeschlossen ist, während der Cluster eingehende Schreibanforderungen bearbeitet.

Multi-AZ auf Ihren MemoryDB-Clustern verbessert Ihre Fehlertoleranz. Dies gilt insbesondere in Fällen, in denen die primären Knoten Ihres Clusters nicht mehr erreichbar sind oder aus irgendeinem Grund ausfallen. Multi-AZ auf MemoryDB-Clustern erfordert, dass jeder Shard mehr als einen Knoten hat, und wird automatisch aktiviert.

Fehlerszenarien mit Multi-AZ-Antworten

Wenn Multi-AZ aktiv ist, erfolgt ein Failover eines ausgefallenen Primärknotens auf ein verfügbares Replikat. Das Replikat wird automatisch mit dem Transaktionslog synchronisiert und wird primär, was viel schneller ist als die Erstellung und erneute Bereitstellung eines neuen Primärknotens. Bei diesem Vorgang dauert gewöhnlich nur wenige Sekunden, bis Sie wieder in den Cluster schreiben können.

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

Fehlerszenarien, wenn nur der Primärknoten ausfällt

Wenn nur der Primärknoten ausfällt, wird ein Replikat automatisch zum primären Knoten. Anschließend wird ein Ersatzreplikat erstellt und in derselben Availability Zone wie das ausgefallene Primärreplikat bereitgestellt.

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

  1. Der ausgefallene primäre Knoten wird in den Offline-Zustand versetzt.

  2. Ein up-to-date Replikat wird automatisch primär.

    Schreibvorgänge können wieder aufgenommen werden, sobald der Failover-Vorgang abgeschlossen ist, normalerweise nur ein paar Sekunden.

  3. Ein Ersatzreplikat wird gestartet und bereitgestellt.

    Das Ersatzreplikat wird in der Availability Zone gestartet, in der sich der ausgefallene Primärknoten befand, sodass die Verteilung der Knoten beibehalten wird.

  4. Das Replikat wird mit dem Transaktionslog synchronisiert.

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

 

Ausfallszenarien, wenn der Primärknoten und einige Replikate ausfallen

Wenn das primäre Replikat und mindestens ein Replikat ausfallen, wird ein up-to-date Replikat zum primären Cluster heraufgestuft. Neue Replikate werden außerdem in denselben Availability Zones wie die ausgefallenen Knoten erstellt und bereitgestellt.

Wenn der Primärknoten und einige Replikate ausfallen, geht MemoryDB Multi-AZ wie folgt vor:

  1. Der ausgefallene Primärknoten und die ausgefallenen Replikate werden offline geschaltet.

  2. Ein verfügbares Replikat wird zum primären Knoten.

    Schreibvorgänge können wieder aufgenommen werden, sobald der Failover abgeschlossen ist, normalerweise nur ein paar Sekunden.

  3. Ersatzreplikate werden erstellt und bereitgestellt.

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

  4. Alle Knoten werden mit dem Transaktionslog synchronisiert.

Weitere Informationen zum Suchen der Endpunkte eines Clusters 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 gibt es keinen Datenverlust, da die Daten im Transaktionslog dauerhaft gespeichert wurden.

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

  1. Der ausgefallene Primärknoten und die Replikate werden offline geschaltet.

  2. Ein Ersatz-Primärknoten wird erstellt und bereitgestellt, der mit dem Transaktionsprotokoll synchronisiert wird.

  3. Ersatzreplikate werden erstellt und bereitgestellt und mit dem Transaktionslog synchronisiert.

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

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

Testen des automatischen Failovers

Sie können den automatischen Failover mithilfe der MemoryDB-Konsole, der und der MemoryDB-API testen. AWS CLI

Beim Testen ist Folgendes zu beachten:

  • Sie können diesen Vorgang innerhalb von 24 Stunden bis zu fünf Mal ausführen.

  • Wenn Sie diesen Vorgang für Shards in verschiedenen Clustern aufrufen, können Sie die Aufrufe gleichzeitig tätigen.

  • In einigen Fällen können Sie diesen Vorgang mehrmals auf verschiedenen Shards im selben MemoryDB-Cluster 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 Ereignisse mithilfe der MemoryDB-Konsole, der oder der AWS CLI MemoryDB-API. Suchen Sie nach den folgenden Ereignissen im Zusammenhang mitFailoverShard, die hier in der Reihenfolge ihres wahrscheinlichen Auftretens aufgeführt sind:

    1. Cluster-Meldung: FailoverShard API called for shard <shard-id>

    2. Cluster-Nachricht: Failover from primary node <primary-node-id> to replica node <node-id> completed

    3. Cluster-Nachricht: Recovering nodes <node-id>

    4. Cluster-Nachricht: Finished recovery for nodes <node-id>

    Weitere Informationen finden Sie hier:

  • Diese API wurde entwickelt, um das Verhalten Ihrer Anwendung im Falle eines MemoryDB-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 diese API unter bestimmten Bedingungen, z. B. bei großen Betriebsereignissen, blockiert werden.

Testen des automatischen Failovers mit dem AWS Management Console

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

  1. Melden Sie sich bei der MemoryDB-Konsole an AWS Management Console und öffnen Sie sie unter https://console.aws.amazon.com/memorydb/.

  2. Wählen Sie das Optionsfeld links neben dem Cluster, den Sie testen möchten. Dieser Cluster muss mindestens einen Replikatknoten haben.

  3. 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 Einen MemoryDB-Cluster ändern.

  4. Wählen Sie den Cluster-Namen aus.

  5. Wählen Sie auf der Seite Shards and Nodes für den Shard, auf dem Sie den Failover testen möchten, den Namen des Shards aus.

  6. Wählen Sie für den Knoten Failover Primary aus.

  7. 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 (FailoverShard API called) und abgeschlossen (Recovery completed) wurde.

 

Testen des automatischen Failovers mit dem AWS CLI

Sie können das automatische Failover auf jedem Multi-AZ-fähigen Cluster testen, indem Sie den AWS CLI Vorgang failover-Shard verwenden.

Parameter

  • --cluster-name – Erforderlich. Der Cluster, der getestet werden soll.

  • --shard-name – Erforderlich. Der Name des Shards, auf dem Sie den automatischen Failover testen möchten. Sie können in einem fortlaufenden Zeitraum von 24 Stunden maximal fünf Shards testen.

Im folgenden Beispiel wird verwendet AWS CLI , um den Shard 0001 im MemoryDB-Cluster aufzurufenfailover-shard. my-cluster

Für Linux, macOS oder Unix:

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

Für Windows:

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

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

Es wird die folgende JSON-Antwort zurückgegeben:

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

Weitere Informationen finden Sie hier:

 

Testen des automatischen Failovers mithilfe der MemoryDB-API

Das folgende Beispiel ruft den Shard 0003 im Cluster FailoverShard auf. memorydb00

Beispiel Testen des automatischen Failovers
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>

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

Weitere Informationen finden Sie hier: