Amazon DocumentDB DocumentDB-Failover - Amazon DocumentDB

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.

Amazon DocumentDB DocumentDB-Failover

In bestimmten Fällen, wie z. B. bei bestimmten Arten von planmäßiger Wartung oder im unwahrscheinlichen Fall eines Ausfalls eines primären Knotens oder einer Availability Zone, erkennt Amazon DocumentDB DocumentDBs (mit MongoDB-Kompatibilität) den Ausfall und ersetzt den primären Knoten. Während eines Failovers wird die Ausfallzeit für Schreibvorgänge minimiert. Das liegt daran, dass die Rolle des primären Knotens auf eine der Read Replicas übergeht, statt dass ein neuer primärer Knoten erstellt und bereitgestellt werden muss. Durch Ausfallerkennung und Replikatheraufstufung wird sichergestellt, dass Sie weiter in den neuen primären Knoten schreiben können, sobald die Heraufstufung abgeschlossen wurde.

Damit das Failover funktioniert, muss Ihr Cluster mindestens zwei Instanzen haben - eine primäre und mindestens eine Replikatinstanz.

Steuern des Failover-Ziels

Amazon DocumentDB DocumentDB-Stufen stellt Ihnen Failover-Stufen zur Verfügung, um zu steuern, welche Replikat-Instance bei einem Failover auf primär umgestellt wird.

Failover-Stufen

Jede Replikat-Instance ist eine Failover-Stufe (0-15) zugeordnet. Wenn ein Failover aufgrund von Wartung oder einem unwahrscheinlichen Hardwareausfall auftritt, geht die primäre Instance auf ein Replikat mit der höchsten Priorität (die niedrigste nummerierte Stufe) über. Wenn mehrere Replikate die gleiche Prioritätsstufe haben, geht die primäre Instance auf das Replikat dieser Stufe über, die der Größe der vorherigen primären Instance am nächsten kommt.

Indem Sie die Failover-Stufe für eine Gruppe ausgewählter Replikate auf 0 (höchste Priorität) setzen, können Sie sicherstellen, dass ein Failover auf eines der Replikate in dieser Gruppe wechselt. Sie können effektiv verhindern, dass bestimmte Replikate im Falle eines Failover zur primären Instance hochgestuft werden, indem Sie diesen Replikaten eine niedrige Stufe (hohe Anzahl) zuweisen. Dies ist nützlich, wenn bestimmte Replikate von einer Anwendung stark genutzt werden und ein Failover auf eine von ihnen eine kritische Anwendung negativ beeinflussen würde.

Sie können die Failover-Stufe einer Instance beim Erstellen oder später festlegen. Das Festlegen einer Instance-Failover-Stufe durch Ändern der Instance löst keinen Failover aus. Weitere Informationen finden Sie in den folgenden Themen:

Wenn Sie einen Failover manuell einleiten, haben Sie zwei Möglichkeiten zur Steuerung, welche Replikat-Instance auf primär umgestellt wird: die Failover-Stufen wie zuvor beschrieben und den Parameter --target-db-instance-identifier.

--target-db-instance-identifier

Zum Testen können Sie mit der Operation failover-db-cluster ein Failover-Ereignis erzwingen. Mit dem Parameter --target-db-instance-identifier können Sie festlegen, welches Replikat auf primär umgestellt werden soll. Die Verwendung des Parameters --target-db-instance-identifier ersetzt die Failover-Prioritätsstufe. Wenn Sie den Parameter --target-db-instance-identifier nicht angeben, entspricht die Primär-Failover-Funktion der Failover-Prioritätsstufe.

Was passiert während eines Failovers?

Der Failover wird automatisch von Amazon DocumentDB DocumentDBs durchgeführt, sodass Ihre Anwendungen den Datenbankbetrieb so schnell wie möglich und ohne Verwaltungseingriff wieder aufnehmen können.

  • Wenn Sie beim Ausfall eine Amazon DocumentDB Replikatinstanz in derselben oder einer anderen Availability Zone haben: Amazon DocumentDB DocumentDB-Limits wechselt den anerkannten Namensdatensatz (CNAME) für Ihre Instance, sodass auf das fehlerfreie Replikat verweist, das dadurch zur neuen primären Instance hochgestuft wird. Das Failover wird in der Regel innerhalb von 30 Sekunden vom Anfang bis zum Ende abgeschlossen.

  • Wenn Sie keine Amazon DocumentDB DocumentDB-Replikat-Instance haben (z. B. einen einzelnen Instance-Cluster): Amazon DocumentDB DocumentDB-Stufe wird versuchen, eine neue Instance in derselben Availability Zone wie die ursprüngliche Instance zu erstellen. Dieser Austausch der ursprünglichen Instance wird nach bestem Bemühen durchgeführt, ist aber nicht immer erfolgreich, z. B. wenn ein Problem vorliegt, das sich allgemein auf die Availability Zone auswirkt.

Bei Verbindungsunterbrechung muss Ihre Anwendung versuchen, die Verbindung zur Datenbank wiederherzustellen.

Testen eines Failovers

Ein Failover für einen Cluster stuft eine der Amazon DocumentDB DocumentDB-Replikate (Read-Only-Instances) im Cluster zu einer primären Instance (den Cluster-Writer) fest.

führt automatisch einen Failover auf ein Amazon DocumentDB DocumentDB-Replikat aus (falls vorhanden), sobald die primäre Instance ausfällt. Sie können ein Failover erzwingen, wenn Sie einen Ausfall einer primären Instance zum Testen simulieren möchten. Jede Instance in einem Cluster hat eine eigene Endpunkt-Adresse. Aus diesem Grund müssen Sie alle bestehenden Verbindungen, die diese Endpunktadressen verwenden, bereinigen und wiederherstellen, wenn der Failover abgeschlossen ist.

Um einen Failover zu erzwingen, verwenden Sie die Operation failover-db-cluster mit diesen Parametern.

  • --db-cluster-identifier—Erforderlich. Der Name des Clusters, der einen Failover durchführen soll.

  • --target-db-instance-identifier—Optional. Der Name der Instance, die zur primären Instance befördert werden soll.

Die folgende Operation erzwingt einen Failover des Clusters sample-cluster. Es wird nicht angegeben, welche Instance die neue primäre Instance bilden soll, daher wählt Amazon DocumentDB DocumentDB-Limits die Instance entsprechend der Failover-Tier-Stufe aus.

Für Linux, macOS oder Unix:

aws docdb failover-db-cluster \ --db-cluster-identifier sample-cluster

Für Windows:

aws docdb failover-db-cluster ^ --db-cluster-identifier sample-cluster

Die folgende Operation erzwingt einen Failover des Clusters sample-cluster und legt fest, dass sample-cluster-instance in die primäre Rolle befördert werden soll. (Beachten Sie "IsClusterWriter": true in der Ausgabe.)

Für Linux, macOS oder Unix:

aws docdb failover-db-cluster \ --db-cluster-identifier sample-cluster \ --target-db-instance-identifier sample-cluster-instance

Für Windows:

aws docdb failover-db-cluster ^ --db-cluster-identifier sample-cluster ^ --target-db-instance-identifier sample-cluster-instance

Die Ausgabe dieser Operation sieht in etwa folgendermaßen aus (JSON-Format).

{ "DBCluster": { "HostedZoneId": "Z2SUY0A1719RZT", "Port": 27017, "EngineVersion": "3.6.0", "PreferredMaintenanceWindow": "thu:04:05-thu:04:35", "BackupRetentionPeriod": 1, "ClusterCreateTime": "2018-06-28T18:53:29.455Z", "AssociatedRoles": [], "DBSubnetGroup": "default", "MasterUsername": "master-user", "Engine": "docdb", "ReadReplicaIdentifiers": [], "EarliestRestorableTime": "2018-08-21T00:04:10.546Z", "DBClusterIdentifier": "sample-cluster", "ReaderEndpoint": "sample-cluster.node.us-east-1.docdb.amazonaws.com", "DBClusterMembers": [ { "DBInstanceIdentifier": "sample-cluster-instance", "DBClusterParameterGroupStatus": "in-sync", "PromotionTier": 1, "IsClusterWriter": true }, { "DBInstanceIdentifier": "sample-cluster-instance-00", "DBClusterParameterGroupStatus": "in-sync", "PromotionTier": 1, "IsClusterWriter": false }, { "DBInstanceIdentifier": "sample-cluster-instance-01", "DBClusterParameterGroupStatus": "in-sync", "PromotionTier": 1, "IsClusterWriter": false } ], "AvailabilityZones": [ "us-east-1b", "us-east-1c", "us-east-1a" ], "DBClusterParameterGroup": "default.docdb3.6", "Endpoint": "sample-cluster.node.us-east-1.docdb.amazonaws.com", "IAMDatabaseAuthenticationEnabled": false, "AllocatedStorage": 1, "LatestRestorableTime": "2018-08-22T21:57:33.904Z", "PreferredBackupWindow": "00:00-00:30", "StorageEncrypted": false, "MultiAZ": true, "Status": "available", "DBClusterArn": "arn:aws:rds:us-east-1:123456789012:cluster:sample-cluster", "VpcSecurityGroups": [ { "Status": "active", "VpcSecurityGroupId": "sg-12345678" } ], "DbClusterResourceId": "cluster-ABCDEFGHIJKLMNOPQRSTUVWXYZ" } }