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.

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.

aws rds create-db-cluster \
  --db-cluster-identifier write-forwarding-test-cluster \
  --enable-local-write-forwarding \
  --engine aurora-mysql \
  --engine-version 8.0.mysql_aurora.3.04.0 \
  --master-username myuser \
  --master-user-password mypassword \
  --backup-retention 1

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:

Ü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:

Anwendung und SQL-Kompatibilität mit Schreibweiterleitung

Sie können die folgenden Arten von SQL-Anweisungen mit Schreibweiterleitung verwenden:

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'.

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.

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:

Informationen zu den mit der Schreibweiterleitung verbundenen Parametern finden Sie unter Konfigurationsparameter für die Schreibweiterleitung.

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.

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)

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)

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)

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 ändern. Sie können diesen Sitzungswert nur ändern, wenn Sie mit einem DB-Cluster verbunden sind, für den die Schreibweiterleitung aktiviert ist.

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.

Verwenden Sie die folgenden Einstellungen, um eingehende Schreibanforderungen zu steuern:

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.

Die folgenden CloudWatch-Metriken und Aurora-MySQL-Statusvariablen werden auf jeder Reader-DB-Instance in einem DB-Cluster mit aktivierter Schreibweiterleitung gemessen.

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)