Wichtige Überlegungen vor der Migration von Aurora zu Cloud SQL for MySQL

Aurora verwendet den Standardzeichensatz latin1 (bis MySQL v 5.7). Dies unterscheidet sich von der Standardkonfiguration von Cloud SQL for MySQL für Datenbanken, Tabellen, gespeicherte Prozeduren und Funktionen, die während der Migration mit utf8 als Standardzeichensatz erstellt werden.Dies kann zu Situationen führen, die zu Leistungsproblemen führen.

Beispielsweise kann ein Nutzer in eine Situation geraten, in der Tabellen mit dem Zeichensatz Latin1 und gespeicherte Prozeduren oder Funktionen mit dem Standard-utf8-Zeichensatz von Cloud SQL erstellt werden. Wenn in einem solchen Fall die gespeicherte Prozedur oder Funktion Variablen als utf8-Parameter erwartet und eine Variable mit einem Spaltenwert im Latin1-Zeichensatz vergleicht, führt dies zu Leistungsproblemen, da ein Vergleich von zwei verschiedenen Zeichensätzen und Sortierungen passiert. 

Mit dem folgenden Befehl können Sie den Zeichensatz von Abläufen prüfen:

mysql> select ROUTINE_NAME, ROUTINE_SCHEMA, CHARACTER_SET_NAME, COLLATION_NAME from information_schema.ROUTINES;

Wenn Sie in Aurora (bis Version 5.7) den Standardzeichensatz „latin1“ verwendet haben, sollten Sie den Standardzeichensatz in Cloud SQL vor dem Importieren der Daten von „utf8“ zu „latin1“ ändern.

Eine andere Lösung könnte darin bestehen, alles in utf8 zu ändern. In diesem Fall sollten Nutzer jedoch die gesamte Anwendung und das gesamte Dataset testen, da Änderungen am Zeichensatz zu unerwarteten Datendarstellungen führen können.

Nutzer können diese Einstellung in der Cloud SQL-Instanz im Abschnitt „Flags“ bearbeiten, wie unten dargestellt.

Aurora MySQL 5.7 hat viele Sortierungen (z. B. utf8mb4_0900_ai_ci für den Zeichensatz utf8mb4), die derzeit nur in Cloud SQL for MySQL 8.0 verfügbar sind. Wenn Sie solche Sortierungen verwenden und die Daten in Cloud SQL for MySQL 5.7 importieren, erhalten Sie eine Fehlermeldung wie „Fehler: ‚Zeichensatz '#255‘ ist kein kompilierter Zeichensatz“.

Die Lösung besteht darin, diese Sortierungen in verfügbare Sortierungen in MySQL Version 5.7 zu ändern.

Cloud SQL for MySQL unterstützt die MyISAM-Engine nicht, im Gegensatz zu Aurora. Es empfiehlt sich, alle Tabellen in InnoDB zu konvertieren, bevor Sie mit der Migration von Aurora zu Cloud SQL beginnen. 

Wenn eine andere Tabelle in einer anderen Engine als InnoDB vorhanden ist, können Nutzer die Engine der Tabelle mit dem Befehl „ALTER“ ändern:

mysql> alter table table_1 engine='Innodb' ;

Query OK, 0 rows affected (2.89 sec)

Records: 0  Duplicates: 0  Warnings: 0

Hinweis: Die Abfragezeit hängt von der Tabellengröße ab und kann andere Vorgänge in derselben Tabelle sperren. Sie können auch Onlinetools für Schemaänderungen wie pt-online-schema-change oder gh-ost verwenden, um die Tabelle zu ändern, ohne andere Vorgänge zu blockieren.

In Aurora können Nutzer mehrere Lesezugriffe hinter einem einzelnen Endpunkt einrichten. Für Cloud SQL for MySQL-Nutzer ist dieses Feature jedoch standardmäßig nicht verfügbar. Jedes Lesereplikat in Cloud SQL for MySQL hat eine eigene IP-Adresse und Nutzer müssen etwas wie ProxySQL verwenden, um den Traffic auf mehrere Lesereplikatinstanzen aufzuteilen.

Hier finden Sie eine Anleitung zum Weiterleiten des Traffics zwischen mehreren Lesereplikaten mit ProxySQL.

Der Änderungspuffer ist eine spezielle Datenstruktur, mit der Änderungen an sekundären Indexseiten im Cache gespeichert werden, wenn sich diese Seiten nicht im Pufferpool befinden. Die Änderungen werden später zusammengeführt, wenn diese Seiten durch andere Lesevorgänge in den Pufferpool geladen werden. Weitere Informationen finden Sie unter Änderungspuffer.

Für den Anwendungsfall, bei dem die Arbeitslast viele Schreibvorgänge auf den Tabellen mit sekundären Indexen hat, ist die Ausführung von Aurora möglicherweise langsamer als Cloud SQL for MySQL, das die standardmäßige Änderungspufferfunktion von InnoDB verwendet, um diese Aktualisierungen auf spätere Phasen zu verschieben. Nutzer sollten die Leistung gemäß ihrer Anwendungsarbeitslast messen.

Der Abfrage-Cache speichert den Befehl „select“ zusammen mit dessen Ergebnis in einer Zwischen-Speicherebene. Wenn später eine identische Anweisung empfangen wird, prüft der Server die Ergebnisse und ruft sie aus dem Abfragecache ab, statt diesen Befehl noch einmal auszuführen. Der Abfragecache wird von den Sitzungen gemeinsam genutzt, sodass alle Sitzungen von Ergebnissen profitieren können, die durch bereits ausgeführte Anweisungen aus anderen Sitzungen im Cache gespeichert werden. Weitere Informationen zum Abfrage-Cache

Aurora aktiviert den Abfrage-Cache standardmäßig. Die MySQL-Community hat ihn jedoch in Version 5.7 deaktiviert und in Version 8.0 vollständig entfernt. Genauso hat Cloud SQL MySQL dasselbe gemacht. Wenn Ihre Abfragen auf die Abfrage-Cache-Funktion von Aurora angewiesen sind, kann die Leistung in Cloud SQL MySQL unterschiedliche ausfallen. Es wird empfohlen, die Abfrageleistung in Cloud SQL MySQL durch einen Vergleich der Ausführungszeit mit der von Aurora zu testen.

Für Lesereplikate innerhalb einer Region verwendet Aurora das Cluster-Volume-Konzept, das Kopien der Daten in drei Verfügbarkeitszonen innerhalb dieser Region hat. Die Replikationsverzögerung in Aurora beträgt in der Regel viel weniger als 100 Millisekunden, da das primäre und die Replikate innerhalb desselben Datenbankclusters die Daten im Cluster-Volume als einzelnes logisches Volume ansehen. Darüber hinaus verwendet Aurora für das regionenübergreifende Lesereplikat die datenträgerbasierte Datensynchronisierung über Regionen hinweg anstelle der binären logbasierten Replikation.

Kurz gesagt, die Replikation wird von der Speicherschicht in Aurora abgewickelt, in Cloud SQL for MySQL wird dagegen der Standardreplikationsmechanismus verwendet, bei dem das binäre Log auf die Replikatinstanz übertragen wird und anschließend diese Logs in Replikat-MySQL-Instanzen erneut wiedergegeben werden. Wir können die Leistung der Replikation verbessern, indem wir die parallele Replikation in Cloud SQL konfigurieren. Lesen Sie Details zum Einrichten der parallelen Replikation.

Obwohl die Replikationsverzögerung von der Datenmenge abhängt, die von der Anwendung und dem Netzwerk zwischen der primären Instanz und der Replikatinstanz geändert wird, funktionieren die meisten Anwendungen problemlos in Aurora und Cloud SQL MySQL ohne nennenswerte Verzögerung. Wenn die Anwendung jedoch schreibintensiv ist und aus den Replikaten liest, sollten Sie vor der Migration die Replikationsverzögerung sowohl in AWS Aurora als auch in CloudSQL MySQL messen.

Im Gegensatz zu AWS Aurora, das die laufwerkbasierte Datensynchronisierung nutzt, verwendet Cloud SQL for MySQL GTID-Replikation. Nutzer sollten vor der Migration auf die unten aufgeführten Einschränkungen der GTID prüfen und alle erforderlichen Änderungen an ihrer Anwendung vornehmen, wenn der Anwendungsworkflow von einem dieser Features abhängt:

• CREATE TABLE ... SELECT-Anweisungen sind bei Verwendung der GTID-basierten Replikation nicht zulässig.
• Die Anweisungen CREATE TEMPORARY TABLE und DROP TEMPORARY TABLE werden innerhalb von Transaktionen, Verfahren, Funktionen und Triggern nicht unterstützt. Es ist möglich, diese Anweisungen bei aktivierten GTIDs zu nutzen, aber nur außerhalb von Transaktionen und nur mit autocommit=1.

Weitere Informationen zu GTID-basierten Einschränkungen finden Sie unter Einschränkungen bei GTID.