Verwendung der Schreibweiterleitung in einer SQL globalen Aurora My-Datenbank

Region und Versionsverfügbarkeit der Schreibweiterleitung in Aurora My SQL

Die Schreibweiterleitung wird mit Aurora My SQL 2.08.1 und höheren Versionen in jeder Region unterstützt, in der globale Datenbanken SQL auf Basis von Aurora My verfügbar sind.

Informationen zur Version und regionalen Verfügbarkeit der SQL globalen Aurora My-Datenbanken finden Sie unterGlobale Aurora-Datenbanken mit Aurora My SQL.

Schreibweiterleitung in Aurora My aktivieren SQL

Standardmäßig ist die Schreibweiterleitung nicht aktiviert, wenn Sie einen sekundären Cluster zu einer Aurora Global Database hinzufügen.

Um die Schreibweiterleitung mithilfe von zu aktivieren AWS Management Console, aktivieren Sie das Kontrollkästchen Globale Schreibweiterleitung aktivieren unter Read Replica Write Forwarding, wenn Sie eine Region für eine globale Datenbank hinzufügen. Ändern Sie den Cluster für einen vorhandenen sekundären Cluster in Globale Schreibweiterleitung aktivieren. Wenn Sie die Schreibweiterleitung ausschalten möchten, deaktivieren Sie beim Hinzufügen der Region oder beim Ändern des sekundären Clusters das Kontrollkästchen Read-Replica-Schreibweiterleitung aktivieren.

Um die Schreibweiterleitung mit dem zu aktivieren AWS CLI, verwenden Sie die --enable-global-write-forwarding Option. Diese Option funktioniert, wenn Sie über den Befehl create-db-cluster einen neuen sekundären Cluster erstellen. Sie funktioniert auch, wenn Sie einen vorhandenen sekundären Cluster über den Befehl modify-db-cluster ändern. Sie erfordert, dass die globale Datenbank eine Aurora-Version verwendet, die eine Schreibweiterleitung unterstützt. Sie können die Schreibweiterleitung deaktivieren, indem Sie die --no-enable-global-write-forwarding Option mit denselben CLI Befehlen verwenden.

Um die Schreibweiterleitung über Amazon zu aktivieren RDSAPI, setzen Sie den EnableGlobalWriteForwarding Parameter auftrue. Dieser Parameter funktioniert, wenn Sie über die Operation CreateDBCluster einen neuen sekundären Cluster erstellen. Sie funktioniert auch, wenn Sie einen vorhandenen sekundären Cluster über die Operation ModifyDBCluster ändern. Sie erfordert, dass die globale Datenbank eine Aurora-Version verwendet, die eine Schreibweiterleitung unterstützt. Sie können die Schreibweiterleitung deaktivieren, indem Sie den Parameter EnableGlobalWriteForwarding auf false festlegen.

Die folgenden CLI Beispiele zeigen, wie Sie eine globale Aurora-Datenbank mit aktivierter oder deaktivierter Schreibweiterleitung einrichten können. Die markierten Elemente stellen die Befehle und Optionen dar, die bei der Einrichtung der Infrastruktur für eine Aurora Global Database Datenbank angegeben werden müssen und konsistent sein müssen.

Im folgenden Beispiel werden eine Aurora Global Database, ein primärer Cluster und ein sekundärer Cluster mit aktivierter Schreibweiterleitung erstellt. Geben Sie Ihre eigenen Daten für Benutzername, Passwort und primäre und sekundäre AWS -Regionen ein.

# Create overall global database.
aws rds create-global-cluster --global-cluster-identifier write-forwarding-test \
  --engine aurora-mysql --engine-version 5.7.mysql_aurora.2.11.1 \
  --region us-east-1

# Create primary cluster, in the same AWS Region as the global database.
aws rds create-db-cluster --global-cluster-identifier write-forwarding-test \
  --db-cluster-identifier write-forwarding-test-cluster-1 \
  --engine aurora-mysql --engine-version 5.7.mysql_aurora.2.11.1 \
  --master-username user_name --master-user-password password \
  --region us-east-1

aws rds create-db-instance --db-cluster-identifier write-forwarding-test-cluster-1 \
  --db-instance-identifier write-forwarding-test-cluster-1-instance-1 \
  --db-instance-class db.r5.large \
  --engine aurora-mysql --engine-version 5.7.mysql_aurora.2.11.1 \
  --region us-east-1

aws rds create-db-instance --db-cluster-identifier write-forwarding-test-cluster-1 \
  --db-instance-identifier write-forwarding-test-cluster-1-instance-2 \
  --db-instance-class db.r5.large \
  --engine aurora-mysql --engine-version 5.7.mysql_aurora.2.11.1 \
  --region us-east-1

# Create secondary cluster, in a different AWS Region than the global database,
# with write forwarding enabled.
aws rds create-db-cluster --global-cluster-identifier write-forwarding-test \
  --db-cluster-identifier write-forwarding-test-cluster-2 \
  --engine aurora-mysql --engine-version 5.7.mysql_aurora.2.11.1 \
  --region us-east-2 \
  --enable-global-write-forwarding

aws rds create-db-instance --db-cluster-identifier write-forwarding-test-cluster-2 \
  --db-instance-identifier write-forwarding-test-cluster-2-instance-1 \
  --db-instance-class db.r5.large \
  --engine aurora-mysql --engine-version 5.7.mysql_aurora.2.11.1 \
  --region us-east-2

aws rds create-db-instance --db-cluster-identifier write-forwarding-test-cluster-2 \
  --db-instance-identifier write-forwarding-test-cluster-2-instance-2 \
  --db-instance-class db.r5.large \
  --engine aurora-mysql --engine-version 5.7.mysql_aurora.2.11.1 \
  --region us-east-2

Das folgende Beispiel setzt das vorherige Beispiel fort. In ihm werden ein sekundärer Cluster ohne aktivierte Schreibweiterleitung erstellt und anschließend die Schreibweiterleitung aktiviert. Nach Abschluss dieses Beispiels ist die Schreibweiterleitung für alle sekundären Cluster in der globalen Datenbank aktiviert.

# Create secondary cluster, in a different AWS Region than the global database,
# without write forwarding enabled.
aws rds create-db-cluster --global-cluster-identifier write-forwarding-test \
  --db-cluster-identifier write-forwarding-test-cluster-2 \
  --engine aurora-mysql --engine-version 5.7.mysql_aurora.2.11.1 \
  --region us-west-1

aws rds create-db-instance --db-cluster-identifier write-forwarding-test-cluster-2 \
  --db-instance-identifier write-forwarding-test-cluster-2-instance-1 \
  --db-instance-class db.r5.large \
  --engine aurora-mysql --engine-version 5.7.mysql_aurora.2.11.1 \
  --region us-west-1

aws rds create-db-instance --db-cluster-identifier write-forwarding-test-cluster-2 \
  --db-instance-identifier write-forwarding-test-cluster-2-instance-2 \
  --db-instance-class db.r5.large \
  --engine aurora-mysql --engine-version 5.7.mysql_aurora.2.11.1 \
  --region us-west-1

aws rds modify-db-cluster --db-cluster-identifier write-forwarding-test-cluster-2 \
  --region us-east-2 \
  --enable-global-write-forwarding

Überprüfung, ob für einen sekundären Cluster die Schreibweiterleitung in Aurora My aktiviert ist SQL

Um festzustellen, ob Sie die Schreibweiterleitung aus einem sekundären Cluster verwenden können, können Sie prüfen, ob der Cluster das Attribut besitz "GlobalWriteForwardingStatus": "enabled".

Auf der AWS Management Console Registerkarte Konfiguration der Detailseite für den Cluster sehen Sie den Status Aktiviert für globale Read Replica-Schreibweiterleitung.

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

Ein sekundärer Cluster zeigt die Werte "enabled" oder "disabled" an, um anzugeben, ob die Schreibweiterleitung aktiviert oder deaktiviert ist. Der Wert null gibt an, dass die Schreibweiterleitung für diesen Cluster nicht verfügbar ist. Entweder ist der Cluster nicht Teil einer globalen Datenbank oder ist der primäre Cluster und nicht kein sekundärer Cluster. Der Wert kann auch "enabling" oder "disabling" sein, wenn die Schreibweiterleitung gerade aktiviert oder deaktiviert wird.

aws rds describe-db-clusters \
--query '*[].{DBClusterIdentifier:DBClusterIdentifier,GlobalWriteForwardingStatus:GlobalWriteForwardingStatus}'

[
    {
        "GlobalWriteForwardingStatus": "enabled",
        "DBClusterIdentifier": "aurora-write-forwarding-test-replica-1"
    },
    {
        "GlobalWriteForwardingStatus": "disabled",
        "DBClusterIdentifier": "aurora-write-forwarding-test-replica-2"
    },
    {
        "GlobalWriteForwardingStatus": null,
        "DBClusterIdentifier": "non-global-cluster"
    }
]

Führen Sie den folgenden Befehl aus, um alle sekundären Cluster zu suchen, für die eine globale Schreibweiterleitung aktiviert ist. Dieser Befehl gibt auch den Reader-Endpunkt des Clusters aus. Sie verwenden den Reader-Endpunkt des sekundären Clusters, wenn Sie die Schreibweiterleitung vom sekundären zum primären Cluster in Ihrer globalen Aurora-Datenbank verwenden.

aws rds describe-db-clusters --query 'DBClusters[].{DBClusterIdentifier:DBClusterIdentifier,GlobalWriteForwardingStatus:GlobalWriteForwardingStatus,ReaderEndpoint:ReaderEndpoint} | [?GlobalWriteForwardingStatus == `enabled`]'
[
    {
        "GlobalWriteForwardingStatus": "enabled",
        "ReaderEndpoint": "aurora-write-forwarding-test-replica-1.cluster-ro-cnpexample.us-west-2.rds.amazonaws.com",
        "DBClusterIdentifier": "aurora-write-forwarding-test-replica-1"
    }
]

Anwendung und SQL Kompatibilität mit der Schreibweiterleitung in Aurora My SQL

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

Bestimmte Anweisungen sind nicht zulässig oder können veraltete Ergebnisse erzeugen, wenn Sie sie in einer globalen Datenbank mit Schreibweiterleitung verwenden. Daher ist die Einstellung EnableGlobalWriteForwarding für sekundäre Cluster standardmäßig deaktiviert. Stellen Sie vor einer 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 auf sekundären 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. Der Versuch, eine Anweisung zu verwenden, wenn sie aufgrund der Schreibweiterleitung nicht zulässig ist, verursacht eine Fehlermeldung im folgendem Format.

ERROR 1235 (42000): This version of MySQL doesn't yet support 'operation with write forwarding'.

Isolation und Konsistenz für die Schreibweiterleitung in Aurora My SQL

In Sitzungen, die Schreibweiterleitung verwenden, können Sie nur die Isolationsstufe REPEATABLE READ verwenden. Obwohl Sie die Isolationsstufe READ COMMITTED auch mit schreibgeschützten Clustern in sekundären AWS -Regionen 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.

Sie können den Grad der Lesekonsistenz in einem sekundären Cluster steuern. Die Lesekonsistenzstufe legt fest, wie viel Wartezeit der sekundäre Cluster vor jeder Leseoperation ausführt, um sicherzustellen, dass einige oder alle Änderungen aus dem primären Cluster repliziert werden. Sie können die Lesekonsistenzstufe anpassen, um sicherzustellen, dass alle aus Ihrer Sitzung weitergeleiteten Schreiboperationen im sekundären Cluster vor nachfolgenden Abfragen angezeigt werden. Sie können diese Einstellung auch verwenden, um sicherzustellen, dass Abfragen auf dem sekundären Cluster stets die aktuellsten Updates des primären Clusters angezeigt werden. Dies gilt auch für diejenigen, die von anderen Sitzungen oder anderen Clustern übermittelt wurden. Um diese Art von Verhalten für Ihre Anwendung anzugeben, wählen Sie einen Wert für den Sitzungsebenen-Parameter au aurora_replica_read_consistency.

Für den Parameter aurora_replica_read_consistency können Sie die Werte EVENTUAL, SESSION und GLOBAL angeben.

Wenn Sie das Konsistenzniveau erhöhen, verbringt Ihre Anwendung mehr Zeit damit, darauf zu warten, dass Änderungen zwischen den AWS Regionen weitergegeben werden. Sie können das Verhältnis zwischen schneller Reaktionszeit und der Gewährleistung festlegen, dass vor der Ausführung Ihrer Abfragen Änderungen an anderen Speicherorten vollständig verfügbar sind.

Wenn die Lesekonsistenz auf eingestellt istEVENTUAL, können Abfragen in einer sekundären AWS Region, die Schreibweiterleitung verwendet, Daten erkennen, die aufgrund von Replikationsverzögerungen leicht veraltet sind. Ergebnisse von Schreiboperationen in derselben Sitzung werden erst angezeigt, wenn die Schreiboperation in der primären Region ausgeführt und zur aktuellen Region repliziert 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.

Wenn die Lesekonsistenz auf eingestellt istSESSION, sehen alle Abfragen in einer sekundären AWS Region, die Schreibweiterleitung verwendet, die Ergebnisse aller in dieser Sitzung vorgenommenen Änderungen. Die Änderungen werden unabhängig davon angezeigt, ob die Transaktion übergeben wurde. Wenn notwendig, wartet die Abfrage auf die Replikation der Ergebnisse weitergeleiteter Schreiboperationen zur aktuellen Region. Sie wartet nicht auf aktualisierte Ergebnisse aus Schreiboperationen, die in anderen Regionen oder in anderen Sitzungen innerhalb der aktuellen Region ausgeführt werden.

Wenn die Lesekonsistenz auf eingestellt istGLOBAL, werden in einer Sitzung in einer sekundären AWS Region die Änderungen angezeigt, die durch diese Sitzung vorgenommen wurden. Außerdem werden alle übernommenen Änderungen sowohl aus der primären AWS Region als auch aus anderen sekundären AWS Regionen angezeigt. Jede Abfrage kann für einen bestimmten Zeitraum warten, abhängig von der Sitzungsverzögerung. Die Abfrage wird fortgesetzt, wenn der sekundäre Cluster zu up-to-date dem Zeitpunkt, zu dem die Abfrage gestartet wurde, alle zugeschriebenen Daten aus dem primären Cluster enthält.

Weitere Informationen zu allen mit der Schreibweiterleitung verbundenen Parametern finden Sie unter Konfigurationsparameter für die Schreibweiterleitung in Aurora My SQL.

Beispiele für die Verwendung der Schreibweiterleitung

In diesen Beispielen wird aurora_replica_read_consistency als Sitzungsvariable verwendet. Für Aurora My SQL Version 3.04 und höher können Sie es entweder aurora_replica_read_consistency als Sitzungsvariable oder als DB-Cluster-Parameter verwenden.

Im folgenden Beispiel befindet sich der primäre Cluster in der Region US East (N. Virginia). Der sekundäre Cluster befindet sich in der Region USA Ost (Ohio). Das Beispiel zeigt die Auswirkungen ausgeführter INSERT-Anweisungen, gefolgt von SELECT-Anweisungen. Abhängig vom Wert der Einstellung aurora_replica_read_consistency können sich die Ergebnisse abhängig vom Zeitpunkt der Anweisungen 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.

In diesem Beispiel gibt es eine Lesekonsistenzeinstellung von eventual. Das Ausführen der Anweisung INSERT unmittelbar gefolgt von der Anweisung SELECT gibt immer noch den Wert von COUNT(*) zurück. Dieser Wert gibt die Anzahl der Zeilen an, 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> set aurora_replica_read_consistency = 'eventual';
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)

Bei Festlegung der Lesekonsistenzeinstellung auf session wartet eine SELECT-Anweisung, die unmittelbar nach einer INSERT-Anweisung ausgeführt wird, bis die Änderungen aus der INSERT-Anweisung angezeigt werden. Nachfolgende SELECT-Anweisungen haben keine Wartezeit.

mysql> set aurora_replica_read_consistency = 'session';
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)

Wenn die Leseksistenzeinstellung auf global festgelegt ist, wartet jede SELECT-Anweisung, um sicherzustellen, dass alle Datenänderungen mit Stand zur Startzeit der Anweisung angezeigt werden, bevor die Abfrage ausgeführt wird. Die Wartezeit für die einzelnen SELECT-Anweisungen ist von der Replikationsverzögerung zwischen dem primären und den sekundären Clustern abhängig.

mysql> set aurora_replica_read_consistency = 'global';
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 mehrteiliger Anweisungen mit Schreibweiterleitung in Aurora My SQL

Eine DML Anweisung kann aus mehreren Teilen bestehen, z. B. aus einer INSERT ... SELECT Anweisung oder einer DELETE ... WHERE Anweisung. In diesem Fall wird die gesamte Anweisung an den primären Cluster weitergeleitet und dort ausgeführt.

Transaktionen mit Schreibweiterleitung in Aurora My SQL

Ob die Transaktion an den primären Cluster weitergeleitet wird, ist vom Zugriffsmodus der Transaktion abhängig. 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 Variablen Aurora My SQL session änderntx_read_only. Sie können diesen Sitzungswert nur ändern, wenn Sie mit einem sekundären 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 Wert auf bis zu einem Tag erhöhen. Eine Transaktion, die die Leerlaufzeitüberschreitung überschreitet, wird vom primären Cluster 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 Schreibweiterleitung verwenden, wenn Sie den primären Cluster neu starten oder die Konfigurationseinstellung für die Schreibweiterleitung deaktivieren.

Konfigurationsparameter für die Schreibweiterleitung in Aurora My SQL

Die Aurora-Cluster-Parametergruppen enthalten Einstellungen für die Schreibweiterleitung. Da es sich um Cluster-Parameter handelt, haben alle DB-Instances in allen Clustern die gleichen Werte für diese Variablen. Details zu diesen Parametern sind in der folgenden Tabelle zusammengefasst, mit Nutzungshinweisen unterhalb der Tabelle.

Um eingehende Schreibanforderungen aus sekundären Clustern zu steuern, verwenden Sie die folgenden Einstellungen auf dem primären Cluster:

Der Parameter aurora_replica_read_consistency ist ein Parameter auf Sitzungsebene, der die Schreibweiterleitung ermöglicht. Sie benutzen ihn in jeder Sitzung. Sie können EVENTUAL, SESSION oder GLOBAL als Lesekonsistenzstufe angeben. Weitere Informationen über Konsistenzebenen finden Sie unter Isolation und Konsistenz für die Schreibweiterleitung in Aurora My SQL. Für diesen Parameter gelten die folgenden Regeln:

CloudWatch Amazon-Metriken für die Weiterleitung von Schreibvorgängen in Aurora My SQL

Die folgenden CloudWatch Amazon-Metriken und Aurora SQL My-Statusvariablen gelten für den primären Cluster, wenn Sie die Schreibweiterleitung auf einem oder mehreren sekundären Clustern verwenden. Diese Metriken werden alle auf der Writer-DB-Instance im primären Cluster gemessen.

Die folgenden CloudWatch Metriken und Aurora SQL My-Statusvariablen gelten für jeden sekundären Cluster. Diese Metriken werden auf jeder Reader-DB-Instance in einem sekundären Cluster mit aktivierter Schreibweiterleitung gemessen.