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-Failover
In bestimmten Fällen, z. B. bei bestimmten Arten von geplanten Wartungsarbeiten oder in dem unwahrscheinlichen Fall, dass ein primärer Knoten oder eine Availability Zone ausfällt, erkennt Amazon DocumentDB (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 der Failover funktioniert, muss Ihr Cluster über mindestens zwei Instances verfügen — eine primäre und mindestens eine Replikat-Instance.
Anmerkung
Dieses Thema gilt nur für originale, auf Amazon DocumentDB DocumentDB-Instances basierende Cluster. Es gilt nicht für elastische oder globale Cluster.
Steuerung des Failover-Ziels
Amazon DocumentDB bietet Ihnen Failover-Stufen, mit denen Sie kontrollieren können, welche Replikat-Instance bei einem Failover zur primären Instanz heraufgestuft wird.
Failover-Stufen
Jede Replikat-Instance ist einer Failover-Stufe (0—15) zugeordnet. Wenn aufgrund von Wartungsarbeiten oder eines unwahrscheinlichen Hardwarefehlers ein Failover auftritt, wechselt die primäre Instanz zu einem Replikat mit der höchsten Priorität (der niedrigsten Stufe). Wenn mehrere Replikate dieselbe Prioritätsstufe haben, erfolgt ein Failover der primären Ebene auf das Replikat dieser Stufe, dessen Größe der vorherigen Primärstufe 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 bei einem Failover
Das Failover wird automatisch von Amazon DocumentDB durchgeführt, sodass Ihre Anwendungen den Datenbankbetrieb so schnell wie möglich ohne administrativen Eingriff wieder aufnehmen können.
-
Wenn Sie beim Failover eine Amazon DocumentDB-Replikat-Instance in derselben oder einer anderen Availability Zone haben: Amazon DocumentDB dreht den kanonischen Namenseintrag (CNAME) für Ihre Instance um, sodass er auf das fehlerfreie Replikat verweist, das wiederum zum neuen primären Replikat heraufgestuft wird. Das Failover wird in der Regel innerhalb von 30 Sekunden vom Anfang bis zum Ende abgeschlossen.
-
Wenn Sie keine Amazon DocumentDB-Replikatinstanz haben (z. B. einen einzelnen Instance-Cluster): Amazon DocumentDB versucht, 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
Bei einem Failover für einen Cluster wird eine der Amazon DocumentDB DocumentDB-Repliken (schreibgeschützte Instances) im Cluster zur primären Instance (Cluster-Writer) heraufgestuft.
Wenn die primäre Instance ausfällt, wechselt Amazon DocumentDB automatisch zu einem Amazon DocumentDB DocumentDB-Replikat, falls eines existiert. 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 zur neuen primären Instance gemacht werden soll, sodass Amazon DocumentDB die Instance entsprechend der Priorität der Failover-Tier-Priorität auswählt.
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 dieses Vorgangs sieht etwa wie folgt aus (JSONFormat).
{
"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"
}
}