MySQL 8.0 je s námi již nějakou dobu a mnoho uživatelů MySQL již upgradovalo na tuto verzi. Pro ty, kteří stále používají starší verze MySQL, bychom rádi představili tento blog, kde se podělíme o několik tipů a informací, které pomohou v procesu upgradu na MySQL 8.0.
Dejte si pozor na verzi
Verze softwaru jsou v procesu upgradu docela důležité. Pro začátek je podporován pouze jeden hlavní rozdíl verzí. Než budete moci upgradovat na MySQL 8.0, musíte používat MySQL 5.7. To je docela důležité mít na paměti, protože MySQL 5.6 se blíží ke konci své životnosti a již nebude podporován. Vy všichni, kteří používáte MySQL 5.6, se musíte ujistit, že ji nejprve upgradujete na MySQL 5.7 a poté případně na MySQL 8.0.
Důrazně doporučujeme upgradovat na nejnovější verzi dostupnou pro MySQL 5.7. V době psaní tohoto blogu to bylo 5.7.31, ale to se časem změní, vždy si to můžete vyhledat na webu MySQL.
Upozorňujeme také, že upgrady z verzí bez GA (a na verze bez GA) nejsou podporovány. Ne, že by mělo smysl provozovat verze bez GA v produkci, ale chtěli jsme to také objasnit.
Jedná se o jednosměrnou letenku
Kdykoli se rozhodnete provést upgrade, mějte na paměti, že jakmile bude aktualizace dokončena, není možné se vrátit. Změny nejsou kompatibilní a na MySQL 5.7 prostě nemůžete použít datový adresář z MySQL 8.0. Ujistěte se, že jste si zálohovali data MySQL 5.7 přímo před upgradem – budete je moci obnovit na instanci MySQL 5.7, pokud budete potřebovat vrátit změnu. Mějte prosím také na paměti, protože to může být překvapením, že upgrade z MySQL 8.0.x na MySQL 8.0.x+1 také nemusí být kompatibilní, a přestože se jedná o upgrade menší verze, neměli byste očekávat, že downgrade by bylo možné. Je to výsledek zaváděcího cyklu společnosti Oracle – namísto zmrazování funkcí pro nejnovější větev GA, jak tomu bylo u předchozích verzí, jsou nové funkce, někdy nekompatibilní, tlačeny jako nová vydání větve 8.0.
Aktualizace na místě je samozřejmostí
V minulosti nebylo vždy možné provést upgrade MySQL na místě. V některých případech jste byli nuceni uložit data do formátu SQL a poté je načíst zpět do nové verze. Naštěstí je MySQL 8.0 přívětivější pro správu a je podporován upgrade na místě. Vše, co musíte udělat, je spustit apt upgrade nebo yum update a máte hotovo. Upgrade je ještě pohodlnější – v minulosti bylo nutné mít na paměti spuštění mysql_upgrade, aby bylo zajištěno, že všechny systémové tabulky budou správně upgradovány na formát požadovaný novou verzí MySQL. V MySQL 8.0, počínaje MySQL 8.0.16, to již není potřeba – vše, co musíte udělat, je spustit proces MySQL, mysqld a ve výchozím nastavení se upgrade provede přes datový slovník a další systémová schémata, kdykoli bude potřeba. určeno jako vyžadováno. Toto chování je možné změnit předáním různých parametrů možnosti --upgrade serveru, ale ve většině případů byste rádi z tohoto vylepšení měli prospěch.
Jsem bezpečný pro upgrade?
Samozřejmě existují předpoklady pro bezpečný upgrade. Pojďme se podívat na některé metody, které by vám měly pomoci zajistit bezpečný upgrade na MySQL 8.0.
Kontrola zdravého rozumu
Než se o něco pokusíte, měli byste před upgradem na MySQL 8.0 znovu zkontrolovat, zda vaše stávající nastavení MySQL 5.7 zaškrtává všechna políčka v kontrolním seznamu zdravého rozumu. Dokumentace MySQL představuje rozsáhlý seznam věcí k testování. Nemá smysl procházet zde seznam, protože je zahrnut v dokumentaci MySQL, ale zde je několik bodů, které byste možná chtěli mít na paměti.
Za prvé, dělení je nyní podporováno pouze u motorů, které jej implementují na svém konci, což jsou pouze NDB a InnoDB. Ujistěte se prosím, že všechny rozdělené tabulky používají jeden z těchto modulů úložiště, nebo že před upgradem odstraníte rozdělení.
Možná budete chtít běhat
mysqlcheck -u root -p --all-databases --check-upgradedvakrát zkontrolujte, zda jsou tabulky ve správném formátu.
Existují také další kontroly, které byste měli provést – téměř každá nová verze MySQL přichází s aktualizovaným seznamem vyhrazených slov a měli byste zkontrolovat, zda je ve své databázi nepoužíváte. Musíte zkontrolovat názvy omezení cizího klíče, nesmí být delší než 64 znaků. Některé možnosti pro sql_mode byly odstraněny, takže byste se měli ujistit, že je nepoužíváte. Jak jsme zmínili, existuje rozsáhlý seznam věcí k testování.
MySQL Shell k záchraně
Testování všech těchto podmínek je poměrně časově náročné, proto Oracle vytvořil možnost v prostředí MySQL Shell, která je určena ke spuštění série testů k ověření, zda je vaše stávající instalace bezpečná pro upgrade na MySQL 8.0. Pro začátek, pokud nemáte nainstalovaný MySQL Shell, měli byste to udělat. Soubory ke stažení najdete na webu Oracle. Jakmile jej nastavíte, můžete se připojit k MySQL 5.7 a spustit test. Pojďme se podívat, jak to může vypadat:
[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.Připojili jsme se k instanci MySQL na localhost pomocí prostředí MySQL. Nyní můžeme provést kontrolu. Předáme cestu ke konfiguračnímu souboru pro rozsáhlejší testy:
MySQL localhost:33060+ ssl JS > util.checkForServerUpgrade({"configPath":"/etc/mysql/my.cnf"})Pak máme dlouhý výstup.
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.Jak můžete vidět, bylo provedeno celkem 21 testů, kontrola našla 3 chyby související s možnostmi konfigurace, které v MySQL 8.0.21 nebudou existovat. Testy jsou poměrně podrobné. Mimo jiné se dozvíte o změnách výchozích hodnot proměnných, které nemáte nakonfigurované v konfiguraci MySQL (takže tato nastavení se po instalaci MySQL 8.0 změní).
Vrácení zpět neúspěšného upgradu
Jak jsme již zmínili, po dokončení upgradu nelze přejít na nižší verzi MySQL 8.0. Naštěstí to neznamená, že nemůžete upgrade vrátit, pokud selže uprostřed. Ve skutečnosti se to stane poloautomaticky, pokud je zjištěn jeden z problémů, o kterých jsme hovořili v předchozí části. Jedinou ruční akcí, která je vyžadována, by bylo odstranění opakovaných protokolů a spuštění MySQL 5.7 k vyřešení problémů zjištěných během upgradu. Poté byste měli provést pomalé vypnutí (innodb_fast_shutdown=0), abyste se ujistili, že je vše zapsáno do tabulkových prostorů, a poté můžete zkusit upgrade ještě jednou.
Poslední tipy
Chtěli bychom zdůraznit dvě, docela důležité změny ve výchozím chování, které přichází s MySQL 8.0.
Caching_sha2_password jako výchozí
Ujistěte se prosím, že jste znovu zkontrolovali, zda vaše aplikace a proxy budou správně fungovat s pluginem pro ověřování caching_sha2_password, protože se stává výchozím v MySQL 8.0. Starší aplikace mohou být ovlivněny a nebudou se moci připojit k databázi. Samozřejmě to můžete změnit na jakýkoli ověřovací plugin, který chcete (jako například mysql_native_password, protože to bylo výchozí v předchozích verzích MySQL), takže to v žádném případě není blokátor. Je to jen něco, co je třeba před upgradem otestovat, abyste neskončili s MySQL 8.0 a aplikacemi, které se k ní nebudou moci připojit, pokud nezměníte konfiguraci databáze tak, aby používala starší mechanismus ověřování.
UTF8mb4 jako výchozí znaková sada
To by nemělo být překvapením vzhledem k tomu, jak široce se v komunitě diskutovalo o změně na UTF8, ale je to tak – MySQL 8.0 přichází se znakovou sadou UTF8mb4 jako výchozí. To má další dopad, kterého byste si měli být vědomi. Za prvé, velikost vaší datové sady se může zvýšit, pokud použijete znakovou sadu UTF8mb4. To vede k tomu, že vyrovnávací paměti mohou ukládat menší množství dat než data se znakovou sadou latin1. Za druhé, očekává se snížení výkonu MySQL. Jistě, Oracle odvedl skvělou práci při minimalizaci dopadu této změny, ale nemůžete očekávat, že nebude mít žádný dopad na výkon – nějaký bude.
Doufáme, že vám tento příspěvek na blogu pomůže projít procesem upgradu z MySQL 5.7 na MySQL 8.0. Pokud máte své názory na tento proces, doporučujeme vám je sdílet v komentářích pod tímto příspěvkem.