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.
Aurora-Replikate
In Multi-AZ-Bereitstellungen erstellt Aurora zusätzliche Aurora-Compute-Instances, die mit der zugrunde liegenden Speicherebene interagieren, die sich über mehrere Availability Zones erstreckt. Diese anderen DB-Instances sind schreibgeschützt und werden als Aurora Replicas bezeichnet. Sie werden auch als Reader-Instances bezeichnet, wenn es darum geht, wie Sie Writer- und Reader-DB-Instances innerhalb eines Clusters kombinieren können. Ein Vorteil von Aurora Replicas besteht darin, dass Sie einen Teil der Arbeit für leseintensive Anwendungen auslagern können, indem Sie die Reader-Instances zur Verarbeitung von SELECT-Abfragen verwenden.
Wenn ein Problem die primäre Instance betrifft, erfolgt ein Failover auf eine dieser sekundären Reader-Instances, die dann die primäre Instanz übernimmt. Aurora erkennt Datenbankprobleme und aktiviert den Failover-Mechanismus bei Bedarf automatisch. Weitere Informationen zum Aurora-Failover finden Sie unter Hochverfügbarkeit für Amazon Aurora.
Aurora Replicas verursachen keine zusätzlichen Kosten in Bezug auf verbrauchten Speicherplatz oder Festplattenschreibvorgänge, da sich alle Instances im Aurora-DB-Cluster das zugrunde liegende Speichervolumen teilen. Der vom Writer generierte und an die Speicherknoten gesendete Log-Stream wird auch an alle Reader-Instances gesendet. In der Reader-Instanz verarbeitet die Datenbank diesen Protokollstream, indem sie jeden Protokolldatensatz nacheinander betrachtet. Wenn der Logeintrag auf eine Seite im Puffercache der Reader-Instanz verweist, verwendet die Reader-Instanz den Log-Applikator, um die angegebene Redo-Operation auf die Seite im Cache anzuwenden. Andernfalls verwirft die Reader-Instanz den Protokolldatensatz.
Beachten Sie, dass Aurora Replicas Protokolldatensätze aus Sicht der Writer-Instance asynchron verarbeiten, die Benutzereingaben unabhängig von den Reader-Instances bestätigt. Aurora Replicas hinken der Writer-Instance in der Regel um ein kurzes Intervall (100 Millisekunden oder weniger) hinterher. Weitere Informationen zur Beziehung zwischen dem Cluster-Volume, der primären DB-Instance und Aurora Replicas in einem Aurora-DB-Cluster finden Sie in der AWS Dokumentation.