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

Преминаване от MySQL 5.7 към MySQL 8.0 - Какво трябва да знаете

Април 2018 г. не е просто дата за света на MySQL. MySQL 8.0 беше пуснат там и повече от 1 година след това вероятно е време да помислите за мигриране към тази нова версия.

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

В този блог ще споменем някои от новите функции на MySQL 8.0, някои оттеглени неща и това, което трябва да имате предвид, преди да мигрирате.

Какво е новото в MySQL 8.0?

Нека сега да обобщим някои от най-важните функции, споменати в официалната документация за тази нова версия на MySQL.

  • MySQL включва речник на транзакционни данни, който съхранява информация за обекти на база данни.
  • Атомарен DDL израз комбинира актуализациите на речника на данните, операциите на механизма за съхранение и записите в двоичен дневник, свързани с DDL операция, в една атомна транзакция.
  • Сървърът MySQL автоматично изпълнява всички необходими задачи за надграждане при следващото стартиране, за да надстрои системните таблици в схемата на mysql, както и обекти в други схеми, като например системната схема и потребителските схеми. Не е необходимо DBA да извиква mysql_upgrade.
  • Поддържа създаването и управлението на групи ресурси и позволява присвояване на нишки, изпълнявани в сървъра, към определени групи, така че нишките да се изпълняват според ресурсите, налични за групата.
  • Криптирането на таблицата вече може да се управлява глобално чрез дефиниране и прилагане на стандартни настройки за криптиране. Променливата default_table_encryption дефинира криптиране по подразбиране за новосъздадени схеми и общо пространство за таблици. Стандартните настройки за криптиране се прилагат чрез активиране на променливата table_encryption_privilege_check.
  • Наборът от символи по подразбиране е променен от latin1 на utf8mb4.
  • Поддържа използването на изрази като стойности по подразбиране в спецификациите на типа данни. Това включва използването на изрази като стойности по подразбиране за типовете данни BLOB, TEXT, GEOMETRY и JSON.
  • Регистрирането на грешки е пренаписано, за да се използва архитектурата на компонента MySQL. Традиционното регистриране на грешки се реализира с помощта на вградени компоненти, а регистрирането с помощта на системния регистрационен файл е реализирано като зареждаем компонент.
  • Нов тип заключване на архивиране позволява DML по време на онлайн архивиране, като същевременно предотвратява операции, които могат да доведат до непоследователна моментна снимка. Новото заключване на архивиране се поддържа от LOCK INSTANCE FOR BACKUP и UNLOCK INSTANCE синтаксис. За използването на тези изрази е необходимо привилегията BACKUP_ADMIN.
  • MySQL Server вече позволява TCP/IP порт да бъде конфигуриран специално за административни връзки. Това осигурява алтернатива на единичната административна връзка, която е разрешена на мрежовите интерфейси, използвани за обикновени връзки, дори когато max_connections връзките вече са установени.
  • Поддържа невидими индекси. Този индекс не се използва от оптимизатора и дава възможност да се тества ефектът от премахването на индекс върху производителността на заявката, без да се премахва.
  • Съхранение за документи за разработване както на SQL, така и на NoSQL приложения за документи с помощта на една база данни.
  • MySQL 8.0 прави възможно запазването на глобални, динамични сървърни променливи с помощта на командата SET PERSIST вместо обичайната SET GLOBAL.

Сигурност и управление на акаунти на MySQL

Тъй като има много подобрения, свързани със сигурността и управлението на потребителите, ще ги изброим в отделен раздел.

  • Таблиците за предоставяне в системната база данни на mysql вече са таблици на InnoDB.
  • Новата добавка за caching_sha2_password за удостоверяване вече е методът за удостоверяване по подразбиране в MySQL 8.0. Той внедрява SHA-256 хеширане на пароли, но използва кеширане за справяне с проблеми със закъснението по време на свързване. Той осигурява по-сигурно криптиране на парола от приставката mysql_native_password и осигурява по-добра производителност от sha256_password.
  • MySQL вече поддържа роли, които са наречени колекции от привилегии. Ролите могат да имат привилегии, предоставени и отнети от тях, и те могат да бъдат предоставени и отменени от потребителски акаунти.
  • MySQL вече поддържа информация за историята на паролите, позволявайки ограничения за повторно използване на предишни пароли.
  • Позволява на администраторите да конфигурират потребителски акаунти така, че твърде много последователни грешки при влизане поради неправилни пароли да доведат до временно заключване на акаунта.

Подобрения на InnoDB

Както предишната точка, има и много подобрения, свързани с тази тема, така че ще ги изброим и в отделен раздел.

  • Текущата максимална стойност на брояча за автоматично увеличение се записва в дневника за повторно изпълнение всеки път, когато стойността се промени, и се записва в таблица на частната система на двигателя на всяка контролна точка. Тези промени правят текущата максимална стойност на брояча за автоматично увеличение постоянна при рестартиране на сървъра
  • Когато срещне повреда на индексното дърво, InnoDB записва флаг за повреда в дневника за повторно изпълнение, което прави флага за повреда безопасен при срив. InnoDB също така записва данни за флаг за повреда в паметта в таблица на частната система на двигателя на всяка контролна точка. По време на възстановяването InnoDB чете флагове за повреда от двете места и обединява резултатите, преди да маркира таблиците и индексните обекти в паметта като повредени.
  • Нова динамична променлива, innodb_deadlock_detect, може да се използва за деактивиране на откриването на застой. При системи с висок паралел, откриването на блокиране може да причини забавяне, когато множество нишки чакат за едно и също заключване. Понякога може да е по-ефективно да деактивирате откриването на безизходица и да разчитате на настройката innodb_lock_wait_timeout за връщане на транзакцията, когато възникне блокиране.
  • Временните таблици на InnoDB вече се създават в споделеното временно пространство за таблици, ibtmp1.
  • Системните таблици на mysql и таблиците с речник на данни вече се създават в един файл на пространството за таблици InnoDB с име mysql.ibd в директорията с данни на MySQL. Преди това тези таблици бяха създадени в отделни файлове на пространството за таблици InnoDB в директорията на базата данни mysql.
  • По подразбиране регистрационните файлове за отмяна вече се намират в две пространства за таблици за отмяна, които се създават, когато MySQL екземплярът е инициализиран. Регистрите за отмяна вече не се създават в системното пространство за таблици.
  • Новата променлива innodb_dedicated_server, която е деактивирана по подразбиране, може да се използва, за да може InnoDB автоматично да конфигурира следните опции според количеството памет, открита на сървъра:innodb_buffer_pool_size, innodb_log_file_size и innodb_flush_method. Тази опция е предназначена за сървърни екземпляри на MySQL, които работят на специален сървър.
  • Файловете на пространството за таблици могат да бъдат преместени или възстановени на ново място, докато сървърът е офлайн, като се използва опцията innodb_directories.

Сега нека да разгледаме някои от функциите, които не трябва да използвате повече в тази нова версия на MySQL.

Какво е отхвърлено в MySQL 8.0?

Следните функции са отхвърлени и ще бъдат премахнати в бъдеща версия.

  • Наборът от символи utf8mb3 е отхвърлен. Моля, вместо това използвайте utf8mb4.
  • Тъй като caching_sha2_password е приставката за удостоверяване по подразбиране в MySQL 8.0 и предоставя супернабор от възможностите на приставката за удостоверяване sha256_password, sha256_password е остаряла.
  • Плъгинът validate_password е повторно имплементиран, за да използва инфраструктурата на сървърния компонент. Формата на приставката validate_password все още е налична, но е отхвърлена.
  • Клаузата ENGINE за изразите ALTER TABLESPACE и DROP TABLESPACE.
  • Режимът PAD_CHAR_TO_FULL_LENGTH SQL.
  • Поддръжката на AUTO_INCREMENT е отхвърлена за колони от тип FLOAT и DOUBLE (и всякакви синоними). Помислете за премахване на атрибута AUTO_INCREMENT от такива колони или да ги преобразувате в целочислен тип.
  • Атрибутът UNSIGNED е отхвърлен за колони от тип FLOAT, DOUBLE и DECIMAL (и всякакви синоними). Вместо това помислете за използването на просто ограничение CHECK за такива колони.
  • Синтаксисът FLOAT(M,D) и DOUBLE(M,D) за определяне на броя на цифрите за колони от тип FLOAT и DOUBLE (и всякакви синоними) е нестандартно разширение на MySQL. Този синтаксис е отхвърлен.
  • Нестандартните &&, || и ! операторите, които са синоними на стандартните SQL оператори AND, OR и NOT, съответно, са отхвърлени. Приложенията, които използват нестандартни оператори, трябва да бъдат коригирани да използват стандартните оператори.
  • Клиентът mysql_upgrade е отхвърлен, тъй като неговите възможности за надграждане на системните таблици в системната схема на mysql и обектите в други схеми са преместени в MySQL сървъра.
  • Файлът mysql_upgrade_info, който е създадена директория с данни и се използва за съхраняване на номера на версията на MySQL.
  • Системната променлива relay_log_info_file и опцията --master-info-file са отхвърлени. Преди това те се използваха за определяне на името на информационния дневник на релето и главния информационен дневник, когато бяха зададени relay_log_info_repository=FILE и master_info_repository=FILE, но тези настройки бяха отхвърлени. Използването на файлове за релейния дневник с информация и главния информационен дневник е заменено от защитени от срив подчинени таблици, които са по подразбиране в MySQL 8.0.
  • Използването на променливата на средата MYSQL_PWD за определяне на парола за MySQL е отхвърлено.

И сега, нека да разгледаме някои от функциите, които трябва да спрете да използвате в тази версия на MySQL.

Какво беше премахнато в MySQL 8.0?

Следните функции бяха премахнати в MySQL 8.0.

  • Системната променлива innodb_locks_unsafe_for_binlog беше премахната. Нивото на изолация READ COMMITTED предоставя подобна функционалност.
  • Използване на GRANT за създаване на потребители. Вместо това използвайте CREATE USER. Следването на тази практика прави SQL режима NO_AUTO_CREATE_USER несъществен за операторите GRANT, така че той също се премахва и грешката сега се записва в регистъра на сървъра, когато наличието на тази стойност за опцията sql_mode във файла с опции предотвратява стартирането на mysqld.
  • Използване на GRANT за промяна на свойства на акаунта, различни от присвояването на привилегии. Това включва удостоверяване, SSL и свойства за ограничение на ресурсите. Вместо това установете такива свойства по време на създаване на акаунт със CREATE USER или ги променете след това с ALTER USER.
  • ИДЕНТИФИЦИРАН С ПАРОЛА 'auth_string' синтаксис за CREATE USER и GRANT. Вместо това използвайте IDENTIFIED WITH auth_plugin КАТО 'auth_string' за CREATE USER и ALTER USER, където стойността 'auth_string' е във формат, съвместим с наименования плъгин.
  • Функцията PASSWORD(). Освен това премахването на PASSWORD() означава, че синтаксисът SET PASSWORD ... =PASSWORD('auth_string') вече не е наличен.
  • Системната променлива old_passwords.
  • Изразите FLUSH QUERY CACHE и RESET QUERY CACHE.
  • Тези системни променливи:query_cache_limit, query_cache_min_res_unit, query_cache_size, query_cache_type, query_cache_wlock_invalidate.
  • Тези променливи на състоянието:Qcache_free_blocks, Qcache_free_memory, Qcache_hits, Qcache_inserts, Qcache_lowmem_prunes, Qcache_not_cached, Qcache_queries_in_cache, Qcache_total_blocks.
  • Тези нишка гласи:проверка на привилегиите върху кешираната заявка, проверка на кеша на заявка за заявка, невалидност на записите в кеша на заявката, изпращане на кеширан резултат на клиента, съхраняване на резултат в кеша на заявката, Изчакване за заключване на кеша на заявката.
  • Системните променливи tx_isolation и tx_read_only бяха премахнати. Вместо това използвайте transaction_isolation и transaction_read_only.
  • Системната променлива sync_frm е премахната, защото .frm файловете са остарели.
  • Системната променлива secure_auth и клиентската опция --secure-auth бяха премахнати. Опцията MYSQL_SECURE_AUTH за функцията mysql_options() C API беше премахната.
  • Системната променлива log_warnings и опцията за сървър --log-warnings бяха премахнати. Вместо това използвайте системната променлива log_error_verbosity.
  • Глобалният обхват за системната променлива sql_log_bin беше премахнат. sql_log_bin има само обхват на сесията и приложенията, които разчитат на достъп до @@GLOBAL.sql_log_bin, трябва да бъдат коригирани.
  • Неизползваните системни променливи date_format, datetime_format, time_format и max_tmp_tables са премахнати.
  • Оттеглените ASC или DESC квалификатори за клаузите GROUP BY са премахнати. Заявките, които преди са разчитали на сортиране GROUP BY, могат да дадат резултати, които се различават от предишните версии на MySQL. За да създадете даден ред на сортиране, осигурете клауза ORDER BY.
  • Антактният анализатор вече не третира \N като синоним на NULL в SQL изрази. Вместо това използвайте NULL. Тази промяна не засяга операциите за импортиране или експортиране на текстов файл, извършени с LOAD DATA или SELECT ... INTO OUTFILE, за които NULL продължава да бъде представена от \N.
  • Опциите --ssl и --ssl-verify-server-cert от страна на клиента бяха премахнати. Използвайте --ssl-mode=REQUIRED вместо --ssl=1 или --enable-ssl. Използвайте --ssl-mode=DISABLED вместо --ssl=0, --skip-ssl или --disable-ssl. Използвайте --ssl-mode=VERIFY_IDENTITY вместо опциите --ssl-verify-server-cert.
  • Програмата mysql_install_db е премахната от MySQL дистрибуции. Инициализацията на директорията с данни трябва да се извърши чрез извикване на mysqld с опцията --initialize или --initialize-insecure. В допълнение, опцията --bootstrap за mysqld, която беше използвана от mysql_install_db, беше премахната и опцията INSTALL_SCRIPTDIR CMake, която контролираше мястото за инсталиране на mysql_install_db, беше премахната.
  • Помощната програма mysql_plugin беше премахната. Алтернативите включват зареждане на плъгини при стартиране на сървъра с помощта на опцията --plugin-load или --plugin-load-add, или по време на изпълнение с помощта на оператора INSTALL PLUGIN.
  • Помощната програма resolveip е премахната. Вместо това могат да се използват nslookup, host или dig.

Има много нови, оттеглени и премахнати функции. Можете да проверите официалния уебсайт за по-подробна информация.

Съображения преди мигрирането към MySQL 8.0

Нека да споменем сега някои от най-важните неща, които трябва да имате предвид, преди да преминете към тази версия на MySQL.

Метод за удостоверяване

Както споменахме, caching_sha2_password не е методът за удостоверяване по подразбиране, така че трябва да проверите дали вашето приложение/конектор го поддържа. Ако не, нека да видим как можете да промените метода за удостоверяване по подразбиране и приставката за удостоверяване на потребителя отново на „mysql_native_password“.

За да промените метода за удостоверяване по подразбиране, редактирайте конфигурационния файл my.cnf и добавете/редактирайте следния ред:

$ vi /etc/my.cnf

[mysqld]

default_authentication_plugin=mysql_native_password

За да промените приставката за удостоверяване на потребителя, изпълнете следната команда с привилегирован потребител:

$ mysql -p

ALTER USER ‘username’@’hostname’ IDENTIFIED WITH ‘mysql_native_password’ BY ‘password’;

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

Също така ролите са важна характеристика тук. Можете да намалите индивидуалните привилегии, като го присвоите на роля и добавите съответните потребители там.

Например можете да създадете нова роля за екипите на маркетинга и разработчиците:

$ mysql -p

CREATE ROLE 'marketing', 'developers';

Задайте привилегии на тези нови роли:

GRANT SELECT ON *.* TO 'marketing';

GRANT ALL PRIVILEGES ON *.* TO 'developers';

И след това задайте ролята на потребителите:

GRANT 'marketing' TO 'marketing1'@'%';

GRANT 'marketing' TO 'marketing2'@'%';

GRANT 'developers' TO 'developer1'@'%';

И това е всичко. Ще имате следните привилегии:

SHOW GRANTS FOR 'marketing1'@'%';

+-------------------------------------------+

| Grants for [email protected]%                   |

+-------------------------------------------+

| GRANT USAGE ON *.* TO `marketing1`@`%`    |

| GRANT `marketing`@`%` TO `marketing1`@`%` |

+-------------------------------------------+

2 rows in set (0.00 sec)

SHOW GRANTS FOR 'marketing';

+----------------------------------------+

| Grants for [email protected]%                 |

+----------------------------------------+

| GRANT SELECT ON *.* TO `marketing`@`%` |

+----------------------------------------+

1 row in set (0.00 sec)

Набори от знаци

Тъй като новият набор от знаци по подразбиране е utf8mb4, трябва да се уверите, че не използвате стандартния, тъй като той ще се промени.

За да избегнете някои проблеми, трябва да посочите променливите character_set_server и collation_server в конфигурационния файл my.cnf.

$ vi /etc/my.cnf

[mysqld]

character_set_server=latin1

collation_server=latin1_swedish_ci

MyISAM Engine

Таблиците с привилегии на MySQL в схемата на MySQL се преместват в InnoDB. Можете да създадете таблица engine=MyISAM и тя ще работи както преди, но копирането на MyISAM таблица в работещ MySQL сървър няма да работи, защото няма да бъде открита.

Разделяне на дялове

Не трябва да има разделени таблици, които използват машина за съхранение, която няма естествена поддръжка за разделяне. Можете да изпълните следната заявка, за да проверите тази точка.

$ mysql -p

SELECT TABLE_SCHEMA, TABLE_NAME FROM INFORMATION_SCHEMA.TABLES WHERE ENGINE NOT IN ('innodb', 'ndbcluster') AND CREATE_OPTIONS LIKE '%partitioned%';

Ако трябва да промените двигателя на таблица, можете да изпълните:

ALTER TABLE table_name ENGINE = INNODB;

Проверка за надстройка

Като последна стъпка можете да изпълните командата mysqlcheck, като използвате флага за проверка на надстройка, за да потвърдите дали всичко изглежда наред.

$ mysqlcheck -uroot -p --all-databases --check-upgrade

Enter password:

mysql.columns_priv                                 OK

mysql.component                                    OK

mysql.db                                           OK

mysql.default_roles                                OK

mysql.engine_cost                                  OK

mysql.func                                         OK

mysql.general_log                                  OK

mysql.global_grants                                OK

mysql.gtid_executed                                OK

mysql.help_category                                OK

mysql.help_keyword                                 OK

mysql.help_relation                                OK

mysql.help_topic                                   OK

mysql.innodb_index_stats                           OK

mysql.innodb_table_stats                           OK

mysql.password_history                             OK

mysql.plugin                                       OK

mysql.procs_priv                                   OK

mysql.proxies_priv                                 OK

mysql.role_edges                                   OK

mysql.server_cost                                  OK

mysql.servers                                      OK

mysql.slave_master_info                            OK

mysql.slave_relay_log_info                         OK

mysql.slave_worker_info                            OK

mysql.slow_log                                     OK

mysql.tables_priv                                  OK

mysql.time_zone                                    OK

mysql.time_zone_leap_second                        OK

mysql.time_zone_name                               OK

mysql.time_zone_transition                         OK

mysql.time_zone_transition_type                    OK

mysql.user                                         OK

sys.sys_config                                     OK

world_x.city                                       OK

world_x.country                                    OK

world_x.countryinfo                                OK

world_x.countrylanguage                            OK

Има няколко неща, които трябва да проверите, преди да извършите надстройката. Можете да проверите официалната документация на MySQL за по-подробна информация.

Методи за надстройка

Има различни начини за надграждане на MySQL 5.7 до 8.0. Можете да използвате надстройката на място или дори да създадете подчинен за репликация в новата версия, за да можете да я популяризирате по-късно.

Но преди да надстроите, стъпка 0 трябва да е архивиране на вашите данни. Архивът трябва да включва всички бази данни, включително системните бази данни. Така че, ако има някакъв проблем, можете да върнете обратно възможно най-скоро.

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

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

Заключение

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


  1. Database
  2.   
  3. Mysql
  4.   
  5. Oracle
  6.   
  7. Sqlserver
  8.   
  9. PostgreSQL
  10.   
  11. Access
  12.   
  13. SQLite
  14.   
  15. MariaDB
  1. PHP, MySQL и часови зони

  2. Как да създадете json формат с group-concat mysql?

  3. tomcat7 - jdbc източник на данни - Това е много вероятно да създаде изтичане на памет

  4. Разлика между SET autocommit=1 и START TRANSACTION в mysql (Пропуснал ли съм нещо?)

  5. разделяне на ключови думи за post php mysql