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.
Konsistenz
Synchrone Schreibvorgänge
Primäre Knoten sind stark konsistent. Erfolgreiche Schreibvorgänge werden dauerhaft im Multi-AZ Transaktionsprotokoll gespeichert, bevor sie an die Clients zurückgegeben werden. Während des normalen Betriebs geben Lesevorgänge für Primärdateien immer die aktuellsten Daten zurück, die die Auswirkungen aller vorherigen erfolgreichen Schreibvorgänge widerspiegeln. Diese starke Konsistenz wird bei allen primären Failovers beibehalten. Replikatknoten sind letztendlich konsistent. Lesevorgänge von Replikaten (mithilfe von READONLY Befehlen) spiegeln möglicherweise nicht immer die Auswirkungen der letzten erfolgreichen Schreibvorgänge wider. Lag-Metriken werden unter veröffentlicht. CloudWatch Die Lesevorgänge eines einzelnen Replikats sind sequenziell konsistent. Erfolgreiche Schreibvorgänge werden für jedes Replikat in derselben Reihenfolge wirksam, in der sie auf dem Primärreplikat ausgeführt wurden.
Asynchrone Schreibvorgänge
Während des normalen Betriebs bieten asynchrone Schreibvorgänge dasselbe Konsistenzverhalten wie synchrone Schreibvorgänge. Da die Schreibvorgänge jedoch an die Clients zurückgegeben werden, bevor sie dauerhaft im Multi-AZ Transaktionsprotokoll gespeichert werden, ist eine starke Konsistenz bei primären Failovers nicht gewährleistet. Im Falle eines Fehlers können bis zu 10 Sekunden an bestätigten Schreibvorgängen verloren gehen, was bedeutet, dass nach einem Failover die Lesevorgänge auf dem neuen Primärserver möglicherweise nicht alle zuvor bestätigten Schreibvorgänge widerspiegeln. Asynchrone Schreibvorgänge werden nicht für Workloads empfohlen, die strenge Konsistenzgarantien erfordern.