MySQL 8.0 is al geruime tijd bij ons en veel MySQL-gebruikers hebben al een upgrade naar deze versie uitgevoerd. Voor degenen die nog steeds oudere MySQL-versies gebruiken, willen we deze blog presenteren waar we enkele tips en informatie zullen delen die helpen bij het upgradeproces voor MySQL 8.0.
Let op uw versie
Softwareversies zijn erg belangrijk in het upgradeproces. Om te beginnen wordt slechts één belangrijk versieverschil ondersteund. U moet MySQL 5.7 gebruiken voordat u kunt upgraden naar MySQL 8.0. Dit is heel belangrijk om in gedachten te houden, aangezien MySQL 5.6 het einde van zijn levensduur nadert en het niet meer zal worden ondersteund. Iedereen die MySQL 5.6 gebruikt, moet ervoor zorgen dat u eerst een upgrade uitvoert naar MySQL 5.7 en vervolgens, uiteindelijk, naar MySQL 8.0.
Wat sterk wordt aanbevolen, is dat u een upgrade uitvoert naar de nieuwste versie die beschikbaar is voor MySQL 5.7. Op het moment van schrijven van deze blog was het 5.7.31, maar dit zal uiteindelijk veranderen, je kunt het altijd opzoeken op de MySQL-website.
Houd er ook rekening mee dat upgrades van niet-GA (en naar niet-GA) versies niet worden ondersteund. Niet dat het zin heeft om niet-GA-versies in productie te nemen, maar we wilden deze ook duidelijk maken.
Het is een enkele reis
Als je besluit de upgrade uit te voeren, houd er dan rekening mee dat, zodra de upgrade is voltooid, er geen terugkeer meer mogelijk is. De wijzigingen zijn niet compatibel en u kunt de gegevensmap van MySQL 8.0 gewoon niet gebruiken op MySQL 5.7. Zorg ervoor dat u direct voor de upgrade een back-up van uw MySQL 5.7-gegevens maakt - u kunt deze herstellen op een MySQL 5.7-instantie als u de wijziging ongedaan moet maken. Houd er ook rekening mee, want het kan als een verrassing komen, dat een upgrade van MySQL 8.0.x naar MySQL 8.0.x+1 ook niet compatibel kan zijn en, hoewel het een kleine versie-upgrade is, moet je die downgrade niet verwachten zou mogelijk zijn. Dit is het resultaat van de implementatiecyclus van Oracle - in plaats van het bevriezen van functies voor de nieuwste GA-tak, zoals het geval was met eerdere versies, worden nieuwe functies, soms incompatibele, gepusht als nieuwe releases van 8.0-tak.
In-Place Upgrade is een Go
In het verleden was het niet altijd mogelijk om een in-place upgrade van MySQL uit te voeren. In sommige gevallen werd u gedwongen om de gegevens in SQL-indeling te dumpen en deze vervolgens terug te laden naar de nieuwe versie. Gelukkig is MySQL 8.0 beheerdersvriendelijker en wordt een interne upgrade ondersteund. Het enige wat u hoeft te doen is apt upgrade of yum update uit te voeren en u bent helemaal klaar. De upgrade is nog handiger - in het verleden moest men er rekening mee houden om mysql_upgrade uit te voeren om ervoor te zorgen dat alle systeemtabellen correct werden opgewaardeerd naar het formaat dat vereist is voor de nieuwe versie van MySQL. In MySQL 8.0, vanaf MySQL 8.0.16, is dit niet langer nodig - het enige wat u hoeft te doen is het MySQL-proces, mysqld te starten, en standaard wordt de upgrade uitgevoerd via de datadictionary en andere systeemschema's wanneer dat nodig is. vastbesloten nodig te zijn. Het is mogelijk om dit gedrag te veranderen door verschillende parameters door te geven aan de optie --upgrade server, maar in de meeste gevallen wilt u profiteren van deze verbetering.
Kan ik veilig upgraden?
Natuurlijk zijn er voorwaarden voor de veilige upgrade. Laten we eens kijken naar enkele methoden die u zouden moeten helpen ervoor te zorgen dat u veilig kunt upgraden naar MySQL 8.0.
Gezondheidscontroles
Voordat u iets probeert, moet u controleren of uw bestaande MySQL 5.7-configuratie alle vakjes op de sanity-checklist aanvinkt voordat u upgradet naar MySQL 8.0. MySQL-documentatie biedt een uitgebreide lijst met dingen die moeten worden getest. Het heeft geen zin om de lijst hier door te nemen, aangezien deze wordt behandeld in de MySQL-documentatie, maar hier zijn een paar punten die u misschien in gedachten wilt houden.
Ten eerste wordt partitionering nu alleen ondersteund in engines die het aan hun kant implementeren, namelijk alleen NDB en InnoDB. Zorg ervoor dat alle gepartitioneerde tabellen een van die opslagengines gebruiken of dat u de partitionering verwijdert vóór de upgrade.
Misschien wil je rennen
mysqlcheck -u root -p --all-databases --check-upgradeom te controleren of tabellen de juiste indeling hebben.
Er zijn ook andere controles die u moet uitvoeren - bijna elke nieuwe MySQL-versie wordt geleverd met een bijgewerkte lijst met gereserveerde woorden en u moet controleren of u ze niet in uw database gebruikt. U moet de namen van externe sleutelbeperkingen controleren, deze mogen niet langer zijn dan 64 tekens. Sommige opties voor sql_mode zijn verwijderd, dus u moet ervoor zorgen dat u ze niet gebruikt. Zoals we al zeiden, is er een uitgebreide lijst met dingen om te testen.
MySQL Shell to the Rescue
Het testen van al deze voorwaarden is nogal tijdrovend, daarom heeft Oracle een optie in de MySQL Shell gemaakt die bedoeld is om een reeks tests uit te voeren om te controleren of uw bestaande installatie veilig is om te upgraden naar MySQL 8.0. Om te beginnen, als u MySQL Shell niet hebt geïnstalleerd, moet u dat doen. U kunt downloads vinden op de website van Oracle. Nadat u het hebt ingesteld, kunt u verbinding maken met uw MySQL 5.7 en de test uitvoeren. Laten we eens kijken hoe het eruit kan zien:
[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.We hebben verbinding gemaakt met de MySQL-instantie op de localhost met behulp van MySQL Shell. Nu kunnen we de controle uitvoeren. We geven het pad naar het configuratiebestand door voor uitgebreidere tests:
MySQL localhost:33060+ ssl JS > util.checkForServerUpgrade({"configPath":"/etc/mysql/my.cnf"})Dan hebben we een lange output.
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.Zoals je kunt zien, zijn er in totaal 21 tests uitgevoerd, de controle heeft 3 fouten gevonden met betrekking tot de configuratie-opties die niet zullen bestaan in MySQL 8.0.21. De tests zijn vrij gedetailleerd. Je leert onder andere over veranderingen in de standaardwaarden voor variabelen die je niet hebt geconfigureerd in je MySQL-configuratie (die instellingen veranderen dus zodra je MySQL 8.0 installeert).
Een mislukte upgrade terugdraaien
Zoals we eerder vermeldden, kunt u niet downgraden van MySQL 8.0 zodra de upgrade is voltooid. Gelukkig betekent dit niet dat je de upgrade niet kunt terugdraaien als deze halverwege mislukt. Het gebeurt eigenlijk semi-automatisch als een van de problemen die we in de vorige sectie hebben besproken, wordt gedetecteerd. De enige handmatige actie die nodig is, is het verwijderen van logbestanden voor opnieuw uitvoeren en het starten van MySQL 5.7 om de problemen op te lossen die tijdens de upgrade zijn gedetecteerd. Daarna moet je langzaam afsluiten (innodb_fast_shutdown=0) om ervoor te zorgen dat alles naar de tablespaces wordt geschreven en dan kun je de upgrade nog een keer proberen.
Laatste tips
Er zijn twee, vrij belangrijke veranderingen in het standaardgedrag van MySQL 8.0 die we willen benadrukken.
Caching_sha2_password als standaard
Zorg ervoor dat u nogmaals controleert of uw toepassingen en proxy's correct werken met de verificatieplug-in caching_sha2_password, aangezien dit de standaardversie wordt in MySQL 8.0. Oudere toepassingen kunnen worden beïnvloed en kunnen geen verbinding maken met de database. Je kunt dit natuurlijk wijzigen in elke authenticatie-plug-in die je wilt (zoals mysql_native_password bijvoorbeeld, omdat het de standaard was in eerdere MySQL-versies), dus het is op geen enkele manier een blocker. Het is gewoon iets om te onthouden om te testen vóór de upgrade, zodat u niet eindigt met MySQL 8.0 en apps die er geen verbinding mee kunnen maken, tenzij u uw database opnieuw configureert om een ouder authenticatiemechanisme te gebruiken.
UTF8mb4 als de standaardtekenset
Dit zou niet als een verrassing moeten komen, aangezien de wijziging in UTF8 in de gemeenschap veel werd besproken, maar dat is het feit - MySQL 8.0 wordt standaard geleverd met UTF8mb4-tekenset. Dit heeft een extra impact waarvan u zich bewust moet zijn. Ten eerste kan de grootte van uw dataset toenemen als u UTF8mb4-tekenset gebruikt. Dit leidt ertoe dat geheugenbuffers kleinere hoeveelheden gegevens kunnen opslaan dan voor gegevens met een latin1-tekenset. Ten tweede zullen de prestaties van MySQL naar verwachting afnemen. Natuurlijk, Oracle heeft uitstekend werk geleverd door de impact van deze wijziging te minimaliseren, maar je kunt niet verwachten dat er geen enkele impact zal zijn op de prestaties - het zal een beetje zijn.
We hopen dat deze blogpost je zal helpen bij het upgraden van MySQL 5.7 naar MySQL 8.0. Als je je mening hebt over het proces, raden we je aan om deze te delen in de reacties onder dit bericht.