Mysql
 sql >> Baza danych >  >> RDS >> Mysql

Wskazówki dotyczące aktualizacji z MySQL 5.7 do MySQL 8

MySQL 8.0 jest z nami już od dłuższego czasu i wielu użytkowników MySQL już zaktualizowało do tej wersji. Dla tych, którzy nadal używają starszych wersji MySQL, chcielibyśmy zaprezentować ten blog, w którym podzielimy się wskazówkami i informacjami, które pomogą w procesie aktualizacji do MySQL 8.0.

Uważaj na swoją wersję

Wersje oprogramowania są dość ważne w procesie aktualizacji. Na początek obsługiwana jest tylko jedna główna różnica wersji. Musisz uruchomić MySQL 5.7, zanim będziesz mógł dokonać aktualizacji do MySQL 8.0. Należy o tym pamiętać, biorąc pod uwagę, że MySQL 5.6 zbliża się do końca życia i nie będzie już wspierany. Wszyscy, którzy używają MySQL 5.6, powinni najpierw zaktualizować go do MySQL 5.7, a następnie do MySQL 8.0.

Zdecydowanie zalecamy uaktualnienie do najnowszej dostępnej wersji MySQL 5.7. W momencie pisania tego bloga był to 5.7.31, ale w końcu to się zmieni, zawsze możesz go sprawdzić na stronie MySQL.

Pamiętaj również, że aktualizacje z wersji innych niż GA (i do wersji innych niż GA) nie są obsługiwane. Nie żeby miało sens uruchamianie wersji innych niż GA w produkcji, ale chcieliśmy, aby to było jasne.

To bilet w jedną stronę

Za każdym razem, gdy zdecydujesz się przeprowadzić aktualizację, pamiętaj, że po zakończeniu aktualizacji nie ma już powrotu. Zmiany nie są kompatybilne i po prostu nie można używać katalogu danych z MySQL 8.0 na MySQL 5.7. Upewnij się, że wykonałeś kopię zapasową danych MySQL 5.7 bezpośrednio przed aktualizacją - będziesz mógł ją przywrócić na instancji MySQL 5.7, jeśli zajdzie potrzeba cofnięcia zmiany. Należy również pamiętać, ponieważ może to być niespodzianką, że aktualizacja z MySQL 8.0.x do MySQL 8.0.x+1 może być również niekompatybilna i mimo że jest to aktualizacja wersji mniejszej, nie należy oczekiwać, że nastąpi jej downgrade byłaby możliwa. Jest to wynik cyklu wdrażania Oracle – zamiast zamrożenia funkcji dla najnowszej gałęzi GA, jak to miało miejsce w poprzednich wersjach, nowe funkcje, czasem niekompatybilne, są wprowadzane jako nowe wydania gałęzi 8.0.

Uaktualnienie w miejscu to dobry pomysł

W przeszłości nie zawsze było możliwe wykonanie uaktualnienia MySQL w miejscu. W niektórych przypadkach byłeś zmuszony zrzucić dane do formatu SQL, a następnie załadować je z powrotem do nowej wersji. Na szczęście MySQL 8.0 jest bardziej przyjazny dla administratorów i wspierana jest aktualizacja w miejscu. Wszystko, co musisz zrobić, to uruchomić aktualizację apt lub aktualizację yum i gotowe. Aktualizacja jest jeszcze wygodniejsza - w przeszłości trzeba było pamiętać o uruchomieniu mysql_upgrade, aby upewnić się, że wszystkie tabele systemowe są poprawnie uaktualnione do formatu wymaganego przez nową wersję MySQL. W MySQL 8.0, począwszy od MySQL 8.0.16, nie jest to już potrzebne - wystarczy uruchomić proces MySQL, mysqld, a domyślnie aktualizacja będzie wykonywana na słowniku danych i innych schematach systemowych, gdy tylko będzie określone jako wymagane. Można zmienić to zachowanie, przekazując różne parametry do opcji --upgrade serwera, ale w większości przypadków chciałbyś skorzystać z tej poprawy.

Czy mogę dokonać aktualizacji?

Oczywiście istnieją warunki wstępne dla bezpiecznego uaktualnienia. Rzućmy okiem na kilka metod, które powinny pomóc w bezpiecznym uaktualnieniu do MySQL 8.0.

Kontrole sprawności

Zanim podejmiesz jakąkolwiek próbę, przed aktualizacją do MySQL 8.0 upewnij się, że istniejąca konfiguracja MySQL 5.7 spełnia wszystkie pola na liście kontrolnej. Dokumentacja MySQL przedstawia obszerną listę rzeczy do przetestowania. Nie ma sensu przeglądać tej listy, ponieważ jest ona opisana w dokumentacji MySQL, ale oto kilka punktów, o których warto pamiętać.

Po pierwsze, partycjonowanie jest teraz obsługiwane tylko w silnikach, które implementują go na swoim końcu, czyli tylko NDB i InnoDB. Upewnij się, że wszystkie partycjonowane tabele korzystają z jednego z tych silników pamięci masowej lub że przed aktualizacją usunięto partycjonowanie.

Możesz chcieć biegać

mysqlcheck -u root -p --all-databases --check-upgrade

aby dokładnie sprawdzić, czy tabele są w odpowiednim formacie.

Istnieją również inne kontrole, które powinieneś wykonać – prawie każda nowa wersja MySQL zawiera zaktualizowaną listę słów zastrzeżonych i powinieneś sprawdzić, czy nie używasz ich w swojej bazie danych. Należy sprawdzić nazwy ograniczeń kluczy obcych, nie mogą one być dłuższe niż 64 znaki. Niektóre opcje trybu sql_mode zostały usunięte, dlatego należy się upewnić, że ich nie używasz. Jak wspomnieliśmy, istnieje obszerna lista rzeczy do przetestowania.

Powłoka MySQL na ratunek

Testowanie wszystkich tych warunków jest dość czasochłonne, dlatego Oracle stworzyło opcję w powłoce MySQL, która ma na celu przeprowadzenie serii testów w celu sprawdzenia, czy istniejąca instalacja jest bezpieczna przy aktualizacji do MySQL 8.0. Na początek, jeśli nie masz zainstalowanego MySQL Shell, powinieneś to zrobić. Pliki do pobrania można znaleźć na stronie Oracle. Po skonfigurowaniu możesz połączyć się z MySQL 5.7 i uruchomić test. Zobaczmy, jak to może wyglądać:

[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.

Połączyliśmy się z instancją MySQL na hoście lokalnym za pomocą powłoki MySQL. Teraz możemy przeprowadzić kontrolę. Przekażemy ścieżkę do pliku konfiguracyjnego dla bardziej rozbudowanych testów:

MySQL  localhost:33060+ ssl  JS > util.checkForServerUpgrade({"configPath":"/etc/mysql/my.cnf"})

W takim razie mamy długi wynik.

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 widać, w sumie wykonano 21 testów, sprawdzenie wykryło 3 błędy związane z opcjami konfiguracyjnymi, które nie będą występowały w MySQL 8.0.21. Testy są dość szczegółowe. Między innymi dowiesz się o zmianach w domyślnych wartościach zmiennych, których nie skonfigurowałeś w swojej konfiguracji MySQL (więc te ustawienia zmienią się po zainstalowaniu MySQL 8.0).

Wycofywanie nieudanej aktualizacji

Jak wspomnieliśmy wcześniej, nie można przejść na starszą wersję MySQL 8.0 po zakończeniu aktualizacji. Na szczęście nie oznacza to, że nie możesz cofnąć aktualizacji, jeśli nie powiedzie się w środku. Właściwie dzieje się to półautomatycznie, jeśli zostanie wykryty jeden z problemów, które omówiliśmy w poprzedniej sekcji. Jedyną ręczną czynnością, która jest wymagana, jest usunięcie dzienników przeróbek i uruchomienie MySQL 5.7 w celu rozwiązania problemów wykrytych podczas aktualizacji. Następnie powinieneś wykonać powolne zamknięcie (innodb_fast_shutdown=0), aby upewnić się, że wszystko jest zapisane w obszarach tabel, a następnie możesz ponownie spróbować uaktualnienia.

Końcowe wskazówki

Chcielibyśmy podkreślić dwie dość ważne zmiany w domyślnym zachowaniu, które jest dostarczane z MySQL 8.0.

Caching_sha2_password jako domyślne

Upewnij się, że dokładnie sprawdziłeś, czy Twoje aplikacje i serwery proxy będą działać poprawnie z wtyczką uwierzytelniającą caching_sha2_password, ponieważ staje się ona domyślną w MySQL 8.0. Może to mieć wpływ na starsze aplikacje i nie mogą one połączyć się z bazą danych. Oczywiście możesz to zmienić na dowolną wtyczkę uwierzytelniającą (na przykład mysql_native_password, ponieważ była domyślna w poprzednich wersjach MySQL), więc nie jest to w żaden sposób bloker. Należy tylko pamiętać o przetestowaniu przed aktualizacją, aby nie skończyć z MySQL 8.0 i aplikacjami, które nie mogą się z nim połączyć, chyba że zmienisz konfigurację bazy danych tak, aby korzystała ze starszego mechanizmu uwierzytelniania.

UTF8mb4 jako domyślny zestaw znaków

Nie powinno to dziwić, biorąc pod uwagę, jak szeroko dyskutowano w społeczności o zmianie na UTF8, ale to jest fakt – MySQL 8.0 jest dostarczany z zestawem znaków UTF8mb4 jako domyślnym. Ma to dodatkowy wpływ, o którym powinieneś wiedzieć. Po pierwsze, rozmiar zestawu danych może wzrosnąć, jeśli użyjesz zestawu znaków UTF8mb4. Prowadzi to do tego, że bufory pamięci mogą przechowywać mniejsze ilości danych niż w przypadku danych z zestawem znaków latin1. Po drugie, oczekuje się, że wydajność MySQL zostanie zmniejszona. Jasne, Oracle wykonało świetną robotę, minimalizując wpływ tej zmiany, ale nie można oczekiwać, że nie będzie to miało żadnego wpływu na wydajność — będzie to trochę.

Mamy nadzieję, że ten wpis na blogu pomoże Ci przejść przez proces aktualizacji z MySQL 5.7 do MySQL 8.0. Jeśli masz swoje przemyślenia na temat tego procesu, zachęcamy do podzielenia się nimi w komentarzach pod tym postem.


  1. Database
  2.   
  3. Mysql
  4.   
  5. Oracle
  6.   
  7. Sqlserver
  8.   
  9. PostgreSQL
  10.   
  11. Access
  12.   
  13. SQLite
  14.   
  15. MariaDB
  1. Oblicz percentyl w MySQL na podstawie sum

  2. Przewodnik po zrozumieniu wzorców skalowania bazy danych

  3. Samouczek dotyczący tworzenia kopii zapasowych i przywracania (eksportowania i importowania) baz danych MySQL

  4. Zwracanie „ostatniego” wiersza każdego „grupuj według” w MySQL

  5. Jak działa funkcja REGEX_REPLACE() w MySQL