MySQL 8.4 Oracle-ის ახალი გამოშვების მოდელით პირველი გრძელვადიანი მხარდაჭერის (LTS) ვერსიაა, და რადგან MySQL 8.0-ის სიცოცხლის ციკლი 2026 წლის აპრილში დასრულდა, სწორედ ამ ვერსიაზე უნდა იყო. აპლიკაციების უმეტესობისთვის 8.0-იდან განახლება უმტკივნეულოა: SQL იგივეა, დრაივერები იგივეა, მონაცემთა ფაილები ადგილზე ახლდება. ტყდება ის, რაც კიდეებზეა. mysql_native_password-ის მქონე ანგარიშები ვერ შედის, სანამ plugin-ს ხელახლა არ ჩართავ, რადგან 8.4 მას ნაგულისხმევად თიშავს. სკრიპტები, რომლებიც CHANGE MASTER TO-ს, SHOW SLAVE STATUS-ს, FLUSH HOSTS-ს, mysqlpump-ს ან expire_logs_days-ს იყენებს, მარცხდება, რადგან ეს ყველაფერი წაიშალა. და InnoDB-ის რამდენიმე ნაგულისხმევი შეიცვალა - უმეტესად უკეთესობისკენ სწრაფ storage-ზე, ერთის გარდა, რომელიც პატარა სერვერებზე უნდა გადაფარო.
ეს სახელმძღვანელო ჯერ გამოშვების მოდელს განიხილავს, რადგან ის ცვლის, როგორ გეგმავ განახლებებს, შემდეგ ყველა ცვლილებას, რომელიც სავარაუდოდ შეეხება აპლიკაციას ან ადმინისტრატორს, და ბოლოს - როგორ შეამოწმო ბაზა გადატანამდე.
LTS და Innovation გამოშვებები#
8.0-მდე MySQL წლების განმავლობაში ერთ სერიას უშვებდა და ფუნქციებს patch გამოშვებებში ამატებდა: 8.0.x-მა EXPLAIN ANALYZE 8.0.18-ში მიიღო, hash join-ები 8.0.18-ში, innodb_redo_log_capacity 8.0.30-ში. ამან „8.0“ მოძრავ სამიზნედ აქცია - ორი სერვერი, რომელთაც ორივეს MySQL 8.0 ერქვა, შეიძლება სხვადასხვანაირად იქცეოდა.
8.1-დან Oracle-მა გამოშვებები ორ ტრეკად გაყო:
| ტრეკი | ვერსიები | სიხშირე | მხარდაჭერა | ცვლილებები სერიის შიგნით |
|---|---|---|---|---|
| Innovation | 8.1, 8.2, 8.3, 9.0, 9.1 და შემდეგ | დაახლოებით კვარტალში ერთხელ | შემდეგ Innovation გამოშვებამდე | ახალი ფუნქციები, წაშლები, ქცევის ცვლილებები |
| LTS | 8.4, შემდეგ მოგვიანებით 9.x | დაახლოებით ორ წელიწადში ერთხელ | ჯამში დაახლოებით რვა წელი | მხოლოდ შეცდომებისა და უსაფრთხოების გამოსწორებები |
LTS სერია მოსაწყენად არის ჩაფიქრებული. 8.4.1, 8.4.2 და ასე შემდეგ გამოსწორებებს შეიცავს და არა ახალ ფუნქციებს ან შეცვლილ ნაგულისხმევებს, ასე რომ patch განახლებამ შენი აპლიკაციის ქცევა არ უნდა შეცვალოს. Oracle 8.4-ს 2032 წლამდე მხარდაჭერილად აცხადებს, მათგან პირველი ხუთი წელი premier მხარდაჭერით. Innovation გამოშვებები მათთვისაა, ვისაც ახალი ფუნქციები ადრე უნდა და მზადაა ყოველ რამდენიმე თვეში განახლდეს; production აპლიკაციის ბაზისთვის LTS გონივრული ნაგულისხმევია.
პრაქტიკული შედეგი ისაა, რომ 8.1-დან 8.3-მდე შემოტანილი ფუნქციები 8.4-ში ერთბაშად მოდის, და ასევე ის წაშლებიც, რომლებიც Innovation გამოშვებებმა გზადაგზა გააკეთა. ამიტომაა 8.0-იდან 8.4-ზე გადასვლაში იმაზე მეტი გამტეხი ცვლილება, ვიდრე 0.4-იანი ვერსიის სხვაობა გვაფიქრებინებს.
ავთენტიფიკაცია: mysql_native_password გამორთულია#
ეს ის ცვლილებაა, რომელიც აპლიკაციებს კავშირს უწყვეტს.
mysql_native_password, SHA-1-ზე დაფუძნებული plugin, რომელიც 8.0-მდე ნაგულისხმევი იყო, 8.0-ში მოძველებულად გამოცხადდა. 8.4-ში ის ჯერ კიდევ არსებობს, მაგრამ ნაგულისხმევად გამორთულია. მისით შექმნილი ანგარიში არსებობს, მაგრამ შესვლა მარცხდება, სანამ სერვერი ასე არ გაეშვება:
[mysqld]mysql_native_password=ONიგივე გადამრთველი command line-ზეც ხელმისაწვდომია, როგორც --mysql-native-password=ON. ეს გაშვების ოფციაა და არა ის, რისი შეცვლაც აპლიკაციის მომხმარებელს შეუძლია, ხოლო MySQL 9.0-ში plugin მთლიანად წაშლილია, ასე რომ მისი ხელახლა ჩართვა დროს გიყიდის და არაფერს წყვეტს. ნამდვილი გამოსწორება ანგარიშების გადაყვანაა caching_sha2_password-ზე, რომელიც 8.0-დან ნაგულისხმევია:
-- Find accounts still on the old pluginSELECT user, host, plugin FROM mysql.userWHERE plugin = 'mysql_native_password';-- Move one; the password must be set again because the hash format differsALTER USER 'app'@'%' IDENTIFIED WITH caching_sha2_password BY 'the-password';ამის გაკეთებამდე შეამოწმე, რომ აპლიკაციის დრაივერი caching_sha2_password-ს უჭერს მხარს. ბოლო რამდენიმე წელში გამოშვებული ყველაფერი უჭერს: PHP-ის mysqlnd, Node-ის mysql2, PyMySQL, mysqlclient, Connector/J 8 და უფრო ახალი, MySqlConnector .NET-ისთვის. Node-ის ორიგინალური mysql პაკეტი არ უჭერს, არც MySQL 5.7-ის ეპოქის command-line კლიენტები. კლიენტი, რომელსაც ეს არ შეუძლია, მარცხდება შეცდომით Authentication plugin 'caching_sha2_password' cannot be loaded; ის, რომელსაც შეუძლია, მაგრამ TLS-ის გარეშე უკავშირდება, პირველი შესვლისას სერვერის RSA საჯარო გასაღებს ან TLS კავშირს საჭიროებს - MySQL-ის დისტანციური კავშირები ამ ქცევას ხსნის.
ავთენტიფიკაციის ორი უფრო მცირე ცვლილება: default_authentication_plugin ცვლადი წაიშალა (მის საქმეს authentication_policy აკეთებს, რომელიც მრავალფაქტორიან ავთენტიფიკაციასაც მართავს), ხოლო authentication_fido plugin-ები წაიშალა authentication_webauthn-ის სასარგებლოდ.
წაშლილი ბრძანებები, ოფციები და ინსტრუმენტები#
აქ ჩამოთვლილი ყველაფერი, რაც სკრიპტში, კონფიგურაციის ფაილში ან ORM-ის ადმინისტრაციულ ინსტრუმენტებში გვხვდება, 8.4-ზე მარცხდება. უმეტესობა 8.0-ის განმავლობაში გაფრთხილებებით მოძველებულად გამოცხადდა.
| წაშლილი | მის ნაცვლად |
|---|---|
CHANGE MASTER TO, MASTER_* ოფციები | CHANGE REPLICATION SOURCE TO, SOURCE_* ოფციები |
START SLAVE, STOP SLAVE, RESET SLAVE | START REPLICA, STOP REPLICA, RESET REPLICA |
SHOW SLAVE STATUS, SHOW SLAVE HOSTS | SHOW REPLICA STATUS, SHOW REPLICAS |
SHOW MASTER STATUS, SHOW MASTER LOGS | SHOW BINARY LOG STATUS, SHOW BINARY LOGS |
RESET MASTER, PURGE MASTER LOGS | RESET BINARY LOGS AND GTIDS, PURGE BINARY LOGS |
FLUSH HOSTS | TRUNCATE TABLE performance_schema.host_cache |
expire_logs_days | binlog_expire_logs_seconds |
default_authentication_plugin | authentication_policy |
--ssl, --admin-ssl, have_ssl, have_openssl | --tls-version, --admin-tls-version |
--skip-host-cache | --host-cache-size=0 |
mysqlpump | mysqldump ან MySQL Shell-ის dump უტილიტები |
mysql_upgrade | არაფერი; სერვერი გაშვებისას თავად ახლდება |
mysql_ssl_rsa_setup | არაფერი; სერვერი სერტიფიკატებს თავად აგენერირებს |
binlog_transaction_dependency_tracking | არაფერი; ყოველთვის writeset tracking გამოიყენება |
AUTO_INCREMENT FLOAT/DOUBLE სვეტებზე | მთელრიცხვა სვეტი |
რეპლიკაციის სინტაქსის ცვლილება უფრო მეტად მონიტორინგის სკრიპტებს იჭერს, ვიდრე რეპლიკაციის კონფიგურაციებს. health check, რომელიც ყოველ წუთს SHOW SLAVE STATUS-ს უშვებს და Seconds_Behind_Master-ს grep-ით ეძებს, ახლა სინტაქსურ შეცდომას იღებს, ხოლო SHOW REPLICA STATUS-ში სვეტს Seconds_Behind_Source ჰქვია. მდგომარეობის ცვლადები, როგორიცაა Com_show_slave_status, მათთან ერთად წაიშალა.
FLUSH HOSTS მნიშვნელოვანია ყველასთვის, ვისაც შეხვედრია Host is blocked because of many connection errors. TRUNCATE ჩამნაცვლებელს იმ ცხრილზე DROP პრივილეგია სჭირდება, რომელიც root-ს აქვს; mysqladmin flush-hosts ისევ მუშაობს და შიგნით მას იყენებს.
ასევე წაიშალა: --old და --new ოფციები, --language, avoid_temporal_upgrade და show_old_temporals, LOW_PRIORITY LOCK TABLES ... WRITE-თან ერთად, keyring_file და keyring_encrypted_file plugin-ები (კომპონენტებით ჩანაცვლდა), INFORMATION_SCHEMA.TABLESPACES და სუსტი TLS შიფრების მხარდაჭერა - 8.4 მხოლოდ forward secrecy-ისა და ავთენტიფიცირებული დაშიფვრის მქონე შიფრებს იღებს TLS 1.2-სა და 1.3-ზე.
InnoDB-ისა და სერვერის ახალი ნაგულისხმევები#
8.4-მა InnoDB-ის ნაგულისხმევების ნაკრები შეცვალა თანამედროვე აპარატურაზე მოსარგებად - NVMe storage-სა და ბევრ ბირთვზე - და არა მბრუნავ დისკებზე, რომლებისთვისაც ძველები დაიწერა. თუ ამათ ცალსახად არ აყენებ, შენი სერვერი განახლების შემდეგ სხვანაირად იქცევა.
| ცვლადი | 8.0 | 8.4 |
|---|---|---|
innodb_io_capacity | 200 | 10000 |
innodb_io_capacity_max | მინიმუმ 2000 | innodb_io_capacity-ის ორმაგი |
innodb_log_buffer_size | 16M | 64M |
innodb_flush_method (Linux) | fsync | O_DIRECT, სადაც მხარდაჭერილია |
innodb_use_fdatasync | OFF | ON |
innodb_adaptive_hash_index | ON | OFF |
innodb_change_buffering | all | none |
innodb_buffer_pool_instances | 8 (1, თუ 1 GB-ზე ნაკლებია) | გამოითვლება; 1, თუ 1 GB ან ნაკლებია |
innodb_doublewrite_pages | innodb_write_io_threads (4) | 128 |
innodb_read_io_threads | 4 | ლოგიკური CPU-ების ნახევარი, მინიმუმ 4 |
innodb_purge_threads | 4 | 1 16 ლოგიკურ CPU-მდე, სხვა შემთხვევაში 4 |
innodb_numa_interleave | OFF | ON |
temptable_max_ram | 1G | მეხსიერების 3%, 1-სა და 4 GB-ს შორის |
temptable_use_mmap / temptable_max_mmap | ON / 1G | OFF / 0 |
ამათი უმეტესობა გაუმჯობესებაა, რომელსაც უფასოდ იღებ. O_DIRECT აჩერებს InnoDB-ს, რომ გვერდები ოპერაციული სისტემის ქეშში ორმაგად არ დააქეშოს. უფრო მაღალი I/O ტევადობა ფონურ flush-ს სწრაფ storage-ს ფეხის აწყობის საშუალებას აძლევს. adaptive hash index-ისა და change buffering-ის გამორთვა აშორებს ორ ფუნქციას, რომლებიც ხშირად იწვევდა კონკურენციას და თანამედროვე დატვირთვებზე იშვიათად ამართლებდა; თუ კონკრეტულ, წაკითხვაზე მძიმე დატვირთვას სარგებელი მოჰქონდა, მათი ხელახლა ჩართვა შეიძლება.
პატარა სერვერზე თვალი temptable_max_ram-ს უნდა ადევნო. მისი 8.4-ის ნაგულისხმევი არასოდეს ეცემა 1 GB-ზე დაბლა, რაც 1 ან 2 GB სერვერზე მეხსიერებაში მყოფ დროებით ცხრილებს მანქანის ნახევრის ან მთლიანის დაკავების საშუალებას აძლევს. შეზღუდე - InnoDB-ის მორგება პატარა სერვერებისთვის გეგმის ზომის მიხედვით რიცხვებს გაძლევს. innodb_dedicated_server, თუ იყენებ, აღარ აყენებს innodb_flush_method-ს და redo log-ის ზომას მეხსიერების ნაცვლად CPU-ების რაოდენობით ითვლის.
სქემისა და პრივილეგიების ცვლილებები#
foreign key-ები უნიკალურ გასაღებებს უნდა მიუთითებდეს. restrict_fk_on_non_standard_key ნაგულისხმევად ON-ია, ასე რომ foreign key-ის შექმნა, რომელიც არაუნიკალურ index-ს ან გასაღების მხოლოდ ნაწილს მიუთითებს, მარცხდება შეცდომით ER_WARN_DEPRECATED_NON_STANDARD_KEY. ასეთი არსებული foreign key-ები განახლებას გაფრთხილებებით გადაურჩება; ახლებს სჭირდება, რომ მითითებული სვეტები primary key ან უნიკალური index იყოს, ან ცვლადი გამორთული.
wildcard-ები ბაზის grant-ებში მოძველებულია. GRANT ... ON ბაზის სახელზე, რომელიც %-ს ან _-ს შეიცავს, ისევ ნიმუშად მუშაობს, მაგრამ მოსალოდნელია, რომ მომავალ ვერსიაში ეს სიმბოლოები ლიტერალები გახდება. grant-ები თითო ბაზაზე გაეცი.
ახალი პრივილეგიები. FLUSH_PRIVILEGES (მხოლოდ FLUSH PRIVILEGES-ისთვის; RELOAD-ის მფლობელები მას განახლებისას იღებენ), OPTIMIZE_LOCAL_TABLE, TRANSACTION_GTID_TAG, და SET_ANY_DEFINER ALLOW_NONEXISTENT_DEFINER-თან ერთად, რომლებიც SET_USER_ID-ს ცვლის ობიექტების შესაქმნელად, სადაც definer სხვა ვინმეა. ეს ბოლო ცვლილება აღდგენებზე მოქმედებს: dump-ს, რომლის view-ები და routine-ები შენგან განსხვავებულ definer-ს ასახელებს, დაწერილი სახით ჩასატვირთად SET_ANY_DEFINER სჭირდება. MySQL-ის მომხმარებლები და პრივილეგიები definer-ებს უფრო დაწვრილებით განიხილავს.
იდენტიფიკატორები ერთზე მეტი `$`-ით. ბრჭყალების გარეშე იდენტიფიკატორი, რომელიც ორ ან მეტ დოლარის ნიშანს შეიცავს, 8.1-დან სინტაქსური შეცდომაა. იშვიათია, მაგრამ როცა ხდება, ხმამაღლა ტყდება.
დადებით მხარეს, 8.4 Innovation ეპოქის ფუნქციებს თან მოიტანს: ჰისტოგრამები, რომელთა ავტომატური განახლებაც ANALYZE TABLE-ით შეიძლება დაყენდეს, GTID tag-ები ტრანზაქციების დასაჯგუფებლად, და mysql კლიენტი, რომელსაც შეუძლია თავისი system shell escape --system-command=OFF-ით გამორთოს.
ბაზის შემოწმება განახლებამდე#
MySQL Shell-ის upgrade checker ამოწმებს გაშვებულ 8.0 სერვერს და აცნობებს ყველაფერს, რაც სამიზნე ვერსიაზე პრობლემა იქნება: გამოყენებული წაშლილი ოფციები, მოძველებულ plugin-ებზე მყოფი ანგარიშები, foreign key-ები არაუნიკალურ გასაღებებზე, იდენტიფიკატორებად გამოყენებული რეზერვირებული სიტყვები და სხვა.
$ mysqlsh root@old-server:3306 -- util check-for-server-upgrade --target-version=8.4.6გაუშვი ანგარიშით, რომელსაც კონფიგურაციისა და mysql სქემის წაკითხვა შეუძლია, წაიკითხე ყველა შეცდომა და გაფრთხილება და გაასწორე ის, რასაც აცნობებს, ჯერ ძველ სერვერზე. განახლების გზები, რომლებსაც მხარს უჭერს:
| საიდან | 8.4-ზე | როგორ |
|---|---|---|
| 8.0 (ბოლო patch) | კი | ადგილზე, ან dump და ჩატვირთვა |
| 8.1-8.3 Innovation | კი | ადგილზე |
| 5.7 | პირდაპირ არა | ჯერ 8.0-ზე განახლება, ან dump და ჩატვირთვა |
| 8.4.x | 8.4.y | ადგილზე; 8.4 სერიის შიგნით downgrade-იც მხარდაჭერილია |
ადგილზე განახლება ნიშნავს ძველი სერვერის გაჩერებას და ახალი binary-ების გაშვებას იმავე data დირექტორიაზე; სერვერი პირველი გაშვებისას თავის data dictionary-სა და სისტემურ ცხრილებს თავად ანახლებს. ჰოსტინგზე განთავსებულ ბაზაზე, სადაც სერვერს პროვაიდერი მართავს, ეკვივალენტია შენი ბაზების ლოგიკური dump, ჩატვირთული 8.4 სერვერში - რაც ასევე ჰოსტებს შორის გადატანის გზაა, აღწერილი MySQL-ის ახალ ჰოსტზე გადატანაში. ლოგიკური dump 5.7-იდან 8.0-ზე ნახტომსაც გამოტოვებს, რადგან MySQL 8.4 უმეტეს შემთხვევაში 5.7-ის dump-ს პირდაპირ ტვირთავს; გამონაკლისები ძირითადად რეზერვირებული სიტყვები და ნულოვანი თარიღებია მკაცრ რეჟიმში.
განახლება, ნაბიჯ-ნაბიჯ#
თვითმართვადი სერვერისთვის ადგილზე განახლების გზა 8.0-იდან ასე გამოიყურება. ყოველ ნაბიჯს თავისი მიზეზი აქვს, და ერთის გამოტოვება სწორედ ისაა, როგორ იქცევა განახლებები აღდგენებად.
- ჯერ 8.0-ის ბოლო patch-ზე გადადი. 8.0.40-იანებიდან განახლება უკეთ არის გამოცდილი, ვიდრე 8.0.20-იდან, და 8.0-ის გვიანი patch-ები გაფრთხილებს იმის უმეტესობაზე, რასაც 8.4 შლის. იმ restart-ის შემდეგ წაიკითხე error log მოძველების გაფრთხილებების საპოვნელად: თითოეული მომავალი ჩავარდნაა.
- გაუშვი upgrade checker მუშა სერვერზე და გაასწორე ყველაფერი, რასაც შეცდომად აცნობებს. გაფრთხილებებიც ყურადღებას იმსახურებს; მათ შორისაა
mysql_native_password-ზე მყოფი ანგარიშები. - გაასუფთავე კონფიგურაცია. წაშალე ზემოთ ჩამოთვლილი ოფციები და შეგნებულად გადაწყვიტე InnoDB-ის შეცვლილი ნაგულისხმევების შესახებ: თუ
innodb_io_capacityშენს storage-ზე გქონდა მორგებული, შენი მნიშვნელობა რჩება; თუ არასოდეს დაგიყენებია, ის 200-იდან 10000-მდე ხტება. - გააკეთე სრული backup, რომელიც ერთხელ მაინც აღგიდგენია. ლოგიკური dump არის ის, რომელიც საჭიროების შემთხვევაში 8.0-ზე დაბრუნების საშუალებას გაძლევს, რადგან ადგილზე განახლებას ძველი binary-ების გაშვებით ვერ დააბრუნებ - data dictionary უკვე განახლებულია.
- გააჩერე სუფთად.
innodb_fast_shutdown-ით მის ნაგულისხმევ 1-ზე სუფთა გაჩერება კარგია; მისი წინასწარ 0-ზე დაყენება InnoDB-ს purge-ისა და merge-ის სამუშაოს დასრულებას აიძულებს გაჩერებამდე, რაც ზოგს დიდი განახლების წინ ურჩევნია. - დააყენე 8.4 და გაუშვი იმავე data დირექტორიაზე. ადევნე თვალი error log-ს: სერვერი ანახლებს data dictionary-ს, შემდეგ სისტემურ სქემას, და აცნობებს, როცა კავშირებისთვის მზადაა. ბევრი ცხრილის მქონე დიდ ინსტანციაზე ამას დრო სჭირდება; არ შეაწყვეტინო.
- გამოცადე აპლიკაცია, ყველა ანგარიშის შესვლის, დაგეგმილი ამოცანებისა და ნებისმიერი მონიტორინგის ჩათვლით, რომელიც ადმინისტრაციულ ბრძანებებს უშვებს. ამ განახლების ჩავარდნები თითქმის ყველა კიდეებზეა და არა query-ებში.
ჰოსტინგზე განთავსებულ ბაზაზე მე-5 და მე-6 ნაბიჯებს თავად არ აკეთებ, და გზა არის ძველი სერვერის dump, ჩატვირთული ახალ 8.4 სერვერში. 1-დან 4-მდე და მე-7 ნაბიჯები ისევ მოქმედებს, და upgrade checker შეგიძლია შენს ძველ სერვერზე მიმართო ნებისმიერი მანქანიდან, სადაც MySQL Shell არის. როცა აპლიკაცია dump-იდან ჩატვირთულ სატესტო ასლზე მუშაობს, გადართვა კონფიგურაციის ცვლილებაა.
რა არ იცვლება#
აპლიკაციისთვის - უმეტესი. query-ებისა და DML-ის SQL სინტაქსი იგივეა. utf8mb4 utf8mb4_0900_ai_ci-ით ნაგულისხმევად რჩება. window ფუნქციები, common table expression-ები, JSON ფუნქციები, EXPLAIN ANALYZE, უხილავი და ფუნქციური index-ები ისევე იქცევა, როგორც გვიან 8.0-ში. ORM-ები, რომლებიც 8.0-ს უჭერდა მხარს, 8.4-საც უჭერს; შესამოწმებელია ის, რომლებიც რეპლიკაციის ან ადმინისტრაციულ ბრძანებებს უშვებს, და ის, რომლებიც ძველ დრაივერზეა მიბმული.
საკონტროლო სია, თანმიმდევრობით: განაახლე დრაივერები, გადაიყვანე ანგარიშები mysql_native_password-იდან, ამოიღე წაშლილი ოფციები კონფიგურაციიდან, ჩაანაცვლე წაშლილი ბრძანებები სკრიპტებსა და მონიტორინგში, გაუშვი upgrade checker, შემდეგ გაიმეორე გადატანა ასლზე და გაუშვი მასზე აპლიკაციის ტესტები.
FAQ#
MySQL 8.0 ჯერ კიდევ მხარდაჭერილია?
არა. MySQL 8.0-ის სიცოცხლის ციკლი 2026 წლის აპრილში დასრულდა და Oracle-ისგან აღარ იღებს გამოსწორებებს, უსაფრთხოების გამოსწორებების ჩათვლით. ზოგიერთი cloud პროვაიდერი მისთვის ფასიან გაფართოებულ მხარდაჭერას ყიდის, მაგრამ მხარდაჭერილი უფასო გზა 8.4 LTS-ია.
MySQL 8.4 გამოვიყენო თუ 9.x Innovation გამოშვება?
production აპლიკაციისთვის - 8.4 LTS. Innovation გამოშვებები მხოლოდ შემდეგამდეა მხარდაჭერილი, დაახლოებით კვარტალი, ასე რომ ერთზე დარჩენა ნიშნავს წელიწადში რამდენჯერმე განახლებას ისეთი გამოშვებებით, რომლებმაც შეიძლება რაღაცები წაშალონ. 9.x გამოიყენე მომავალი ცვლილებების გამოსაცდელად და შემდეგ LTS-ზე გადადი, როცა გამოვა.
შემიძლია 8.4-ზე ისევ mysql_native_password გამოვიყენო?
მხოლოდ თუ სერვერი mysql_native_password=ON-ით გაეშვება, რაც სერვერის კონფიგურაციაზე კონტროლს მოითხოვს. მაშინაც კი ეს დროებითი გამოსავალია: MySQL 9.0-მა plugin წაშალა. გადაიყვანე ანგარიში caching_sha2_password-ზე და განაახლე ნებისმიერი დრაივერი, რომელიც მას ვერ უმკლავდება.
ჩემი 8.0-ის dump MySQL 8.4-ში ჩაიტვირთება?
თითქმის ყოველთვის, კი. 8.0-ის ლოგიკური dump 8.4-ში ცვლილებების გარეშე იტვირთება შემთხვევების აბსოლუტურ უმრავლესობაში. ყურადღება მიაქციე definer-ის პუნქტებს, რომლებიც ახალ სერვერზე არარსებულ ანგარიშებს ასახელებს, და SET @@GLOBAL ხაზებს, რომლებსაც ისეთი პრივილეგიები სჭირდება, რაც ჩვეულებრივ მომხმარებელს არ აქვს; mysqldump-ით backup და აღდგენა ორივეს განიხილავს.
უნდა გავუშვა mysql_upgrade განახლების შემდეგ?
არა - და 8.4-ზე ვერც გაუშვებ, რადგან წაიშალა. 8.0.16-დან სერვერი თავის სისტემურ ცხრილებსა და data dictionary-ს გაშვებისას თავად ანახლებს, რასაც --upgrade ოფცია მართავს, რომლის ნაგულისხმევიც ისაა, რომ ყველაფერი საჭირო გააკეთოს.
კომენტარები
სრულიად ანონიმურად: ანგარიშის, ელფოსტის და cookie-ის გარეშე. ინახება მხოლოდ სახელი, ტექსტი და დრო - სხვა არაფერი. ბმულების რაოდენობა ლიმიტირებულია.