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.
Verwendung der lokalen Schreibweiterleitung in einem DB-Cluster von Amazon Aurora MySQL
Lokale (clusterinterne) Schreibweiterleitung ermöglicht Ihren Anwendungen, Lese-/Schreibtransaktionen direkt auf einem Aurora-Replikat durchzuführen. Diese Transaktionen werden dann zum Commit an die Writer-DB-Instance weitergeleitet. Sie können die lokale Schreibweiterleitung verwenden, wenn Ihre Anwendungen Lesen-nach-Schreiben-Konsistenz erfordern. Dies ist die Fähigkeit, den letzten Schreibvorgang in einer Transaktion zu lesen.
Lesereplikate erhalten asynchron Updates vom Writer. Ohne Schreibweiterleitung müssen Sie alle Lesevorgänge, die eine Lesen-nach-Schreiben-Konsistenz erfordern, auf der Writer-DB-Instance abwickeln. Oder Sie müssen eine komplexe benutzerdefinierte Anwendungslogik entwickeln, um aus Gründen der Skalierbarkeit mehrere Lesereplikate nutzen zu können. Ihre Anwendungen müssen den gesamten Lese- und Schreibverkehr vollständig aufteilen und zwei Gruppen von Datenbankverbindungen aufrechterhalten, um den Datenverkehr an den richtigen Endpunkt zu senden. Dieser Entwicklungsaufwand erschwert das Anwendungsdesign, wenn die Abfragen Teil einer einzelnen logischen Sitzung bzw. Transaktion innerhalb der Anwendung sind. Da die Replikationsverzögerung zwischen den Lesereplikaten unterschiedlich sein kann, ist es außerdem schwierig, eine globale Lesekonsistenz für alle Instances in der Datenbank zu erreichen.
Durch die Schreibweiterleitung müssen diese Transaktionen nicht aufgeteilt oder ausschließlich an den Writer gesendet werden, was die Anwendungsentwicklung vereinfacht. Diese neue Funktion macht es einfach, Leseskalierung für Workloads zu erreichen, die den letzten Schreibvorgang in einer Transaktion lesen müssen und nicht empfindlich auf Schreiblatenz reagieren.
Die lokale Schreibweiterleitung unterscheidet sich von der globalen Schreibweiterleitung, bei der Schreibvorgänge von einem sekundären DB-Cluster an den primären DB-Cluster in einer globalen Aurora-Datenbank weitergeleitet werden. Sie können die lokale Schreibweiterleitung in einem DB-Cluster verwenden, der Teil einer globalen Aurora-Datenbank ist. Weitere Informationen finden Sie unter Verwenden der Schreibweiterleitung in einer Amazon Aurora globalen Datenbank.
Die Schreibweiterleitung erfordert Aurora-MySQL-Version 3.04 oder höher.
Themen
- Aktivieren der lokalen Schreibweiterleitung
- Überprüfen, ob die Schreibweiterleitung für einen DB-Cluster aktiviert ist
- Anwendung und SQL-Kompatibilität mit Schreibweiterleitung
- Isolationsstufen für die Schreibweiterleitung
- Lesekonsistenz für die Schreibweiterleitung
- Ausführen von Multipart-Anweisungen mit Schreibweiterleitung
- Transaktionen mit Schreibweiterleitung
- Konfigurationsparameter für die Schreibweiterleitung
- Amazon-CloudWatch-Metriken und Aurora-MySQL-Statusvariablen für die Schreibweiterleitung
- Identifizieren weitergeleiteter Transaktionen und Abfragen
Aktivieren der lokalen Schreibweiterleitung
Standardmäßig ist die lokale Schreibweiterleitung für DB-Cluster von Aurora MySQL nicht aktiviert. Sie aktivieren die lokale Schreibweiterleitung auf Clusterebene, nicht auf Instance-Ebene.
Wichtig
Sie können auch die lokale Schreibweiterleitung für regionsübergreifende Lesereplikate aktivieren, die Binärprotokollierung verwenden. Schreibvorgänge werden jedoch nicht an die Quelle AWS-Region weitergeleitet. Sie werden an die Writer-DB-Instance des Binärprotokoll-Lesereplikats-Clusters weitergeleitet.
Verwenden Sie diese Methode nur, wenn Sie einen Anwendungsfall für das Schreiben in das Binärprotokoll-Lesereplikat in der sekundären AWS-Region haben. Andernfalls könnte es zu einem „Split-Brain“ -Szenario kommen, in dem replizierte Datensätze nicht miteinander konsistent sind.
Es wird empfohlen, die globale Schreibweiterleitung für globale Datenbanken anstelle der lokalen Schreibweiterleitung für regionsübergreifende Lesereplikate zu verwenden, sofern dies nicht unbedingt erforderlich ist. Weitere Informationen finden Sie unter Verwenden der Schreibweiterleitung in einer Amazon Aurora globalen Datenbank.
Wählen Sie in der AWS Management Console das Kontrollkästchen Lokale Schreibweiterleitung aktivieren unter Read-Replica-Schreibweiterleitung aktivieren aus, wenn Sie einen DB-Cluster erstellen oder ändern.
Wenn Sie die Schreibweiterleitung über die AWS CLI aktivieren möchten, verwenden Sie die Option --enable-local-write-forwarding
. Diese Option funktioniert, wenn Sie über den Befehl create-db-cluster
einen neuen DB-Cluster erstellen. Sie funktioniert auch, wenn Sie einen vorhandenen DB-Cluster über den Befehl modify-db-cluster
ändern. Sie können die Schreibweiterleitung deaktivieren, indem Sie die Option --no-enable-local-write-forwarding
mit denselben CLI-Befehlen verwenden.
Im folgenden Beispiel wird ein DB-Cluster von Aurora MySQL mit aktivierter Schreibweiterleitung erstellt.
aws rds create-db-cluster \ --db-cluster-identifier write-forwarding-test-cluster \
--enable-local-write-forwarding
\ --engine aurora-mysql \ --engine-version8.0.mysql_aurora.3.04.0
\ --master-username myuser \ --master-user-password mypassword \ --backup-retention 1
Anschließend erstellen Sie Writer- und Reader-DB-Instances, sodass Sie die Schreibweiterleitung verwenden können. Weitere Informationen finden Sie unter Erstellen eines Amazon Aurora-DB Clusters.
Um die Schreibweiterleitung über die Amazon RDS-API zu aktivieren, legen Sie den Parameter EnableLocalWriteForwarding
auf true
fest. Dieser Parameter funktioniert, wenn Sie über die Operation CreateDBCluster
einen neuen DB-Cluster erstellen. Sie funktioniert auch, wenn Sie einen vorhandenen DB-Cluster über die Operation ModifyDBCluster
ändern. Sie können die Schreibweiterleitung deaktivieren, indem Sie den Parameter EnableLocalWriteForwarding
auf false
festlegen.
Aktivieren der Schreibweiterleitung für Datenbanksitzungen
Der Parameter aurora_replica_read_consistency
ist ein DB-Parameter und ein DB-Cluster-Parameter, der die Schreibweiterleitung ermöglicht. Sie können EVENTUAL
, SESSION
oder GLOBAL
als Lesekonsistenzstufe angeben. Weitere Informationen über Konsistenzebenen finden Sie unter Lesekonsistenz für die Schreibweiterleitung.
Für diesen Parameter gelten die folgenden Regeln:
-
Der Standardwert ist (null).
-
Die Schreibweiterleitung ist nur verfügbar, wenn
aurora_replica_read_consistency
aufEVENTUAL
,SESSION
oderGLOBAL
festgelegt ist. Dieser Parameter ist nur in Reader-Instances von DB-Clustern relevant, für die Schreibweiterleitung aktiviert ist. -
Sie können diesen Parameter (wenn leer) nicht innerhalb einer Multistatement-Transaktion festlegen oder die Einstellung (wenn er bereits eingestellt ist) nicht aufheben. Sie können ihn während einer solchen Transaktion von einem gültigen Wert in einen anderen gültigen Wert ändern. Diese Aktion wird jedoch nicht empfohlen.
Überprüfen, ob die Schreibweiterleitung für einen DB-Cluster aktiviert ist
Wenn Sie feststellen möchten, ob Sie die Schreibweiterleitung in einem DB-Cluster verwenden können, stellen Sie sicher, dass das Attribut LocalWriteForwardingStatus
für den Cluster auf enabled
eingestellt ist.
In der AWS Management Console sehen Sie auf der Registerkarte Konfiguration der Detailseite des Clusters den StatusAktiviert für Lokale Lesereplikat-Schreibweiterleitung.
Um den Status der Einstellung für die Schreibweiterleitung für alle Cluster anzuzeigen, führen Sie den folgenden AWS CLI-Befehl aus.
aws rds describe-db-clusters \ --query '*[].{DBClusterIdentifier:DBClusterIdentifier,LocalWriteForwardingStatus:LocalWriteForwardingStatus}' [ { "LocalWriteForwardingStatus": "enabled", "DBClusterIdentifier": "write-forwarding-test-cluster-1" }, { "LocalWriteForwardingStatus": "disabled", "DBClusterIdentifier": "write-forwarding-test-cluster-2" }, { "LocalWriteForwardingStatus": "requested", "DBClusterIdentifier": "test-global-cluster-2" }, { "LocalWriteForwardingStatus": "null", "DBClusterIdentifier": "aurora-mysql-v2-cluster" } ]
Für einen DB-Cluster sind folgende Werte LocalWriteForwardingStatus
zulässig:
-
disabled
– Die Schreibweiterleitung ist deaktiviert. -
disabling
– Die Schreibweiterleitung wird gerade deaktiviert. -
enabled
– Die Schreibweiterleitung ist aktiviert. -
enabling
– Die Schreibweiterleitung wird gerade aktiviert. -
null
– Die Schreibweiterleitung ist für diesen DB-Cluster nicht verfügbar. -
requested
– Die Schreibweiterleitung wurde angefordert, ist aber noch nicht aktiv.
Anwendung und SQL-Kompatibilität mit Schreibweiterleitung
Sie können die folgenden Arten von SQL-Anweisungen mit Schreibweiterleitung verwenden:
-
Data Manipulation Language (DM)-Anweisungen wie
INSERT
, wieDELETE
undUPDATE
. Es gibt einige Einschränkungen für die Eigenschaften dieser Anweisungen, die Sie bei der Schreibweiterleitung verwenden können, wie im Folgenden beschrieben. -
SELECT ... LOCK IN SHARE MODE
- undSELECT FOR UPDATE
-Anweisungen. -
PREPARE
- undEXECUTE
-Anweisungen.
Bestimmte Anweisungen sind nicht zulässig oder können veraltete Ergebnisse erzeugen, wenn Sie sie in einem DB-Cluster mit Schreibweiterleitung verwenden. Somit ist die die Einstellung EnableLocalWriteForwarding
für DB-Cluster standardmäßig deaktiviert. Stellen Sie vor der Aktivierung sicher, dass der Anwendungscode von keiner dieser Einschränkungen betroffen ist.
Die folgenden Einschränkungen gelten für die SQL-Anweisungen, die Sie für die Schreibweiterleitung verwenden. In einigen Fällen können Sie die Anweisungen in DB-Clustern verwenden, bei denen eine Schreibweiterleitung auf Clusterebene aktiviert ist. Dieser Ansatz funktioniert, wenn die Schreibweiterleitung nicht innerhalb der Sitzung durch den Konfigurationsparameter aurora_replica_read_consistency
aktiviert wird. Wenn Sie versuchen, eine Anweisung zu verwenden, obwohl diese aufgrund der Schreibweiterleitung nicht zulässig ist, wird eine Fehlermeldung ähnlich wie die folgende ausgegeben:
ERROR 1235 (42000): This version of MySQL doesn't yet support '
operation
with write forwarding'.
- Data Definition Language (DDL)
-
Stellen Sie eine Verbindung mit der Writer-DB-Instance her, um DDL-Anweisungen auszuführen. Sie können sie nicht von Reader-DB-Instances aus ausführen.
- Aktualisieren einer permanenten Tabelle mit Daten aus einer temporären Tabelle
-
Sie können in DB-Clustern mit aktivierter Schreibweiterleitung temporäre Tabellen verwenden. Sie können jedoch keine DML-Anweisung verwenden, um eine permanente Tabelle zu ändern, wenn sich die Anweisung auf eine temporäre Tabelle bezieht. Beispielsweise können Sie keine
INSERT ... SELECT
-Anweisung verwenden, die die Daten aus einer temporären Tabelle übernimmt. - XA-Transaktionen
-
Sie können die folgenden Anweisungen nicht in einem DB-Cluster verwenden, wenn die Schreibweiterleitung innerhalb der Sitzung aktiviert wird. Sie können diese Anweisungen in DB-Clustern verwenden, bei denen die Schreibweiterleitung nicht aktiviert ist, oder innerhalb von Sitzungen mit leerer Einstellung
aurora_replica_read_consistency
. Bevor Sie die Schreibweiterleitung innerhalb einer Sitzung aktivieren, müssen Sie überprüfen, ob Ihr Code diese Anweisungen verwendet.XA {START|BEGIN} xid [JOIN|RESUME] XA END xid [SUSPEND [FOR MIGRATE]] XA PREPARE xid XA COMMIT xid [ONE PHASE] XA ROLLBACK xid XA RECOVER [CONVERT XID]
- LOAD-Anweisungen für permanente Tabellen
-
Sie können die folgenden Anweisungen nicht in einem DB-Cluster mit aktivierter Schreibweiterleitung verwenden.
LOAD DATA INFILE 'data.txt' INTO TABLE t1; LOAD XML LOCAL INFILE 'test.xml' INTO TABLE t1;
- Plugin-Anweisungen
-
Sie können die folgenden Anweisungen nicht in einem DB-Cluster mit aktivierter Schreibweiterleitung verwenden.
INSTALL PLUGIN example SONAME 'ha_example.so'; UNINSTALL PLUGIN example;
- SAVEPOINT-Anweisungen
-
Sie können die folgenden Anweisungen nicht in einem DB-Cluster verwenden, wenn die Schreibweiterleitung innerhalb der Sitzung aktiviert wird. Sie können diese Anweisungen in DB-Clustern ohne aktivierte Schreibweiterleitung oder in Sitzungen mit leerer Einstellung
aurora_replica_read_consistency
verwenden. Überprüfen Sie, ob Ihr Code diese Anweisungen verwendet, bevor Sie die Schreibweiterleitung innerhalb einer Sitzung aktivieren.SAVEPOINT t1_save; ROLLBACK TO SAVEPOINT t1_save; RELEASE SAVEPOINT t1_save;
Isolationsstufen für die Schreibweiterleitung
In Sitzungen, die Schreibweiterleitung verwenden, können Sie nur die Isolationsstufe REPEATABLE READ
verwenden. Obwohl Sie die Isolationsstufe READ COMMITTED
auch mit Aurora Replicas verwenden können, funktioniert diese Isolationsstufe nicht mit Schreibweiterleitung. Weitere Informationen zu den Isolationsstufen REPEATABLE READ
und READ COMMITTED
finden Sie unter Aurora Meine SQL Isolationsstufen.
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.
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)
Ausführen von Multipart-Anweisungen mit Schreibweiterleitung
Eine DML-Anweisung kann aus mehreren Teilen bestehen, z. B. einer INSERT ... SELECT
-Anweisung oder einer DELETE ...
WHERE
-Anweisung. In diesem Fall wird die gesamte Anweisung an die Writer-DB-Instance weitergeleitet und dort ausgeführt.
Transaktionen mit Schreibweiterleitung
Wenn der Transaktionszugriffsmodus schreibgeschützt ist, wird die Schreibweiterleitung nicht verwendet. Sie können den Zugriffsmodus für die Transaktion durch Verwendung der Anweisungen SET TRANSACTION
oder START TRANSACTION
angeben. Sie können den Transaktionszugriffsmodus auch angeben, indem Sie den Wert der Sitzungsvariablen transaction_read_only
Wenn eine Transaktion mit langer Laufzeit für einen beträchtlichen Zeitraum keine Anweisung ausgibt, kann sie Leerlaufzeitüberschreitung überschreiten. Dieser Zeitraum hat einen Standardwert von einer Minute. Sie können den Parameter aurora_fwd_writer_idle_timeout
festlegen, um den Wert um bis zu einem Tag zu erhöhen. Eine Transaktion, die die Leerlaufzeitüberschreitung überschreitet, wird von der Writer-Instance abgebrochen. Die nächste nachfolgende Anweisung, die Sie übermitteln, empfängt einen Zeitüberschreitungsfehler. In diesem Fall rollt Aurora die Transaktion zurück.
Diese Art von Fehler kann in anderen Fällen auftreten, wenn die Schreibweiterleitung nicht mehr verfügbar ist. Beispielsweise bricht Aurora alle Transaktionen ab, die die Schreibweiterleitung verwenden, wenn Sie den DB-Cluster neu starten oder die Schreibweiterleitung deaktivieren.
Wenn eine Writer-Instance in einem Cluster, der die lokale Schreibweiterleitung verwendet, neu gestartet wird, werden alle aktiven, weitergeleiteten Transaktionen und Abfragen auf Reader-Instances, die die lokale Schreibweiterleitung verwenden, automatisch geschlossen. Nachdem die Writer-Instance wieder verfügbar ist, können Sie diese Transaktionen erneut versuchen.
Konfigurationsparameter für die Schreibweiterleitung
Die Aurora-DB-Parametergruppen enthalten Einstellungen für die Schreibweiterleitung. Details zu diesen Parametern sind in der folgenden Tabelle zusammengefasst, mit Nutzungshinweisen unterhalb der Tabelle.
Parameter | Scope | Typ | Standardwert | Zulässige Werte |
---|---|---|---|---|
aurora_fwd_writer_idle_timeout |
Cluster | Ganzzahl ohne Vorzeichen | 60 | 1 – 86.400 |
aurora_fwd_writer_max_connections_pct |
Cluster | Lange Ganzzahl ohne Vorzeichen | 10 | 0 – 90 |
aurora_replica_read_consistency |
Cluster oder Instances | Enum | '' (null) | EVENTUAL , SESSION , GLOBAL |
Verwenden Sie die folgenden Einstellungen, um eingehende Schreibanforderungen zu steuern:
-
aurora_fwd_writer_idle_timeout
– Die Anzahl der Sekunden, die die Writer-DB-Instance auf Aktivitäten bei einer Verbindung wartet, die von einer Reader-Instance weitergeleitet werden, bevor sie geschlossen wird. Wenn die Sitzung über diesen Zeitraum hinaus im Leerlauf ist, bricht Aurora die Sitzung ab. -
aurora_fwd_writer_max_connections_pct
– Die obere Grenze für Datenbankverbindungen, die in einer Writer-DB-Instance für die Verarbeitung von Abfragen verwendet werden können, die von Reader-Instances weitergeleitet werden. Sie wird als Prozentsatz der Einstellungmax_connections
für den Writer ausgedrückt. Wenn beispielsweisemax_connections
800 ist undaurora_fwd_master_max_connections_pct
oderaurora_fwd_writer_max_connections_pct
10 ist, lässt der Writer maximal 80 weitergeleitete Sitzungen gleichzeitig zu. Diese Verbindungen stammen aus demselben, von der Einstellungmax_connections
verwalteten Verbindungspool.Diese Einstellung gilt nur für den Writer, wenn dessen Schreibweiterleitung aktiviert ist. Wenn Sie den Wert verringern, sind vorhandene Verbindungen nicht betroffen. Aurora berücksichtigt den neuen Wert der Einstellung, wenn versucht wird, eine neue Verbindung von einem DB-Cluster aus zu erstellen. Der Standardwert ist 10, was 10 % des Werts für
max_connections
entspricht.
Anmerkung
Da es sich bei aurora_fwd_writer_idle_timeout
und aurora_fwd_writer_max_connections_pct
um Cluster-Parameter handelt, haben alle DB-Instances in allen Clustern die gleichen Werte für diese Parameter.
Mehr über aurora_replica_read_consistency
erfahren Sie unter Lesekonsistenz für die Schreibweiterleitung.
Weitere Informationen zu DB-Parametergruppen finden Sie unter Parametergruppen für Amazon Aurora.
Amazon-CloudWatch-Metriken und Aurora-MySQL-Statusvariablen für die Schreibweiterleitung
Die folgenden Amazon-CloudWatch-Metriken und Aurora-MySQL-Statusvariablen gelten, wenn Sie die Schreibweiterleitung in einem oder mehreren DB-Clustern verwenden. Diese Metriken und Statusvariablen werden alle auf der Writer-DB-Instance gemessen.
CloudWatch-Metrik | Aurora-MySQL-Statusvariable | Einheit | Beschreibung |
---|---|---|---|
|
– | Millisekunden |
Durchschnittliche Zeit für die Verarbeitung jeder weitergeleiteten DML-Anweisung auf der Writer-DB-Instance. Nicht enthalten ist die Zeit, die der DB-Cluster benötigt, um die Schreibanforderung weiterzuleiten, oder die Zeit, um Änderungen zurück an den Writer zu replizieren. |
|
– | Anzahl pro Sekunde | Anzahl der weitergeleiteten DML-Anweisungen, die pro Sekunde von dieser Writer-DB-Instance verarbeitet werden. |
|
Aurora_fwd_writer_open_sessions |
Anzahl | Anzahl der weitergeleiteten Sitzungen auf der Writer-DB-Instance. |
– |
Aurora_fwd_writer_dml_stmt_count |
Anzahl | Gesamtzahl der DML-Anweisungen, die an diese Writer-DB-Instance weitergeleitet werden. |
– |
Aurora_fwd_writer_dml_stmt_duration |
Mikrosekunden | Gesamtdauer der DML-Anweisungen, die an diese Writer-DB-Instance weitergeleitet werden. |
– |
Aurora_fwd_writer_select_stmt_count |
Anzahl | Gesamtzahl der SELECT -Anweisungen, die an diese Writer-DB-Instance weitergeleitet werden. |
– |
Aurora_fwd_writer_select_stmt_duration |
Mikrosekunden | Gesamtdauer der SELECT -Anweisungen, die an diese Writer-DB-Instance weitergeleitet werden. |
Die folgenden CloudWatch-Metriken und Aurora-MySQL-Statusvariablen werden auf jeder Reader-DB-Instance in einem DB-Cluster mit aktivierter Schreibweiterleitung gemessen.
CloudWatch-Metrik | Aurora-MySQL-Statusvariable | Einheit | Beschreibung |
---|---|---|---|
|
– | Millisekunden | Durchschnittliche Reaktionszeit weitergeleiteter DML-Anweisungen auf Replikaten. |
|
– | Anzahl pro Sekunde | Anzahl der weitergeleiteten DML-Anweisungen, die pro Sekunde verarbeitet werden. |
|
Aurora_fwd_replica_open_sessions |
Anzahl | Die Anzahl der Sitzungen, die die Schreibweiterleitung für eine Reader-DB-Instance verwenden. |
|
– | Millisekunden |
Durchschnittliche Wartezeit, die eine Der Grad, in dem die Reader-DB-Instance vor der Verarbeitung einer Abfrage wartet, ist von der Einstellung |
|
– | Anzahl pro Sekunde | Gesamtzahl der pro Sekunde in allen Sitzungen verarbeiteten SELECT -Anweisungen, die Schreibvorgänge weiterleiten. |
|
– | Millisekunden | Weitergeleitete SELECT -Latenz, als Durchschnitt über alle weitergeleiteten SELECT -Anweisungen innerhalb des Überwachungszeitraums. |
|
– | Anzahl pro Sekunde | Weitergeleiteter SELECT -Durchsatz, pro Sekunde, als Durchschnitt innerhalb des Überwachungszeitraums. |
– |
Aurora_fwd_replica_dml_stmt_count |
Anzahl | Gesamtzahl der DML-Anweisungen, die aus dieser Reader-DB-Instance weitergeleitet werden. |
– |
Aurora_fwd_replica_dml_stmt_duration |
Mikrosekunden | Gesamtdauer aller DML-Anweisungen, die aus dieser Reader-DB-Instance weitergeleitet werden. |
– |
Aurora_fwd_replica_errors_session_limit |
Anzahl |
Anzahl der Sitzungen, die vom primären Cluster aufgrund einer der folgenden Fehlerbedingungen zurückgewiesen wurden:
|
– |
Aurora_fwd_replica_read_wait_count |
Anzahl | Gesamtzahl der Lesen-Nach-Schreiben-Wartezeiten auf dieser Reader-DB-Instance. |
– |
Aurora_fwd_replica_read_wait_duration |
Mikrosekunden | Gesamtdauer der Wartezeiten aufgrund der Lesekonsistenzeinstellung auf dieser Reader-DB-Instance. |
– |
Aurora_fwd_replica_select_stmt_count |
Anzahl | Gesamtzahl der SELECT -Anweisungen, die aus dieser Reader-DB-Instance weitergeleitet werden. |
– |
Aurora_fwd_replica_select_stmt_duration |
Mikrosekunden | Gesamtdauer der SELECT -Anweisungen, die aus dieser Reader-DB-Instance weitergeleitet werden. |
Identifizieren weitergeleiteter Transaktionen und Abfragen
Sie können die Tabelle information_schema.aurora_forwarding_processlist
zur Identifizierung weitergeleiteter Transaktionen und Abfragen verwenden. Weitere Informationen zu dieser Tabelle finden Sie unter information_schema.aurora_forwarding_processlist.
Das folgende Beispiel zeigt alle weitergeleiteten Verbindungen auf einer Writer-DB-Instance.
mysql> select * from information_schema.AURORA_FORWARDING_PROCESSLIST where IS_FORWARDED=1 order by REPLICA_SESSION_ID; +-----+----------+--------------------+----------+---------+------+--------------+--------------------------------------------+--------------+--------------------+---------------------------------+----------------------+----------------+ | ID | USER | HOST | DB | COMMAND | TIME | STATE | INFO | IS_FORWARDED | REPLICA_SESSION_ID | REPLICA_INSTANCE_IDENTIFIER | REPLICA_CLUSTER_NAME | REPLICA_REGION | +-----+----------+--------------------+----------+---------+------+--------------+--------------------------------------------+--------------+--------------------+---------------------------------+---------------------------------------+ | 648 | myuser |
IP_address:port1
| sysbench | Query | 0 | async commit | UPDATE sbtest58 SET k=k+1 WHERE id=4802579 | 1 | 637 | my-db-cluster-instance-2 | my-db-cluster | us-west-2 | | 650 | myuser |IP_address:port2
| sysbench | Query | 0 | async commit | UPDATE sbtest54 SET k=k+1 WHERE id=2503953 | 1 | 639 | my-db-cluster-instance-2 | my-db-cluster | us-west-2 | +-----+----------+--------------------+----------+---------+------+--------------+--------------------------------------------+--------------+--------------------+---------------------------------+----------------------+----------------+
Auf der weiterleitenden Reader-DB-Instance können Sie die Threads sehen, die diesen Writer-DB-Verbindungen zugeordnet sind, indem Sie SHOW PROCESSLIST
ausführen. Die REPLICA_SESSION_ID
-Werte auf dem Writer, 637 und 639, sind dieselben wie die Id
-Werte auf dem Reader.
mysql> select @@aurora_server_id; +---------------------------------+ | @@aurora_server_id | +---------------------------------+ | my-db-cluster-instance-2 | +---------------------------------+ 1 row in set (0.00 sec) mysql> show processlist; +-----+----------+--------------------+----------+---------+------+--------------+---------------------------------------------+ | Id | User | Host | db | Command | Time | State | Info | +-----+----------+--------------------+----------+---------+------+--------------+---------------------------------------------+ | 637 | myuser |
IP_address:port1
| sysbench | Query | 0 | async commit | UPDATE sbtest12 SET k=k+1 WHERE id=4802579 | | 639 | myuser |IP_address:port2
| sysbench | Query | 0 | async commit | UPDATE sbtest61 SET k=k+1 WHERE id=2503953 | +-----+----------+--------------------+----------+---------+------+--------------+---------------------------------------------+ 12 rows in set (0.00 sec)