Mysql
 sql >> база данни >  >> RDS >> Mysql

Съвети за надграждане от MySQL 5.7 до MySQL 8

MySQL 8.0 е с нас от доста време и много потребители на MySQL вече са надстроили до тази версия. За тези, които все още използват по-стари версии на MySQL, бихме искали да представим този блог, където ще споделим някои съвети и информация, които ще помогнат в процеса на надстройка за MySQL 8.0.

Внимавайте за вашата версия

Софтуерните версии са доста важни в процеса на надстройка. За начало се поддържа само една основна разлика във версията. Трябва да използвате MySQL 5.7, преди да можете да надстроите до MySQL 8.0. Това е доста важно да се има предвид, като се има предвид, че MySQL 5.6 наближава своя край на живота и вече няма да се поддържа. За всички вас, които използвате MySQL 5.6, трябва да се уверите, че сте го надстроили първо до MySQL 5.7 и след това, евентуално, до MySQL 8.0.

Това, което силно се препоръчва, е да надстроите до най-новата версия, налична за MySQL 5.7. Към момента на писане на този блог беше 5.7.31, но това в крайна сметка ще се промени, винаги можете да го потърсите на уебсайта на MySQL.

Моля, имайте предвид също, че не се поддържат надстройки от не-GA (и до не-GA) версии. Не че има смисъл да се пускат версии, различни от GA, в производство, но искахме да изясним и тази.

Това е еднопосочен билет

Всеки път, когато решите да извършите надстройката, моля, имайте предвид, че след като надстройката приключи, няма връщане назад. Промените не са съвместими и просто не можете да използвате директорията с данни от MySQL 8.0 на MySQL 5.7. Уверете се, че сте направили резервно копие на вашите MySQL 5.7 данни непосредствено преди надстройката - ще можете да го възстановите на MySQL 5.7 екземпляр, ако трябва да върнете промяната. Моля, имайте предвид също, тъй като може да бъде изненада, че надстройката от MySQL 8.0.x до MySQL 8.0.x+1 може също да не е съвместима и, въпреки че е незначителна надстройка на версията, не трябва да очаквате това понижаване би било възможно. Това е резултат от цикъла на внедряване на Oracle – вместо да се прави замразяване на функции за най-новия клон на GA, както беше в предишните версии, новите функции, понякога несъвместими, се избутват като нови версии на клон 8.0.

Надстройването на място е лесно

В миналото не винаги е било възможно да се извърши надграждане на MySQL на място. В някои случаи сте били принудени да изхвърлите данните в SQL формат и след това да ги заредите обратно в новата версия. За щастие MySQL 8.0 е по-удобен за администратора и се поддържа надстройка на място. Всичко, което трябва да направите, е да стартирате apt upgrade или yum update и сте готови. Надстройката е още по-удобна - в миналото трябваше да се има предвид да се стартира mysql_upgrade, за да се гарантира, че всички системни таблици са правилно надстроени до формата, изискван от новата версия на MySQL. В MySQL 8.0, започвайки от MySQL 8.0.16, това вече не е необходимо - всичко, което трябва да направите, е да стартирате MySQL процес, mysqld и по подразбиране надграждането ще се извършва през речника на данните и други системни схеми, когато е определено е необходимо. Възможно е да промените това поведение, като подадете различни параметри на опцията --upgrade сървъра, но в повечето случаи бихте искали да се възползвате от това подобрение.

Безопасен ли е да надстроя?

Разбира се, има предпоставки за безопасното надграждане. Нека да разгледаме някои методи, които трябва да ви помогнат да гарантирате, че можете безопасно да надстроите до MySQL 8.0.

Проверки за здравина

Преди да опитате каквото и да е, трябва да проверите отново дали съществуващата ви настройка на MySQL 5.7 поставя отметки във всички квадратчета в контролния списък за здравина, преди да надстроите до MySQL 8.0. Документацията на MySQL представя обширен списък от неща за тестване. Няма смисъл да преглеждате списъка тук, тъй като е обхванат в документацията на MySQL, но ето няколко точки, които може да искате да имате предвид.

Първо, разделянето на дялове вече се поддържа само в двигатели, които го прилагат от своя край, които са само NDB и InnoDB. Моля, уверете се, че всички разделени таблици използват една от тези машини за съхранение или че премахвате разделянето преди надстройката.

Може да искате да бягате

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

за да проверите отново дали таблиците са в правилния формат.

Има и други проверки, които трябва да извършите - почти всяка нова версия на MySQL идва с актуализиран списък с запазени думи и трябва да проверите дали не ги използвате във вашата база данни. Трябва да проверите имената на ограниченията на външния ключ, те не могат да бъдат по-дълги от 64 знака. Някои опции за sql_mode са премахнати, така че трябва да се уверите, че не ги използвате. Както споменахме, има обширен списък с неща за тестване.

MySQL Shell за спасяване

Тестването на всички тези условия отнема доста време, затова Oracle създаде опция в MySQL Shell, която има за цел да изпълни серия от тестове, за да провери дали съществуващата ви инсталация е безопасна за надграждане до MySQL 8.0. Като за начало, ако нямате инсталиран MySQL Shell, трябва да го направите. Можете да намерите изтегляния на уебсайта на Oracle. След като го настроите, можете да се свържете с вашия MySQL 5.7 и да стартирате теста. Нека видим как може да изглежда:

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

Свързахме се с MySQL екземпляр на локалния хост, използвайки MySQL Shell. Сега можем да изпълним проверката. Ще предадем пътя към конфигурационния файл за по-обширни тестове:

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

Тогава имаме дълъг изход.

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.

Както можете да видите, извършени са общо 21 теста, проверката е открила 3 ​​грешки, свързани с опциите за конфигурация, които няма да съществуват в MySQL 8.0.21. Тестовете са доста подробни. Наред с други неща, ще научите за промените в стойностите по подразбиране за променливи, които не сте конфигурирали във вашата MySQL конфигурация (така че тези настройки ще се променят, след като инсталирате MySQL 8.0).

Отмяна на неуспешно надстройка

Както споменахме по-рано, не можете да понижите версията си от MySQL 8.0, след като надстройката приключи. За щастие, това не означава, че не можете да върнете надстройката, ако се провали в средата. Всъщност това се случва полуавтоматично, ако бъде открит един от проблемите, които обсъждахме в предишния раздел. Единственото ръчно действие, което се изисква, би било да премахнете регистрационните файлове за повторение и да стартирате MySQL 5.7, за да разрешите проблемите, открити по време на надстройката. След това трябва да извършите бавно изключване (innodb_fast_shutdown=0), за да се уверите, че всичко е записано в пространствата за таблици и след това сте готови да опитате надстройката още веднъж.

Последни съвети

Има две доста важни промени в поведението по подразбиране, което идва с MySQL 8.0, които бихме искали да подчертаем.

Caching_sha2_password по подразбиране

Моля, уверете се, че сте проверили отново дали вашите приложения и прокси сървъри ще работят правилно с caching_sha2_password плъгин за удостоверяване, тъй като той става по подразбиране в MySQL 8.0. По-старите приложения може да бъдат засегнати и да не могат да се свържат с базата данни. Разбира се, можете да промените това на какъвто плъгин за удостоверяване искате (като mysql_native_password например, тъй като беше по подразбиране в предишните версии на MySQL), така че да не е блокиращ по никакъв начин. Това е нещо, което трябва да запомните да тествате преди надстройката, за да не се окажете с MySQL 8.0 и приложения, които не могат да се свържат с него, освен ако не конфигурирате базата си данни да използва по-стар механизъм за удостоверяване.

UTF8mb4 като набор от знаци по подразбиране

Това не трябва да е изненада, като се има предвид колко широко се обсъждаше промяната на UTF8 в общността, но това е факт - MySQL 8.0 идва с UTF8mb4 набор от знаци по подразбиране. Това има някакво допълнително въздействие, за което трябва да сте наясно. Първо, размерът на вашия набор от данни може да се увеличи, ако използвате UTF8mb4 набор от знаци. Това води до това, че буферите на паметта могат да съхраняват по-малки количества данни, отколкото за данни с latin1 charset. Второ, очаква се производителността на MySQL да бъде намалена. Разбира се, Oracle свърши страхотна работа за минимизиране на въздействието на тази промяна, но не можете да очаквате, че няма да има никакво въздействие върху производителността - ще бъде известно.

Надяваме се тази публикация в блога да ви помогне да преминете през процеса на надграждане от MySQL 5.7 до MySQL 8.0. Ако имате своите мисли за процеса, препоръчваме ви да ги споделите в коментарите под тази публикация.


  1. Database
  2.   
  3. Mysql
  4.   
  5. Oracle
  6.   
  7. Sqlserver
  8.   
  9. PostgreSQL
  10.   
  11. Access
  12.   
  13. SQLite
  14.   
  15. MariaDB
  1. Има ли някакъв начин да се провери производителността на mysql Indexing

  2. разделен със запетая низ от избрани стойности в mysql

  3. Какъв тип/дължина на колона трябва да използвам за съхраняване на хеширана парола на Bcrypt в база данни?

  4. Как да създадете база данни в MySQL

  5. xampp MySQL не се стартира