Verwenden der lokalen Schreibweiterleitung in einem Amazon Aurora My SQL DB-Cluster

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 read-after-write Konsistenz erfordern, d. h. 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 read-after-write Konsistenz erfordern, auf der Writer-DB-Instance durchführen. 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.

Für die lokale Schreibweiterleitung ist Aurora My SQL Version 3.04 oder höher erforderlich.

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

Im AWS Management Console, auf der Registerkarte Konfiguration der Detailseite für den Cluster sehen Sie den Status Aktiviert für lokale Read Replica-Schreibweiterleitung.

Führen Sie den folgenden Befehl aus, um den Status der Einstellung für die Schreibweiterleitung für alle Ihre Cluster zu überprüfen AWS CLI Befehl.

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 der Schreibweiterleitung

Bei der Schreibweiterleitung können Sie die folgenden Arten von SQL Anweisungen 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 bei der 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.

Ausführen von Multipart-Anweisungen mit Schreibweiterleitung

Eine DML Aussage kann aus mehreren Teilen bestehen, z. B. aus einer INSERT ... SELECT Aussage oder einer DELETE ... WHERE Aussage. 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.

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)