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 Durch die *lokale (clusterinterne) Schreibweiterleitung* können Ihre Anwendungen read/write Transaktionen direkt auf einer Aurora Replica ausfü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](aurora-global-database-write-forwarding.md). Die Schreibweiterleitung erfordert Aurora-MySQL-Version 3.04 oder höher. **Topics** + [Aktivieren der lokalen Schreibweiterleitung](aurora-mysql-write-forwarding-enabling.md) + [Überprüfen, ob die Schreibweiterleitung für einen DB-Cluster aktiviert ist](#aurora-mysql-write-forwarding-describing) + [Anwendung und SQL-Kompatibilität mit Schreibweiterleitung](#aurora-mysql-write-forwarding-compatibility) + [Isolationsstufen für die Schreibweiterleitung](#aurora-mysql-write-forwarding-isolation) + [Lesekonsistenz für die Schreibweiterleitung](aurora-mysql-write-forwarding-consistency.md) + [Ausführen von Multipart-Anweisungen mit Schreibweiterleitung](#aurora-mysql-write-forwarding-multipart) + [Transaktionen mit Schreibweiterleitung](#aurora-mysql-write-forwarding-txns) + [Konfigurationsparameter für die Schreibweiterleitung](#aurora-mysql-write-forwarding-params) + [CloudWatch Amazon-Metriken und Aurora MySQL-Statusvariablen für die Schreibweiterleitung](aurora-mysql-write-forwarding-cloudwatch.md) + [Identifizieren weitergeleiteter Transaktionen und Abfragen](#aurora-write-forwarding-processlist) ## Ü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. Auf der AWS-Managementkonsole Registerkarte **Konfiguration** der Detailseite für den Cluster sehen Sie den Status **Aktiviert** für die **lokale Schreibweiterleitung von Lesereplikaten**. Führen Sie den folgenden AWS CLI Befehl aus, um den Status der Einstellung für die Schreibweiterleitung für alle Ihre Cluster zu überprüfen. **Example** ``` 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`, wie`DELETE` und `UPDATE`. 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`- und `SELECT FOR UPDATE`-Anweisungen. + `PREPARE`- und `EXECUTE`-Anweisungen. Bestimmte Anweisungen sind nicht zulässig oder können veraltete Ergebnisse erzeugen, wenn Sie sie in einem DB-Cluster mit Schreibweiterleitung verwenden. Darüber hinaus werden benutzerdefinierte Funktionen und benutzerdefinierte Prozeduren nicht unterstützt. 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 Cluster-Ebene 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 MySQL-Isolierungsstufen](AuroraMySQL.Reference.IsolationLevels.md). ## 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\$1read\$1only](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_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. | Parameter | Scope | Typ | Standardwert | Zulässige Werte | | --- | --- | --- | --- | --- | | aurora\$1fwd\$1writer\$1idle\$1timeout | Cluster | Ganzzahl ohne Vorzeichen | 60 | 1 – 86.400 | | aurora\$1fwd\$1writer\$1max\$1connections\$1pct | Cluster | Lange Ganzzahl ohne Vorzeichen | 10 | 0 – 90 | | aurora\$1replica\$1read\$1consistency | 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 Einstellung `max_connections` für den Writer ausgedrückt. Wenn beispielsweise `max_connections` 800 ist und `aurora_fwd_master_max_connections_pct` oder `aurora_fwd_writer_max_connections_pct` 10 ist, lässt der Writer maximal 80 weitergeleitete Sitzungen gleichzeitig zu. Diese Verbindungen stammen aus demselben, von der Einstellung `max_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](aurora-mysql-write-forwarding-consistency.md). Weitere Informationen zu DB-Parametergruppen finden Sie unter [Parametergruppen für Amazon Aurora](USER_WorkingWithParamGroups.md). ## 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\$1schema.aurora\$1forwarding\$1processlist](AuroraMySQL.Reference.ISTables.md#AuroraMySQL.Reference.ISTables.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) ```