MySQL 8.0 har redan funnits med oss ganska länge och många MySQL-användare har redan uppgraderat till denna version. För de som fortfarande använder äldre MySQL-versioner vill vi presentera den här bloggen där vi kommer att dela med oss av några tips och information som hjälper till i uppgraderingsprocessen för MySQL 8.0.
Tänk på din version
Programversioner är ganska viktiga i uppgraderingsprocessen. Till att börja med stöds endast en större versionsskillnad. Du måste köra MySQL 5.7 innan du kan uppgradera till MySQL 8.0. Detta är ganska viktigt att komma ihåg med tanke på att MySQL 5.6 närmar sig slutet av livet och det kommer inte att stödjas längre. För alla er som använder MySQL 5.6 måste ni se till att uppgradera den till MySQL 5.7 först och sedan, så småningom, till MySQL 8.0.
Det som starkt rekommenderas är att du uppgraderar till den senaste versionen för MySQL 5.7. När jag skrev den här bloggen var den 5.7.31 men detta kommer så småningom att ändras, du kan alltid slå upp det på MySQL-webbplatsen.
Observera också att uppgraderingar från icke-GA-versioner (och till icke-GA-versioner) inte stöds. Inte för att det är meningsfullt att köra icke-GA-versioner i produktion, men vi ville göra detta tydligt också.
Det är en enkelbiljett
När du bestämmer dig för att utföra uppgraderingen, var medveten om att när uppgraderingen är klar finns det ingen återvändo. Ändringarna är inte kompatibla och du kan helt enkelt inte använda datakatalogen från MySQL 8.0 på MySQL 5.7. Se till att du tar en säkerhetskopia av dina MySQL 5.7-data direkt före uppgraderingen - du skulle kunna återställa den på MySQL 5.7-instans om du skulle behöva återställa ändringen. Tänk också på, eftersom det kan komma som en överraskning, att uppgradering från MySQL 8.0.x till MySQL 8.0.x+1 kanske inte heller är kompatibel och även om det är en mindre versionsuppgradering bör du inte förvänta dig den nedgraderingen skulle vara möjligt. Detta är resultatet av Oracles distributionscykel - istället för att göra funktionsfrysning för den senaste GA-grenen, som det var fallet med tidigare versioner, skjuts nya funktioner, ibland inkompatibla sådana, som nya versioner av 8.0-grenen.
In-Place Upgrade är en Go
Tidigare var det inte alltid möjligt att utföra en uppgradering av MySQL på plats. I vissa fall var du tvungen att dumpa data till SQL-format och sedan ladda upp den igen till den nya versionen. Lyckligtvis är MySQL 8.0 mer administratörsvänligt och uppgradering på plats stöds. Allt du behöver göra är att köra apt upgrade eller yum update och du är redo. Uppgraderingen är ännu bekvämare - tidigare var man tvungen att tänka på att köra mysql_upgrade för att säkerställa att alla systemtabeller är korrekt uppgraderade till det format som krävs av den nya versionen av MySQL. I MySQL 8.0, från och med MySQL 8.0.16, behövs detta inte längre - allt du behöver göra är att starta MySQL-processen, mysqld, och som standard kommer uppgraderingen att utföras över dataordboken och andra systemscheman närhelst det är bestämt sig för att krävas. Det är möjligt att ändra detta beteende genom att skicka olika parametrar till --upgrade server alternativet, men i de flesta fall skulle du vilja dra nytta av denna förbättring.
Är jag säker att uppgradera?
Naturligtvis finns det förutsättningar för den säkra uppgraderingen. Låt oss ta en titt på några metoder som bör hjälpa dig att säkerställa att du säkert kan uppgradera till MySQL 8.0.
Syndhetskontroller
Innan du försöker något bör du dubbelkolla att din befintliga MySQL 5.7-installation kryssar i alla rutorna på förnuftschecklistan innan du uppgraderar till MySQL 8.0. MySQL-dokumentationen presenterar en omfattande lista över saker att testa. Det är inte meningsfullt att gå igenom listan här eftersom den täcks av MySQL-dokumentationen, men här är ett par punkter som du kanske vill ha i åtanke.
För det första, partitionering stöds nu endast i motorer som implementerar det på sin sida, som endast är NDB och InnoDB. Se till att alla partitionerade tabeller använder någon av dessa lagringsmotorer eller att du tar bort partitioneringen före uppgraderingen.
Du kanske vill köra
mysqlcheck -u root -p --all-databases --check-upgradeför att dubbelkolla att tabeller har rätt format.
Det finns också andra kontroller som du bör utföra - nästan varje ny MySQL-version kommer med en uppdaterad lista med reserverade ord och du bör kontrollera att du inte använder dem i din databas. Du måste kontrollera namnen på främmande nyckelbegränsningar, de får inte vara längre än 64 tecken. Vissa alternativ för sql_mode har tagits bort så du bör se till att du inte använder dem. Som vi nämnde finns det en omfattande lista över saker att testa.
MySQL Shell till räddning
Att testa alla dessa villkor är ganska tidskrävande, därför skapade Oracle ett alternativ i MySQL-skalet som är avsett att köra en serie tester för att verifiera om din befintliga installation är säker att uppgradera till MySQL 8.0. Till att börja med, om du inte har MySQL Shell installerat, bör du göra det. Du kan hitta nedladdningar på Oracles webbplats. När du har ställt in det kan du ansluta till din MySQL 5.7 och köra testet. Låt oss se hur det kan se ut:
[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 kopplade till MySQL-instansen på den lokala värden med MySQL Shell. Nu kan vi köra kontrollen. Vi skickar sökvägen till konfigurationsfilen för mer omfattande tester:
MySQL localhost:33060+ ssl JS > util.checkForServerUpgrade({"configPath":"/etc/mysql/my.cnf"})Då har vi en lång utgång.
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 har totalt 21 tester utförts, kontrollen har hittat 3 fel relaterade till konfigurationsalternativen som inte kommer att existera i MySQL 8.0.21. Testerna är ganska detaljerade. Du kommer bland annat att lära dig om ändringar i standardvärdena för variabler som du inte har konfigurerat i din MySQL-konfiguration (så dessa inställningar kommer att ändras när du installerar MySQL 8.0).
Återställa en misslyckad uppgradering
Som vi nämnde tidigare kan du inte nedgradera från MySQL 8.0 när uppgraderingen är klar. Lyckligtvis betyder det inte att du inte kan återställa uppgraderingen om den misslyckas i mitten. Egentligen sker det halvautomatiskt om något av de problem som vi diskuterade i föregående avsnitt upptäcks. Den enda manuella åtgärd som krävs är att ta bort redo-loggar och starta MySQL 5.7 för att åtgärda problemen som upptäcktes under uppgraderingen. Sedan bör du göra en långsam avstängning (innodb_fast_shutdown=0) för att säkerställa att allt skrivs till tabellutrymmena och sedan är du redo att försöka uppgradera en gång till.
Sluta tips
Det finns två, ganska viktiga ändringar i standardbeteendet som följer med MySQL 8.0 som vi skulle vilja lyfta fram.
Caching_sha2_password som standard
Se till att du dubbelkolla om dina applikationer och proxyservrar kommer att fungera korrekt med plugin-programmet caching_sha2_password-autentisering eftersom det blir standard i MySQL 8.0. Äldre applikationer kan påverkas och inte kunna ansluta till databasen. Naturligtvis kan du ändra detta till vilken autentiseringsplugin du vill (som mysql_native_password till exempel, eftersom det var standard i tidigare MySQL-versioner) så det är inte en blockerare på något sätt. Det är bara något att komma ihåg att testa innan uppgraderingen så att du inte får MySQL 8.0 och appar som inte kan ansluta till den om du inte konfigurerar om din databas för att använda en äldre autentiseringsmekanism.
UTF8mb4 som standardteckenuppsättning
Detta borde inte komma som en överraskning med tanke på hur omfattande förändringar till UTF8 diskuterades i communityn, men det är faktum - MySQL 8.0 kommer med UTF8mb4-teckenuppsättning som standard. Detta har ytterligare effekter som du bör vara medveten om. För det första kan din datauppsättnings storlek öka om du använder UTF8mb4 teckenuppsättning. Detta leder till att minnesbuffertar kan lagra mindre mängder data än för data med latin1 teckenuppsättning. För det andra förväntas prestanda för MySQL att minska. Visst, Oracle gjorde ett bra jobb med att minimera effekten av den här förändringen, men du kan inte förvänta dig att det inte kommer att bli någon effekt alls – det kommer att bli en del.
Vi hoppas att det här blogginlägget hjälper dig att gå igenom processen med att uppgradera från MySQL 5.7 till MySQL 8.0. Om du har dina tankar om processen uppmuntrar vi dig att dela dem i kommentarerna under det här inlägget.