MySQL 8.0 ist schon seit geraumer Zeit bei uns und viele MySQL-Benutzer haben bereits auf diese Version aktualisiert. Für diejenigen, die noch ältere MySQL-Versionen verwenden, möchten wir diesen Blog vorstellen, in dem wir einige Tipps und Informationen teilen, die beim Upgrade-Prozess für MySQL 8.0 helfen.
Achten Sie auf Ihre Version
Softwareversionen sind im Upgrade-Prozess sehr wichtig. Für den Anfang wird nur ein Hauptversionsunterschied unterstützt. Sie müssen MySQL 5.7 ausführen, bevor Sie auf MySQL 8.0 aktualisieren können. Dies ist sehr wichtig, da sich MySQL 5.6 dem Ende seiner Lebensdauer nähert und nicht mehr unterstützt wird. Alle, die MySQL 5.6 verwenden, müssen sicherstellen, dass sie zuerst auf MySQL 5.7 und dann schließlich auf MySQL 8.0 aktualisieren.
Es wird dringend empfohlen, dass Sie auf die neueste verfügbare Version für MySQL 5.7 aktualisieren. Zum Zeitpunkt des Schreibens dieses Blogs war es 5.7.31, aber das wird sich irgendwann ändern, Sie können es jederzeit auf der MySQL-Website nachschlagen.
Bitte beachten Sie auch, dass Upgrades von Nicht-GA-Versionen (und auf Nicht-GA-Versionen) nicht unterstützt werden. Nicht, dass es Sinn macht, Nicht-GA-Versionen in der Produktion zu verwenden, aber wir wollten dies auch klarstellen.
Es ist ein One-Way-Ticket
Wann immer Sie sich entscheiden, das Upgrade durchzuführen, beachten Sie bitte, dass es nach Abschluss des Upgrades kein Zurück mehr gibt. Die Änderungen sind nicht kompatibel und Sie können das Datenverzeichnis von MySQL 8.0 einfach nicht auf MySQL 5.7 verwenden. Stellen Sie sicher, dass Sie direkt vor dem Upgrade eine Sicherungskopie Ihrer MySQL 5.7-Daten erstellen – Sie könnten sie auf einer MySQL 5.7-Instanz wiederherstellen, falls Sie die Änderung rückgängig machen müssen. Bitte denken Sie auch daran, dass ein Upgrade von MySQL 8.0.x auf MySQL 8.0.x+1 möglicherweise nicht kompatibel ist, da es überraschend sein kann, und obwohl es sich um ein kleineres Versions-Upgrade handelt, sollten Sie dieses Downgrade nicht erwarten wäre möglich. Dies ist das Ergebnis des Bereitstellungszyklus von Oracle – anstatt Feature-Freeze für den neuesten GA-Zweig durchzuführen, wie es bei früheren Versionen der Fall war, werden neue Funktionen, manchmal inkompatible, als neue Versionen von 8.0-Zweig gepusht.
In-Place-Upgrade ist ein Go
In der Vergangenheit war es nicht immer möglich, ein direktes Upgrade von MySQL durchzuführen. In einigen Fällen waren Sie gezwungen, die Daten in das SQL-Format zu sichern und sie dann wieder in die neue Version zu laden. Glücklicherweise ist MySQL 8.0 verwaltungsfreundlicher und In-Place-Upgrades werden unterstützt. Alles, was Sie tun müssen, ist, apt upgrade oder yum update auszuführen, und schon sind Sie fertig. Das Upgrade ist noch bequemer - in der Vergangenheit musste man daran denken, mysql_upgrade auszuführen, um sicherzustellen, dass alle Systemtabellen ordnungsgemäß auf das von der neuen MySQL-Version benötigte Format aktualisiert werden. In MySQL 8.0, beginnend mit MySQL 8.0.16, ist dies nicht mehr erforderlich – alles, was Sie tun müssen, ist, den MySQL-Prozess mysqld zu starten, und standardmäßig wird das Upgrade über das Datenwörterbuch und andere Systemschemata durchgeführt, wann immer es der Fall ist bestimmt erforderlich. Es ist möglich, dieses Verhalten zu ändern, indem Sie verschiedene Parameter an die Serveroption --upgrade übergeben, aber in den meisten Fällen möchten Sie von dieser Verbesserung profitieren.
Kann ich sicher upgraden?
Natürlich gibt es Voraussetzungen für das sichere Upgrade. Werfen wir einen Blick auf einige Methoden, die Ihnen dabei helfen sollen sicherzustellen, dass Sie ein sicheres Upgrade auf MySQL 8.0 durchführen können.
Sicherheitsprüfungen
Bevor Sie irgendetwas versuchen, sollten Sie vor dem Upgrade auf MySQL 8.0 überprüfen, ob Ihr vorhandenes MySQL 5.7-Setup alle Kästchen auf der Plausibilitäts-Checkliste ankreuzt. Die MySQL-Dokumentation enthält eine umfangreiche Liste von Dingen, die getestet werden können. Es macht keinen Sinn, die Liste hier durchzugehen, da sie in der MySQL-Dokumentation behandelt wird, aber hier sind ein paar Punkte, die Sie vielleicht im Hinterkopf behalten sollten.
Erstens wird die Partitionierung jetzt nur noch in Engines unterstützt, die sie auf ihrer Seite implementieren, also nur NDB und InnoDB. Bitte stellen Sie sicher, dass alle partitionierten Tabellen eine dieser Speicher-Engines verwenden oder dass Sie die Partitionierung vor dem Upgrade entfernen.
Vielleicht möchten Sie rennen
mysqlcheck -u root -p --all-databases --check-upgradeum zu überprüfen, ob die Tabellen das richtige Format haben.
Es gibt auch andere Überprüfungen, die Sie durchführen sollten – fast jede neue MySQL-Version enthält eine aktualisierte Liste reservierter Wörter, und Sie sollten überprüfen, dass Sie diese nicht in Ihrer Datenbank verwenden. Sie müssen Fremdschlüsselbeschränkungsnamen überprüfen, sie dürfen nicht länger als 64 Zeichen sein. Einige Optionen für sql_mode wurden entfernt, daher sollten Sie sicherstellen, dass Sie sie nicht verwenden. Wie bereits erwähnt, gibt es eine umfangreiche Liste von Dingen, die getestet werden können.
MySQL-Shell zur Rettung
Das Testen all dieser Bedingungen ist ziemlich zeitaufwändig, daher hat Oracle eine Option in der MySQL-Shell erstellt, die eine Reihe von Tests ausführen soll, um zu überprüfen, ob Ihre vorhandene Installation sicher auf MySQL 8.0 aktualisiert werden kann. Wenn Sie MySQL Shell nicht installiert haben, sollten Sie dies zunächst tun. Sie finden Downloads auf der Website von Oracle. Sobald Sie es eingerichtet haben, können Sie eine Verbindung zu Ihrem MySQL 5.7 herstellen und den Test ausführen. Mal sehen, wie es aussehen kann:
[email protected]:~# mysqlsh
MySQL Shell 8.0.21
Copyright (c) 2016, 2020, Oracle and/or its affiliates. All rights reserved.
Oracle is a registered trademark of Oracle Corporation and/or its affiliates.
Other names may be trademarks of their respective owners.
Type '\help' or '\?' for help; '\quit' to exit.
MySQL JS > \c [email protected]
Creating a session to '[email protected]'
Please provide the password for '[email protected]': ****
Save password for '[email protected]'? [Y]es/[N]o/Ne[v]er (default No):
Fetching schema names for autocompletion... Press ^C to stop.
Your MySQL connection id is 71 (X protocol)
Server version: 5.7.31-log MySQL Community Server (GPL)
No default schema selected; type \use <schema> to set one.Wir haben mit MySQL Shell eine Verbindung zur MySQL-Instanz auf dem lokalen Host hergestellt. Jetzt können wir die Überprüfung durchführen. Für ausführlichere Tests übergeben wir den Pfad zur Konfigurationsdatei:
MySQL localhost:33060+ ssl JS > util.checkForServerUpgrade({"configPath":"/etc/mysql/my.cnf"})Dann haben wir eine lange Ausgabe.
The MySQL server at localhost:33060, version 5.7.31-log - MySQL Community
Server (GPL), will now be checked for compatibility issues for upgrade to MySQL
8.0.21...
1) Usage of old temporal type
No issues found
2) Usage of db objects with names conflicting with new reserved keywords
No issues found
3) Usage of utf8mb3 charset
No issues found
4) Table names in the mysql schema conflicting with new tables in 8.0
No issues found
5) Partitioned tables using engines with non native partitioning
No issues found
6) Foreign key constraint names longer than 64 characters
No issues found
7) Usage of obsolete MAXDB sql_mode flag
No issues found
8) Usage of obsolete sql_mode flags
No issues found
9) ENUM/SET column definitions containing elements longer than 255 characters
No issues found
10) Usage of partitioned tables in shared tablespaces
No issues found
11) Circular directory references in tablespace data file paths
No issues found
12) Usage of removed functions
No issues found
13) Usage of removed GROUP BY ASC/DESC syntax
No issues found
14) Removed system variables for error logging to the system log configuration
No issues found
15) Removed system variables
Error: Following system variables that were detected as being used will be
removed. Please update your system to not rely on them before the upgrade.
More information:
https://dev.mysql.com/doc/refman/8.0/en/added-deprecated-removed.html#optvars-removed
log_warnings - is set and will be removed, consider using log_error_verbosity
instead
query_cache_size - is set and will be removed
query_cache_type - is set and will be removed
16) System variables with new default values
Warning: Following system variables that are not defined in your
configuration file will have new default values. Please review if you rely on
their current values and if so define them before performing upgrade.
More information:
https://mysqlserverteam.com/new-defaults-in-mysql-8-0/
back_log - default value will change
character_set_server - default value will change from latin1 to utf8mb4
collation_server - default value will change from latin1_swedish_ci to
utf8mb4_0900_ai_ci
event_scheduler - default value will change from OFF to ON
explicit_defaults_for_timestamp - default value will change from OFF to ON
innodb_flush_neighbors - default value will change from 1 (enable) to 0
(disable)
innodb_max_dirty_pages_pct - default value will change from 75 (%) 90 (%)
innodb_max_dirty_pages_pct_lwm - default value will change from_0 (%) to 10
(%)
innodb_undo_log_truncate - default value will change from OFF to ON
innodb_undo_tablespaces - default value will change from 0 to 2
log_error_verbosity - default value will change from 3 (Notes) to 2 (Warning)
max_error_count - default value will change from 64 to 1024
optimizer_trace_max_mem_size - default value will change from 16KB to 1MB
performance_schema_consumer_events_transactions_current - default value will
change from OFF to ON
performance_schema_consumer_events_transactions_history - default value will
change from OFF to ON
slave_rows_search_algorithms - default value will change from 'INDEX_SCAN,
TABLE_SCAN' to 'INDEX_SCAN, HASH_SCAN'
transaction_write_set_extraction - default value will change from OFF to
XXHASH64
17) Zero Date, Datetime, and Timestamp values
No issues found
18) Schema inconsistencies resulting from file removal or corruption
No issues found
19) Tables recognized by InnoDB that belong to a different engine
No issues found
20) Issues reported by 'check table x for upgrade' command
No issues found
21) New default authentication plugin considerations
Warning: The new default authentication plugin 'caching_sha2_password' offers
more secure password hashing than previously used 'mysql_native_password'
(and consequent improved client connection authentication). However, it also
has compatibility implications that may affect existing MySQL installations.
If your MySQL installation must serve pre-8.0 clients and you encounter
compatibility issues after upgrading, the simplest way to address those
issues is to reconfigure the server to revert to the previous default
authentication plugin (mysql_native_password). For example, use these lines
in the server option file:
[mysqld]
default_authentication_plugin=mysql_native_password
However, the setting should be viewed as temporary, not as a long term or
permanent solution, because it causes new accounts created with the setting
in effect to forego the improved authentication security.
If you are using replication please take time to understand how the
authentication plugin changes may impact you.
More information:
https://dev.mysql.com/doc/refman/8.0/en/upgrading-from-previous-series.html#upgrade-caching-sha2-password-compatibility-issues
https://dev.mysql.com/doc/refman/8.0/en/upgrading-from-previous-series.html#upgrade-caching-sha2-password-replication
Errors: 3
Warnings: 18
Notices: 0
3 errors were found. Please correct these issues before upgrading to avoid compatibility issues.Wie Sie sehen können, wurden insgesamt 21 Tests durchgeführt, die Prüfung hat 3 Fehler im Zusammenhang mit den Konfigurationsoptionen gefunden, die in MySQL 8.0.21 nicht vorhanden sein werden. Die Tests sind recht ausführlich. Unter anderem erfahren Sie etwas über Änderungen der Standardwerte für Variablen, die Sie nicht in Ihrer MySQL-Konfiguration konfiguriert haben (diese Einstellungen werden sich also ändern, sobald Sie MySQL 8.0 installieren).
Rollback eines fehlgeschlagenen Upgrades
Wie bereits erwähnt, können Sie nach Abschluss des Upgrades kein Downgrade von MySQL 8.0 durchführen. Glücklicherweise bedeutet dies nicht, dass Sie das Upgrade nicht rückgängig machen können, wenn es mittendrin fehlschlägt. Tatsächlich geschieht dies halbautomatisch, wenn eines der im vorherigen Abschnitt besprochenen Probleme erkannt wird. Die einzige manuelle Aktion, die erforderlich wäre, wäre das Entfernen von Redo-Protokollen und das Starten von MySQL 5.7, um die während des Upgrades festgestellten Probleme zu beheben. Dann sollten Sie ein langsames Herunterfahren durchführen (innodb_fast_shutdown=0), um sicherzustellen, dass alles in die Tablespaces geschrieben wird, und dann können Sie das Upgrade noch einmal versuchen.
Letzte Tipps
Es gibt zwei sehr wichtige Änderungen im Standardverhalten von MySQL 8.0, die wir hervorheben möchten.
Caching_sha2_password als Standard
Bitte stellen Sie sicher, dass Sie überprüfen, ob Ihre Anwendungen und Proxys ordnungsgemäß mit dem caching_sha2_password-Authentifizierungs-Plugin funktionieren, da es das Standard-Plugin in MySQL 8.0 wird. Ältere Anwendungen sind möglicherweise betroffen und können keine Verbindung zur Datenbank herstellen. Natürlich können Sie dies in ein beliebiges Authentifizierungs-Plugin ändern (wie zum Beispiel mysql_native_password, da es in früheren MySQL-Versionen der Standard war), so dass es keineswegs ein Blocker ist. Es ist nur etwas, das Sie daran denken sollten, es vor dem Upgrade zu testen, damit Sie nicht mit MySQL 8.0 und Apps enden, die keine Verbindung dazu herstellen können, es sei denn, Sie konfigurieren Ihre Datenbank neu, um einen älteren Authentifizierungsmechanismus zu verwenden.
UTF8mb4 als Standardzeichensatz
Dies sollte nicht überraschen, wenn man bedenkt, wie viel in der Community über die Umstellung auf UTF8 diskutiert wurde, aber Tatsache ist - MySQL 8.0 wird standardmäßig mit dem UTF8mb4-Zeichensatz geliefert. Dies hat einige zusätzliche Auswirkungen, derer Sie sich bewusst sein sollten. Erstens kann die Größe Ihres Datensatzes zunehmen, wenn Sie den UTF8mb4-Zeichensatz verwenden. Dies führt dazu, dass Speicherpuffer kleinere Datenmengen speichern können als für Daten mit latin1-Zeichensatz. Zweitens wird erwartet, dass die Leistung von MySQL reduziert wird. Sicher, Oracle hat großartige Arbeit geleistet, um die Auswirkungen dieser Änderung zu minimieren, aber Sie können nicht erwarten, dass es keinerlei Auswirkungen auf die Leistung geben wird - es werden einige sein.
Wir hoffen, dass dieser Blogbeitrag Ihnen beim Upgrade von MySQL 5.7 auf MySQL 8.0 helfen wird. Wenn Sie Ihre Gedanken zu dem Prozess haben, empfehlen wir Ihnen, diese in den Kommentaren unter diesem Beitrag mitzuteilen.
