MySQL 8.0 har allerede været hos os i et stykke tid, og mange MySQL-brugere har allerede opgraderet til denne version. For dem, der stadig bruger ældre MySQL-versioner, vil vi gerne præsentere denne blog, hvor vi vil dele nogle tips og information, der hjælper i opgraderingsprocessen til MySQL 8.0.
Husk din version
Softwareversioner er ret vigtige i opgraderingsprocessen. For det første understøttes kun én større versionsforskel. Du skal køre MySQL 5.7, før du kan opgradere til MySQL 8.0. Dette er ret vigtigt at huske på, da MySQL 5.6 nærmer sig End-of-Life, og det vil ikke længere blive understøttet. For alle jer, der bruger MySQL 5.6, skal I sørge for at opgradere det til MySQL 5.7 først og derefter til sidst til MySQL 8.0.
Det, der stærkt anbefales, er, at du opgraderer til den nyeste version, der er tilgængelig til MySQL 5.7. På tidspunktet for skrivning af denne blog var den 5.7.31, men dette vil i sidste ende ændre sig, du kan altid slå det op på MySQL-webstedet.
Bemærk også, at opgraderinger fra ikke-GA (og til ikke-GA) versioner ikke understøttes. Ikke at det giver nogen mening at køre ikke-GA-versioner i produktion, men vi ønskede også at gøre denne klar.
Det er en enkeltbillet
Når du beslutter dig for at udføre opgraderingen, skal du være opmærksom på, at når opgraderingen er fuldført, er der ingen tilbagevenden. Ændringerne er ikke kompatible, og du kan simpelthen ikke bruge databiblioteket fra MySQL 8.0 på MySQL 5.7. Sørg for at tage en sikkerhedskopi af dine MySQL 5.7-data direkte før opgraderingen - du ville være i stand til at gendanne den på MySQL 5.7-instansen, hvis du skulle få brug for at fortryde ændringen. Husk også, da det kan komme som en overraskelse, at opgradering fra MySQL 8.0.x til MySQL 8.0.x+1 muligvis heller ikke er kompatibel, og selvom det er en mindre versionsopgradering, skal du ikke forvente denne nedgradering ville være muligt. Dette er resultatet af Oracles implementeringscyklus - i stedet for at lave funktionsfrysning for den seneste GA-gren, som det var tilfældet med tidligere versioner, bliver nye funktioner, nogle gange inkompatible, skubbet som nye udgivelser af 8.0-grenen.
In-Place Upgrade er en Go
Tidligere var det ikke altid muligt at udføre en lokal opgradering af MySQL. I nogle tilfælde blev du tvunget til at dumpe dataene i SQL-format og derefter indlæse dem tilbage til den nye version. Heldigvis er MySQL 8.0 mere administratorvenlig, og opgradering på stedet understøttes. Alt du skal gøre er at køre apt upgrade eller yum update, og du er klar. Opgraderingen er endnu mere bekvem - førhen skulle man huske på at køre mysql_upgrade for at sikre, at alle systemtabeller er korrekt opgraderet til det format, der kræves af den nye version af MySQL. I MySQL 8.0, startende fra MySQL 8.0.16, er dette ikke længere nødvendigt - alt du skal gøre er at starte MySQL-processen, mysqld, og som standard vil opgraderingen blive udført over dataordbogen og andre systemskemaer, når det er bestemt at være påkrævet. Det er muligt at ændre denne adfærd ved at overføre forskellige parametre til --upgrade server option, men i de fleste tilfælde vil du gerne drage fordel af denne forbedring.
Er jeg sikker at opgradere?
Selvfølgelig er der forudsætninger for den sikre opgradering. Lad os tage et kig på nogle metoder, der skal hjælpe dig med at sikre, at du sikkert kan opgradere til MySQL 8.0.
Sanity Checks
Før du forsøger noget, bør du dobbelttjekke, at din eksisterende MySQL 5.7-opsætning afkrydser alle boksene på fornuftstjeklisten, før du opgraderer til MySQL 8.0. MySQL-dokumentationen præsenterer en omfattende liste over ting, der skal teste. Det giver ikke mening at gennemgå listen her, da den er dækket af MySQL-dokumentationen, men her er et par punkter, du måske bør huske på.
For det første understøttes partitionering nu kun i motorer, der implementerer det på deres side, som kun er NDB og InnoDB. Sørg for, at alle de partitionerede tabeller bruger en af disse lagermotorer, eller at du fjerner partitioneringen før opgraderingen.
Du vil måske køre
mysqlcheck -u root -p --all-databases --check-upgradefor at dobbelttjekke, at tabeller er i det korrekte format.
Der er også andre kontroller, du bør udføre - næsten hver ny MySQL-version kommer med en opdateret liste over reserverede ord, og du bør kontrollere, at du ikke bruger dem i din database. Du skal kontrollere navne på fremmednøgler, de må ikke være længere end 64 tegn. Nogle muligheder for sql_mode er blevet fjernet, så du bør sikre dig, at du ikke bruger dem. Som vi nævnte, er der en omfattende liste over ting at teste.
MySQL Shell til undsætning
At teste alle disse forhold er ret tidskrævende, derfor har Oracle oprettet en mulighed i MySQL Shell, der er beregnet til at køre en række tests for at verificere, om din eksisterende installation er sikker at opgradere til MySQL 8.0. For det første, hvis du ikke har MySQL Shell installeret, bør du gøre det. Du kan finde downloads på Oracles hjemmeside. Når du har konfigureret det, kan du oprette forbindelse til din MySQL 5.7 og køre testen. Lad os se, hvordan det kan se ud:
[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.Vi oprettede forbindelse til MySQL-instansen på den lokale vært ved hjælp af MySQL Shell. Nu kan vi køre kontrollen. Vi videregiver stien til konfigurationsfilen for mere omfattende test:
MySQL localhost:33060+ ssl JS > util.checkForServerUpgrade({"configPath":"/etc/mysql/my.cnf"})Så har vi et langt 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.Som du kan se, er der udført 21 tests i alt, kontrollen har fundet 3 fejl relateret til konfigurationsmulighederne, som ikke vil eksistere i MySQL 8.0.21. Testene er ret detaljerede. Du vil blandt andet lære om ændringer i standardværdierne for variabler, som du ikke har konfigureret i din MySQL-konfiguration (så disse indstillinger ændres, når du installerer MySQL 8.0).
Tilbageføring af en mislykket opgradering
Som vi nævnte før, kan du ikke nedgradere fra MySQL 8.0, når opgraderingen er fuldført. Heldigvis betyder det ikke, at du ikke kan rulle opgraderingen tilbage, hvis den mislykkes i midten. Faktisk sker det semi-automatisk, hvis et af de problemer, vi diskuterede i det foregående afsnit, opdages. Den eneste manuelle handling, der kræves, ville være at fjerne gentag-logfiler og starte MySQL 5.7 for at løse de problemer, der blev opdaget under opgraderingen. Så bør du udføre en langsom nedlukning (innodb_fast_shutdown=0) for at sikre, at alt er skrevet til tablespaces, og så er du klar til at prøve opgraderingen igen.
Sidste tip
Der er to ret vigtige ændringer i standardadfærden, der følger med MySQL 8.0, vi gerne vil fremhæve.
Caching_sha2_password som standard
Sørg venligst for, at du dobbelttjekker, om dine applikationer og proxyer fungerer korrekt med caching_sha2_password-godkendelsesplugin, da det bliver standard i MySQL 8.0. Ældre applikationer kan blive påvirket og ikke i stand til at oprette forbindelse til databasen. Selvfølgelig kan du ændre dette til det autentificerings-plugin du ønsker (som f.eks. mysql_native_password, da det var standard i tidligere MySQL-versioner), så det er på ingen måde en blokering. Det er bare noget, du skal huske at teste før opgraderingen, så du ikke ender med MySQL 8.0 og apps, der ikke kan oprette forbindelse til den, medmindre du omkonfigurerer din database til at bruge en ældre godkendelsesmekanisme.
UTF8mb4 som standardtegnsæt
Dette burde ikke komme som en overraskelse i betragtning af, hvor bredt ændret til UTF8 blev diskuteret i fællesskabet, men det er faktum - MySQL 8.0 kommer med UTF8mb4-tegnsæt som standard. Dette har en yderligere effekt, som du bør være opmærksom på. For det første kan dit datasæts størrelse øges, hvis du vil bruge UTF8mb4-tegnsæt. Dette fører til, at hukommelsesbuffere kan lagre mindre mængder data end for data med latin1-tegnsæt. For det andet forventes MySQL's ydeevne at blive reduceret. Nok, Oracle gjorde et godt stykke arbejde med at minimere virkningen af denne ændring, men du kan ikke forvente, at der ikke vil være nogen effekt på ydeevnen - det vil være nogle.
Vi håber, at dette blogindlæg vil hjælpe dig med at gennemgå processen med at opgradere fra MySQL 5.7 til MySQL 8.0. Hvis du har dine tanker om processen, opfordrer vi dig til at dele dem i kommentarerne under dette indlæg.