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.
Lesekonsistenz für die Schreibweiterleitung
Sie können den Grad der Lesekonsistenz in einem DB-Cluster steuern. Die Lesekonsistenzstufe legt fest, wie lange der DB-Cluster vor jeder Leseoperation wartet, um sicherzustellen, dass einige oder alle Änderungen aus dem Writer repliziert werden. Sie können die Lesekonsistenzstufe anpassen, um sicherzustellen, dass alle aus Ihrer Sitzung weitergeleiteten Schreiboperationen im DB-Cluster vor nachfolgenden Abfragen angezeigt werden. Sie können diese Einstellung auch verwenden, um sicherzustellen, dass Abfragen auf dem DB-Cluster stets die aktuellsten Updates des Writers angezeigt werden. Diese Einstellung gilt auch für Abfragen, die von anderen Sitzungen oder Clustern gesendet werden. Um diese Art von Verhalten für Ihre Anwendung anzugeben, wählen Sie einen Wert für den DB-Parameter aurora_replica_read_consistency oder den DB-Cluster-Parameter aus.
Wichtig
Stellen Sie den DB-Parameter aurora_replica_read_consistency oder den DB-Cluster-Parameter immer ein, wenn Sie Schreibvorgänge weiterleiten möchten. Andernfalls leitet Aurora keine Schreibvorgänge weiter. Dieser Parameter hat standardmäßig einen leeren Wert, wählen Sie daher einen bestimmten Wert, wenn Sie diesen Parameter verwenden. Der Parameter aurora_replica_read_consistency wirkt sich nur auf DB-Cluster oder Instances aus, für die die Schreibweiterleitung aktiviert ist.
Wenn Sie die Konsistenzstufe erhöhen, verbringt Ihre Anwendung mehr Zeit mit dem Warten auf die Propagierung von Änderungen zwischen DB-Instances. Sie können das Verhältnis zwischen schneller Reaktionszeit und der Gewährleistung festlegen, dass vor der Ausführung Ihrer Abfragen Änderungen auf anderen DB-Instances vollständig verfügbar sind.
Sie können die folgenden Werte für den Parameter aurora_replica_read_consistency angeben:
-
EVENTUAL– Ergebnisse von Schreibvorgängen in derselben Sitzung sind erst sichtbar, wenn der Schreibvorgang auf der Writer-DB-Instance ausgeführt wird. Die Abfrage wartet nicht, bis die aktualisierten Ergebnisse verfügbar sind. Daher könnte sie die älteren Daten oder die aktualisierten Daten abrufen, abhängig vom Zeitpunkt der Anweisungen und der Größe der Replikationsverzögerung. Dies ist dieselbe Konsistenz wie bei Aurora My SQL DB-Clustern, die keine Schreibweiterleitung verwenden. -
SESSION– Allen Abfragen, die die Schreibweiterleitung verwenden, werden die Ergebnisse sämtlicher in dieser Sitzung vorgenommenen Änderungen angezeigt. Die Änderungen werden unabhängig davon angezeigt, ob die Transaktion übergeben wurde. Wenn notwendig, wartet die Abfrage auf die Replikation der Ergebnisse weitergeleiteter Schreibvorgänge. -
GLOBAL– In einer Sitzung werden alle übernommenen Änderungen in allen Sitzungen und Instances im DB-Cluster angezeigt. Jede Abfrage kann für einen bestimmten Zeitraum warten, abhängig von der Sitzungsverzögerung. Die Abfrage wird fortgesetzt, wenn der DB-Cluster zu up-to-date dem Zeitpunkt, zu dem die Abfrage gestartet wurde, alle zugeschriebenen Daten vom Writer enthält.
Informationen zu den mit der Schreibweiterleitung verbundenen Parametern finden Sie unter Konfigurationsparameter für die Schreibweiterleitung.
Anmerkung
Sie können auch aurora_replica_read_consistency als Sitzungsvariable verwenden, zum Beispiel:
mysql> set aurora_replica_read_consistency = 'session';
Beispiele für die Verwendung der Schreibweiterleitung
Die folgenden Beispiele zeigen die Auswirkungen des Parameters aurora_replica_read_consistency auf laufende INSERT-Anweisungen, gefolgt von SELECT-Anweisungen. Abhängig vom Wert der Einstellung aurora_replica_read_consistency und vom Zeitpunkt der Anweisungen können sich die Ergebnisse unterscheiden.
Um eine höhere Konsistenz zu erreichen, können Sie kurz warten, bevor Sie die Anweisung SELECT ausführen. Oder Aurora kann automatisch warten, bis die Ergebnisse fertig repliziert sind, bevor mit fortgefahren wir SELECT.
Informationen zum Einstellen von DB-Parametern finden Sie unter Parametergruppen für Amazon Aurora.
Beispiel mit der Einstellung von aurora_replica_read_consistency auf EVENTUAL
Durch Ausführen einer INSERT-Anweisung, auf die unmittelbar eine SELECT-Anweisung folgt, wird ein Wert für COUNT(*) mit der Anzahl der Zeilen zurückgegeben, bevor die neue Zeile eingefügt wird. Wenn Sie kurze Zeit später SELECT erneut ausführen, wird die aktualisierte Zeilenzahl zurückgegeben. Die SELECT-Anweisungen haben keine Wartezeit.
mysql> select count(*) from t1; +----------+ | count(*) | +----------+ | 5 | +----------+ 1 row in set (0.00 sec) mysql> insert into t1 values (6); select count(*) from t1; +----------+ | count(*) | +----------+ | 5 | +----------+ 1 row in set (0.00 sec) mysql> select count(*) from t1; +----------+ | count(*) | +----------+ | 6 | +----------+ 1 row in set (0.00 sec)
Beispiel mit der Einstellung von aurora_replica_read_consistency auf SESSION
Eine SELECT-Anweisung wartet unmittelbar nach einer INSERT-Anweisung, bis die Änderungen aus der INSERT-Anweisung sichtbar sind. Nachfolgende SELECT-Anweisungen haben keine Wartezeit.
mysql> select count(*) from t1; +----------+ | count(*) | +----------+ | 6 | +----------+ 1 row in set (0.01 sec) mysql> insert into t1 values (6); select count(*) from t1; select count(*) from t1; Query OK, 1 row affected (0.08 sec) +----------+ | count(*) | +----------+ | 7 | +----------+ 1 row in set (0.37 sec) +----------+ | count(*) | +----------+ | 7 | +----------+ 1 row in set (0.00 sec)
Wenn die Lesekonsistenzeinstellung weiter auf SESSION festgelegt ist, wird durch die Einführung einer kurzen Wartezeit nach der Ausführung einer INSERT-Anweisung die aktualisierte Zeilenzahl zum Zeitpunkt der nächsten Ausführung der SELECT-Anweisung verfügbar.
mysql> insert into t1 values (6); select sleep(2); select count(*) from t1; Query OK, 1 row affected (0.07 sec) +----------+ | sleep(2) | +----------+ | 0 | +----------+ 1 row in set (2.01 sec) +----------+ | count(*) | +----------+ | 8 | +----------+ 1 row in set (0.00 sec)
Beispiel mit der Einstellung von aurora_replica_read_consistency auf GLOBAL
Jede SELECT-Anweisung wartet, um sicherzustellen, dass alle Datenänderungen mit Stand zur Startzeit der Anweisung angezeigt werden, bevor die Abfrage ausgeführt wird. Die Wartezeit für jede SELECT-Anweisung variiert je nach Dauer der Replikationsverzögerung.
mysql> select count(*) from t1; +----------+ | count(*) | +----------+ | 8 | +----------+ 1 row in set (0.75 sec) mysql> select count(*) from t1; +----------+ | count(*) | +----------+ | 8 | +----------+ 1 row in set (0.37 sec) mysql> select count(*) from t1; +----------+ | count(*) | +----------+ | 8 | +----------+ 1 row in set (0.66 sec)
