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 entspricht der Konsistenz von DB-Clustern von Aurora MySQL, 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 mit allen übergebenen Daten aus dem Writer mit Stand zu dem Zeitpunkt, an dem die Abfrage gestartet wurde, aktualisiert ist. Informationen zu den mit der Schreibweiterleitung verbundenen Parametern finden Sie unter [Konfigurationsparameter für die Schreibweiterleitung](aurora-mysql-write-forwarding.md#aurora-mysql-write-forwarding-params). **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](USER_WorkingWithParamGroups.md). **Example 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) ``` **Example 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) ``` **Example 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) ```