Wichtige Überlegungen vor der Migration von Aurora zu Cloud SQL for MySQL
Amazon AWS und Google Cloud bieten beide cloudbasierte, vollständig verwaltete MySQL-Datenbankdienste. Beide Cloud-Dienstanbieter haben ihre eigenen Features und Unterschiede was ihre jeweilige Standardkonfiguration angeht. Diese Unterschiede können nach der Migration von einem Anbieter zum nächsten zu unvorhergesehenen Leistungs- oder Betriebsproblemen führen. In diesem Artikel finden Sie eine Zusammenfassung der Probleme, die bei einer solchen Migration auftreten können, sowie entsprechende Lösungen. Der Schwerpunkt liegt dabei auf der Migration von MySQL-Datenbankdiensten von Aurora MySQL zu Cloud SQL for MySQL.
Hinweise zur Migration
Zeichensatz: Leistungsproblem
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.Das 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.
Sie können den Zeichensatz von Abläufen mit dem folgenden Befehl prüfen:
|
mysql> select ROUTINE_NAME, ROUTINE_SCHEMA, CHARACTER_SET_NAME, COLLATION_NAME from information_schema.ROUTINES; |
Wenn Sie den Standardzeichensatz in Aurora (bis Version 5.7) verwendet haben, der Latin1 ist, muss der Standardzeichensatz in Cloud SQL vor dem Import der Daten von utf8 zu latin1 geändert werden.
Eine weitere Lösung könnte sein, alles auf 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 unter dem Flag-Abschnitt wie unten dargestellt bearbeiten.
Zeichensatz: Inkompatibilitätsproblem
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 Sammlungen in MySQL Version 5.7 zu ändern.
Speicher-Engine: Alle Tabellen müssen sich in InnoDB befinden
Cloud SQL for MySQL unterstützt die MyISAM-Engine nicht, im Gegensatz zu Aurora. Es wird empfohlen, alle Tabellen in InnoDB zu konvertieren, bevor Sie die Migration von Aurora zu Cloud SQL starten.
Wenn eine 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 für dieselbe Tabelle sperren. Sie können auch Online-Schemaänderungstools wie pt-online-schema-change oder gh-ost verwenden, um die Tabelle ändern, ohne andere Vorgänge zu blockieren.
Endpunkte für Leseverbindungen
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.
Aurora hat keinen Änderungspuffer
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 kann die Leistung beeinträchtigen
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 Abfragecache
Aurora aktiviert den Abfrage-Cache standardmäßig. Allerdings hat die MySQL-Community den Abfrage-Cache in Version 5.7 deaktiviert und in Version 8.0 vollständig entfernt. Dasselbe gilt für Cloud SQL MySQL. 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.
Replikationsmechanismus kann sich auf die Leistung auswirken
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 Sie die parallele Replikation in Cloud SQL konfigurieren. Parallele Replikation einrichten
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.
GTID-basierte Replikation (Globale Transaktions-ID)
Cloud SQL for MySQL verwendet im Gegensatz zu AWS Aurora, das die datenträgerbasierte Synchronisierung von Daten verwendet, die 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.
- CREATE TEMPORARY TABLE- und DROP TEMPORARY TABLE-Anweisungen werden in 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 in GTID.
Ähnliche Produkte und Dienste
Google Cloud bietet eine verwaltete MySQL-Datenbank, die auf Ihre geschäftlichen Anforderungen zugeschnitten ist – von der Stilllegung Ihres lokalen Rechenzentrums über die Ausführung von SaaS-Anwendungen bis hin zur Migration von Kerngeschäftssystemen.
