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 Meine SQL Isolationsstufen

Erfahren Sie, wie DB-Instances in einem Aurora SQL My-Cluster die Datenbankeigenschaft der Isolation implementieren. In diesem Thema wird erklärt, wie das SQL Standardverhalten von Aurora My ein Gleichgewicht zwischen strikter Konsistenz und hoher Leistung herstellt. Mithilfe dieser Informationen können Sie entscheiden, wann je nach den Eigenschaften Ihres Workloads die Standardeinstellungen geändert werden sollten.

Verfügbare Isolierungsstufen für Writer-Instances

Sie können die IsolationsstufenREPEATABLE READ, READ COMMITTEDREAD UNCOMMITTED, und SERIALIZABLE auf der primären Instance eines Aurora My SQL DB-Clusters verwenden. Diese Isolationsstufen funktionieren in Aurora My SQL genauso wie in RDS MySQL.

REPEATABLEREADIsolationsstufe für Leser-Instanzen

Standardmäßig verwenden Aurora My SQL DB-Instances, die als schreibgeschützte Aurora Replicas konfiguriert sind, immer die REPEATABLE READ Isolationsstufe. Diese DB-Instances ignorieren alle SET TRANSACTION ISOLATION LEVEL-Anweisungen und verwenden weiterhin die Isolierungsstufe REPEATABLE READ.

Sie können die Isolationsstufe für Reader-DB-Instances nicht mithilfe von DB-Parametern oder DB-Cluster-Parametern festlegen.

READCOMMITTEDIsolationsstufe für Reader-Instances

Wenn Ihre Anwendung schreibintensive Workloads auf der primären Instance und lang andauernde Abfragen auf den Aurora-Replicas beinhaltet, kann es zu erheblichen Bereinigungsverzögerungen kommen. Eine Bereinigungsverzögerung tritt auf, wenn die interne Garbage Collection von lang andauernden Abfragen blockiert wird. Das Symptom, das Sie sehen, ist ein hoher Wert für history list length in der Ausgabe des SHOW ENGINE INNODB STATUS-Befehls. Sie können diesen Wert mithilfe der RollbackSegmentHistoryListLength Metrik in überwachen CloudWatch. Eine erhebliche Bereinigungsverzögerung kann die Effektivität sekundärer Indizes reduzieren und zu einer geringeren allgemeinen Abfrageleistung führen sowie Speicherplatz verschwenden.

Wenn Sie auf solche Probleme stoßen, können Sie die Konfigurationseinstellung Aurora My auf SQL Sitzungsebene festlegenaurora_read_replica_read_committed, um die READ COMMITTED Isolationsstufe auf Aurora Replicas zu verwenden. Die Verwendung dieser Einstellung kann Verlangsamungen sowie die Verschwendung von Speicherplatz durch lang andauernde Abfragen reduzieren, während Transaktionen Ihre Tabellen modifizieren.

Wir empfehlen Ihnen, sich mit dem spezifischen SQL Verhalten der READ COMMITTED Isolierung in Aurora My vertraut zu machen, bevor Sie diese Einstellung verwenden. Das READ COMMITTED Verhalten von Aurora Replica entspricht dem ANSI SQL Standard. Die Isolierung ist jedoch weniger streng als das typische SQL READ COMMITTED Verhalten von My, mit dem Sie vielleicht vertraut sind. Daher sehen Sie READ COMMITTED unter einer Aurora My SQL Read Replica möglicherweise andere Abfrageergebnisse als für dieselbe Abfrage READ COMMITTED unter der Aurora My SQL Primary Instance oder unter RDS MySQL. Sie können die aurora_read_replica_read_committed-Einstellung für Anwendungsfälle wie einen umfassenden Bericht über eine sehr große Datenbank verwenden. Für kurze Abfragen mit kleinen Ergebnissätzen, bei denen es auf Präzision und Wiederholbarkeit ankommt, sollten Sie sie eher nicht verwenden.

Die READ COMMITTED-Isolierungsstufe ist nicht für Sitzungen innerhalb eines sekundären Clusters in einer globalen Aurora-Datenbank verfügbar, die die Schreibweiterleitungsfunktion verwenden. Informationen zur Schreibweiterleitung finden Sie unter Verwenden der Schreibweiterleitung in einer Amazon Aurora globalen Datenbank.

READCOMMITTEDFür Leser verwenden

Um die Isolierungsstufe READ COMMITTED für Aurora-Replicas zu aktivieren, setzen Sie die Konfigurationseinstellung aurora_read_replica_read_committed auf ON. Verwenden Sie diese Einstellung auf Sitzungsebene bei Verbindung zu einer spezifischen Aurora-Replica. Führen Sie dazu die folgenden SQL Befehle aus.

set session aurora_read_replica_read_committed = ON;
set session transaction isolation level read committed;

Sie können diese Konfigurationseinstellung temporär verwenden, um interaktive einmalige Abfragen durchzuführen. Sie können auch eine Berichts- oder Datenanalyseanwendung ausführen, die von der Isolierungsstufe READ COMMITTED profitiert, wobei die Standards für andere Anwendungen unverändert bleiben.

Wenn die aurora_read_replica_read_committed-Einstellung aktiviert ist, geben Sie mit dem SET TRANSACTION ISOLATION LEVEL-Befehl die Isolierungsstufe für die jeweiligen Transaktionen an.

set transaction isolation level read committed;

READCOMMITTEDVerhaltensunterschiede auf Aurora-Repliken

Die aurora_read_replica_read_committed-Einstellung stellt die Isolierungsstufe READ COMMITTED für eine Aurora-Replica zur Verfügung, mit einem Konsistenzverhalten, das für lang andauernde Transaktionen optimiert ist. Die Isolierungsstufe READ COMMITTED auf Aurora-Replicas bietet eine weniger strikte Isolierung als auf primären Aurora-Instances. Aktivieren Sie daher diese Einstellung nur auf Aurora-Replicas, wenn Sie wissen, dass für Ihre Abfragen bestimmte Arten inkonsistenter Ergebnisse akzeptabel sind.

Bei Ihren Abfragen können bestimmte Arten von Anomalien auftreten, wenn die aurora_read_replica_read_committed-Einstellung aktiviert ist. Dabei sollten Sie besonders zwei Arten von Anomalien verstehen und in Ihrem Anwendungscode berücksichtigen. Eine nicht-wiederholbarer Lesevorgang tritt auf, wenn eine andere Transaktion ein Commit durchführt, während Ihre Abfrage läuft. Eine lang andauernde Abfrage kann an ihrem Anfang andere Daten sehen als an ihrem Ende. Eine Phantom-Lesevorgang tritt auf, wenn andere Transaktionen dazu führen, dass bestehende Zeilen umorganisiert werden, während Ihre Abfrage läuft, und dass dadurch eine oder mehrere Zeilen von Ihrer Abfrage zweimal gelesen werden.

Phantom-Lesevorgänge können in Ihren Abfragen zu inkonsistenten Zeilenanzahlen führen. Nicht-wiederholbare Lesevorgänge können auch zur Ausgabe unvollständiger oder inkonsistenter Ergebnisse führen. Nehmen wir beispielsweise an, dass sich ein Join-Vorgang auf Tabellen bezieht, die gleichzeitig durch SQL Anweisungen wie INSERT oder geändert werden. DELETE In diesem Fall kann es sein, dass die Join-Abfrage eine Zeile aus einer Tabelle liest, aber nicht die entsprechende Zeile aus einer anderen Tabelle.

Der ANSI SQL Standard erlaubt beide Verhaltensweisen für die READ COMMITTED Isolationsstufe. Diese Verhaltensweisen unterscheiden sich jedoch von der typischen SQL My-Implementierung vonREAD COMMITTED. Bevor Sie die aurora_read_replica_read_committed Einstellung aktivieren, überprüfen Sie daher den vorhandenen SQL Code, um zu überprüfen, ob er nach dem Modell mit geringerer Konsistenz erwartungsgemäß funktioniert.

Zeilenanzahlen und andere Ergebnisse sind auf der Isolationsstufe READ COMMITTED bei Aktivierung dieser Einstellung möglicherweise nicht streng konsistent. Sie sollten diese Einstellung daher typischerweise nur aktivieren, wenn Sie analytische Abfragen ausführen, die große Datenmengen aggregieren und für die keine absolute Präzision erforderlich ist. Wenn Sie nicht solche lang andauernden Abfragen zusammen mit schreibintensiven Workloads verwenden, benötigen Sie die aurora_read_replica_read_committed-Einstellung wahrscheinlich nicht. Ohne die Kombination aus lang andauernden Abfragen und schreibintensiven Workloads sind Probleme mit der Länge der Verlaufsliste unwahrscheinlich.