MySQL 8.0-ის განახლება 8.4-ზე: checker, backup, upgrade, rollback

MySQL 8.0-ის განახლება 8.4-ზე ოთხნაწილიანი საქმეა და თანმიმდევრობა უფრო მნიშვნელოვანია, ვიდრე ნებისმიერი ცალკეული ბრძანება. MySQL Shell-ის upgrade checker გაუშვი ცოცხალ 8.0 სერვერზე და გაასწორე ყველა შეცდომა, რომელსაც ის აჩვენებს. აიღე backup, რომლის აღდგენაც 8.0-ზე შეგიძლია: in-place განახლებისთვის data directory-ის ცივი ასლი, ყველა დანარჩენისთვის - ლოგიკური dump. შემდეგ ან 8.4-ის binary-ები გაუშვი ძველ data directory-ზე (in-place), ან dump ჩატვირთე ახალ 8.4 სერვერზე (ლოგიკური გზა). ბოლოს, რეალური ტრაფიკის მოსვლამდე გატესტე აპლიკაცია 8.4-ზე, რადგან in-place უკან დაბრუნების გზა არ არსებობს: როგორც კი 8.4 data directory-ზე ერთხელ გაეშვა, 8.0 მის გახსნაზე უარს ამბობს.

ვერსიებს შორის განსხვავებები - ავთენტიფიკაციის ნაგულისხმევი მეთოდი, წაშლილი ბრძანებები, InnoDB-ის ახალი ნაგულისხმევი მნიშვნელობები - აღწერილია სტატიაში MySQL 8.4 LTS: რა შეიცვალა. ეს გზამკვლევი თავად პროცედურაა: ბრძანებები, checker-ის გამოსავლის მნიშვნელობა, განახლების ორივე გზა დეტალურად, როგორ გატესტო და რა ზომით მუშაობს rollback.

In-place თუ ლოგიკური: ჯერ გზა აირჩიე#

ორივე გზა იქამდე მიგიყვანს, რომ მონაცემები 8.4-ზე გექნება. განსხვავება downtime-შია, იმაში, რაზე გჭირდება კონტროლი და როგორ გამოიყურება rollback.

In-place აირჩიე, როცა MySQL-ს თავად ამუშავებ VDS-ზე ან საკუთარ მანქანაზე და მონაცემები იმდენად დიდია, რომ თავიდან ჩატვირთვას საათები დასჭირდება. ლოგიკური აირჩიე, როცა ბაზა hosted სერვისზეა და სერვერს სხვა მართავს, როცა ამავე დროს ახალ მანქანაზე გადადიხარ, ან როცა მონაცემები იმდენად მცირეა - რამდენიმე გიგაბაიტი - რომ ჩატვირთვა მაინც წუთებში სრულდება. ლოგიკურ განახლებას ასევე ყველაზე კომფორტული rollback აქვს, რადგან 8.0 სერვერი შენს გამორთვამდე ხელუხლებლად რჩება.

არსებობს მესამე გზაც მათთვის, ვისაც downtime ვერ აქვს: ახალი 8.4 სერვერი 8.0 წყაროს replica-დ გახადე, დაელოდე სანამ დაეწევა და მერე აპლიკაცია მასზე გადაიყვანე. ძველი source-დან ახალ replica-ზე replication მხარდაჭერილია, პირუკუ - არა, ამიტომ როგორც კი ჩანაწერები 8.4-ზე მოხვდება, ძველი 8.0 სერვერი მათ ვეღარ გაჰყვება. ეს გზა პატარა აპლიკაციის საჭიროებებს სცილდება და აქ დეტალურად არ განიხილება.

ნაბიჯი 1: ჯერ backup აიღე, 8.0-ისთვის წასაკითხი ფორმით#

განახლებამდე აღებულ backup-ს ჩვეულებრივ დანიშნულებას გარდა ერთი დამატებითი ამოცანა აქვს: ის 8.0-ზე უნდა აღდგებოდეს, რადგან სწორედ იმ ვერსიას დაუბრუნდები. ორი სახეობა გამოდგება.

data directory-ის ცივი ასლი. 8.0 სუფთად გააჩერე და მთელი დირექტორია - Linux-ზე ჩვეულებრივ /var/lib/mysql - სხვა ადგილას დააკოპირე. ეს ერთადერთი backup-ია, რომელიც in-place განახლებას სწრაფად აბრუნებს: ასლს უკან დებ, 8.0-ს თავიდან აყენებ, უშვებ და იქ ხარ, სადაც იყავი. სხვა არაფრისთვის გამოდგება, რადგან მხოლოდ იმავე major ვერსიაზე იხსნება, მაგრამ ამ მიზნისთვის იდეალურია. სუფთად გაჩერებული სერვერის ფაილური სისტემის snapshot-ი (LVM, ZFS) იმავე დანიშნულებას ემსახურება და წამებში კეთდება.

$ sudo systemctl stop mysql          # mysqld on RHEL-family systems$ sudo cp -a /var/lib/mysql /var/backups/mysql-80-datadir$ sudo cp -a /etc/mysql /var/backups/mysql-80-etc

კონფიგურაციაც დააკოპირე. განახლება მის რედაქტირებას გაიძულებს, rollback-ს კი 8.0-ის ვერსია სჭირდება.

ლოგიკური dump. ეს ლოგიკური გზის backup-ია და in-place გზის მეორე თავდაცვის ხაზი. mysqldump პარამეტრებით --single-transaction --routines --events --triggers სერვერის გაჩერების გარეშე ქმნის თანმიმდევრულ SQL ფაილს; mysqldump backup და restore ყველა flag-ს და მის შეცდომებს განმარტავს. უფრო დიდი ბაზებისთვის MySQL Shell-ის dump utility უფრო სწრაფია, რადგან პარალელურად წერს:

// in mysqlsh, JavaScript mode (\js)util.dumpInstance("/var/backups/dump-80", {threads: 4})

util.dumpInstance() ნაგულისხმევად მომხმარებლის ანგარიშებსა და grant-ებს შეიცავს, რასაც mysqldump ცუდად უმკლავდება - ის mysql schema-ს ცხრილებად ჩაწერს და მათი სხვა ვერსიაში ჩატვირთვა უსიამოვნებას იწვევს. თუ mysqldump-ს იყენებ, ანგარიშები ცალკე შეინახე: თითოეული აპლიკაციის ანგარიშისთვის SHOW CREATE USER და SHOW GRANTS გაძლევს ბრძანებებს, რომლებიც შეგიძლია ხელახლა გაუშვა.

ნაბიჯი 2: გაუშვი util.checkForServerUpgrade#

upgrade checker MySQL Shell-შია (mysqlsh) და არა სერვერში. ის მომუშავე 8.0 სერვერს უერთდება, ამოწმებს კონფიგურაციას, ანგარიშებს, schema-ებსა და შენახულ კოდს და გაცნობებს, რა გაფუჭდება ან განსხვავებულად იმუშავებს სამიზნე ვერსიაზე. არაფერს ცვლის.

გჭირდება MySQL Shell, რომელიც სამიზნე ვერსიაზე არანაკლებ ახალია: checker-ს შეუძლია შეამოწმოს ნებისმიერი ვერსია 8.0.11-დან მისი საკუთარი ვერსიის ნომრამდე და არა მეტი. 8.4 სამიზნისთვის Shell 8.4 და 9.x რელიზები ორივე გამოდგება. გაშვება შეიძლება ნებისმიერ მანქანაზე, რომელიც სერვერს წვდება, შენი ლეპტოპის ჩათვლით, მაგრამ კონფიგურაციის ფაილის შემოწმებას ფაილი იმ მანქანაზე სჭირდება, სადაც Shell მუშაობს, ამიტომ თავად მონაცემთა ბაზის სერვერზე გაშვება ყველაზე სრულ ანგარიშს იძლევა.

$ mysqlsh -- util check-for-server-upgrade root@localhost:3306 \    --target-version=8.4.6 --config-path=/etc/mysql/my.cnf

იგივე ინტერაქტიული Shell სესიის შიგნიდან, JavaScript რეჟიმში:

util.checkForServerUpgrade("root@localhost:3306", {  targetVersion: "8.4.6",  configPath: "/etc/mysql/my.cnf"})

თუ targetVersion გამოტოვე, checker Shell-ის ვერსიის ტოლ ვერსიას ივარაუდებს - ამიტომ Shell 9.x უამისოდ 9.x-ზე შეამოწმებს და ისეთ პრობლემებს აჩვენებს, რომლებიც ჯერ არ გაქვს. მიუთითე 8.4-ის ის patch, რომელსაც რეალურად აყენებ. თუ configPath გამოტოვე, option ფაილის წამკითხველი შემოწმებები ჩავარდება და შეტყობინება ფაილის მითითებას მოითხოვს; Debian-სა და Ubuntu-ზე ფაილია /etc/mysql/my.cnf (რომელიც mysql.conf.d/-ს მოიცავს), RHEL-ის ოჯახის სისტემებზე - /etc/my.cnf.

checker-ის გამშვებ ანგარიშს PROCESS და SELECT პრივილეგიები სჭირდება. საკუთარ სერვერზე ადვილი პასუხი root-ია. hosted სერვერზე, სადაც მხოლოდ აპლიკაციის მომხმარებელი გაქვს, მიანიჭე რაც შეგიძლია და მაინც გაუშვი; შემოწმებები, რომლებსაც საჭირო მონაცემები არ ეწვდებათ, ამას აცხადებენ და უხმოდ არ გადიან.

ანგარიშის კითხვა

ტექსტური გამოსავალი დანომრილი შემოწმებების სიაა, თითოეული ან No issues found-ით მთავრდება, ან Error, Warning ან Notice ნიშნით მონიშნული აღმოჩენების სიით, რასაც შეჯამება მოსდევს:

Errors:   2Warnings: 5Notices:  02 errors were found. Please correct these issues before upgradingto avoid compatibility issues.

Errors განახლებას ბლოკავს ან სერვერს გაშვებაზე უარს ათქმევინებს - ჩვეულებრივ ეს კონფიგურაციის ფაილში წაშლილი option-ია. ყველა ისინი 8.0 სერვერზე გაასწორე, მერე checker ისევ გაუშვი, სანამ რაოდენობა ნული არ გახდება. Warnings განახლებას არ აჩერებს, მაგრამ აღწერს რამეს, რაც სხვანაირად იმუშავებს ან მოგვიანებით გაფუჭდება; თითოეული წაიკითხე. Notices საინფორმაციოა.

შემოწმებები, რომლებიც 8.4-ისკენ მიმავალ 8.0 სერვერზე ყველაზე ხშირად ჩნდება:

mysqlsh -- util check-for-server-upgrade --list --target-version=8.4.6 ყველა შემოწმებას აღწერითა და იმ ვერსიებით ბეჭდავს, რომლებზეც ისინი მოქმედებს. ავტომატიზაციისთვის --output-format=JSON გაძლევს ერთ ობიექტს ველებით errorCount, warningCount და მასივით checksPerformed; CI ნაბიჯს ან სკრიპტს შეუძლია გაგრძელებაზე უარი თქვას, სანამ errorCount ნულზე მეტია. checker წარუმატებლობას exit code-ით არ აცხადებს, ამიტომ დათვალე რაოდენობა და ბრძანების ჩავარდნას ნუ ენდობი.

ორი აღმოჩენა მისი გასწორების გზას იმსახურებს. authMethodUsage-სთვის თითოეული ანგარიში caching_sha2_password-ზე გადაიყვანე ALTER USER ... IDENTIFIED WITH caching_sha2_password BY '...'-ით - მას შემდეგ, რაც შეამოწმებ, რომ აპლიკაციის driver მას უჭერს მხარს. sysvar-ისთვის option ფაილი შეასწორე და წაშლილი პარამეტრები წაშალე ან გადაარქვი სახელი; ყველაზე გავრცელებულია expire_logs_days (ჩაანაცვლე binlog_expire_logs_seconds-ით) და default_authentication_plugin. ორივე გასწორება 8.0-ზეც მუშაობს, ამიტომ ისინი იქ გააკეთე, გადატვირთე და დარწმუნდი, რომ აპლიკაცია ისევ მუშაობს, მხოლოდ ამის შემდეგ გადადი თავად განახლებაზე. ასე გაიყოფა „config-ის ცვლილებამ რამე გააფუჭა“ და „8.4-მა გააფუჭა“, და ეს განსხვავება გამოგადგება.

ნაბიჯი 3ა: in-place განახლება Linux-ზე#

როცა checker სუფთაა და ცივი ასლი აღებულია, in-place განახლება მოკლეა. MySQL-ის დოკუმენტაცია release სერიებს შორის in-place განახლებამდე slow shutdown-ს გვირჩევს, რომ InnoDB-მ purge და change-buffer merge დაასრულოს, სანამ ფაილები ახალ ვერსიას გადაეცემა:

SET GLOBAL innodb_fast_shutdown = 0;

შემდეგ სერვერი გააჩერე და პაკეტები გამოცვალე. Debian-ზე ან Ubuntu-ზე Oracle-ის APT repository-თი სერიას mysql-apt-config პაკეტი ირჩევს:

$ sudo systemctl stop mysql$ sudo dpkg-reconfigure mysql-apt-config   # choose the 8.4 LTS series$ sudo apt update$ sudo apt install mysql-server

RHEL-ზე, Rocky-ზე ან Alma-ზე Oracle-ის yum repository-თი 8.0 repository გამორთე და 8.4 LTS-ისა ჩართე - dnf repolist all | grep mysql მათ ზუსტ სახელებს შენი release პაკეტიდან აჩვენებს - მერე sudo dnf upgrade mysql-community-server. დისტრიბუტივის პაკეტებით მიწოდებული MySQL დისტრიბუტივის საკუთარ განრიგს მისდევს და შეიძლება 8.4 საერთოდ არ შესთავაზოს; თუ apt policy mysql-server მხოლოდ 8.0 კანდიდატებს აჩვენებს, გჭირდება Oracle-ის repository ან container.

Docker-ში გამოცვლა tag-ის შეცვლაა. container გააჩერე, image: mysql:8.0 შეცვალე image: mysql:8.4-ით და იმავე volume-ზე გაუშვი. მიამაგრე 8.4-ს ან კონკრეტულ patch-ს და არასდროს latest-ს, რომელიც 8.4-ს Innovation რელიზებზე გაცდა.

რა ხდება პირველ გაშვებაზე

როცა 8.4 8.0-ის data directory-ზე ეშვება, ჯერ data dictionary-ს ანახლებს, მერე mysql სისტემურ schema-ს, sys schema-სა და help ცხრილებს. ამ დროს error log-ს უყურე:

$ sudo tail -f /var/log/mysql/error.log

ეძებ ხაზების წყვილს Server upgrade from '80xxx' to '804xx' started და ... completed, შემდეგ ready for connections. რამდენიმე ასეულ ცხრილიან სერვერზე ეს წამებს გრძელდება; ათობით ათასით - წუთებს. შუაში არ შეწყვიტო - შეწყვეტილი dictionary-ის განახლებისთვისაა ცივი ასლი.

ქცევას სერვერის --upgrade option აკონტროლებს, რომლის ნაგულისხმევია AUTO (განაახლე ყველაფერი, რასაც სჭირდება). --upgrade=FORCE სისტემური ცხრილების განახლებას ხელახლა უშვებს მაშინაც, როცა სერვერს ჰგონია, რომ დასრულებულია, და ეს არის გამოსავალი, როცა საეჭვოა სისტემური schema ნახევრად განახლდა. mysql_upgrade აღარ არსებობს; ხელით გასაშვები არაფერია.

თუ სერვერი არ ეშვება, log მიზეზს პირველივე რამდენიმე შეცდომის ხაზში ამბობს. ჩვეულებრივი მიზეზია option, რომელიც checker-მა მონიშნა და ვინმემ არ წაშალა - log აჩვენებს unknown variable-ს სახელით. კონფიგურაციიდან ამოშალე და თავიდან გაუშვი.

ნაბიჯი 3ბ: ლოგიკური განახლება#

ლოგიკურ გზას სჭირდება მომუშავე 8.4 სერვერი - ახალი მანქანა, ახალი container ან hosted MySQL 8.4 ბაზა - და ნაბიჯი 1-ის dump. mysqldump-ის გამოსავლით ეს უბრალო import-ია:

$ gunzip -c appdb-80.sql.gz | mysql -h new-host -P 3306 -u root -p appdb

MySQL Shell-ის dump-ისთვის შესაბამისი loader გამოიყენე, რომელიც ცხრილებს პარალელურად ტვირთავს:

util.loadDump("/var/backups/dump-80", {threads: 4, loadUsers: true})

util.loadDump()-ს ორი რამ აფერხებს. ის მონაცემებს LOAD DATA LOCAL INFILE-ით ტვირთავს, ამიტომ სამიზნე სერვერზე local_infile ON უნდა იყოს; თუ გამორთულია და ვერ ცვლი, mysqldump გამოიყენე. და loadUsers ნაგულისხმევად გამორთულია, ამიტომ ანგარიშები და grant-ები გამოტოვებულია, სანამ არ მოითხოვ. hosted სერვერზე, სადაც სრული ადმინისტრატორი არ ხარ, მომხმარებლების გამოტოვება და აპლიკაციის ანგარიშების თავად შექმნა ხშირად უფრო სუფთაა - ანგარიშს, რომელიც გაქვს, შეიძლება თვითნებური პრივილეგიებით ანგარიშების შექმნა საერთოდ არ შეეძლოს.

ლოგიკური გზის აზრი რეპეტიციაა. ახალ სერვერზე ჩატვირთე, სანამ ძველი ტრაფიკს ემსახურება, ყველაფერი ასლზე გატესტე და როცა გაივლის, მოკლე write freeze-ის დროს ახალი dump აიღე და ის ჩატვირთე. freeze მხოლოდ რეპეტიციის dump-სა და საბოლოოს შორის ჩაწერილი ჩანაწერებისთვის გჭირდება. MySQL-ის ახალ ჰოსტზე გადატანა თავად გადართვას ეხება: freeze, საბოლოო dump, connection string-ების გადართვა, ძველი სერვერის რამდენიმე დღით read-only რეჟიმში დატოვება.

Definer-ები import-ის კლასიკური პრობლემაა. view, trigger ან routine, რომელიც ძველ სერვერზე admin@localhost-მა შექმნა, DEFINER=admin@localhost-ს ატარებს, 8.4-ზე კი ობიექტის შექმნას სხვა ანგარიშით definer-ად SET_ANY_DEFINER პრივილეგია სჭირდება. თუ import CREATE VIEW-ზე ან CREATE TRIGGER-ზე access-denied შეცდომით ჩერდება, ან ჯერ definer ანგარიში შექმენი, ან dump-იდან ეს clause-ები ამოიღე.

ნაბიჯი 4: აპლიკაცია ტრაფიკამდე გატესტე#

upgrade checker ბაზას ამოწმებს. აპლიკაციას ვერ ხედავს, 8.4-ის სიურპრიზები კი სწორედ აპლიკაციაში ჩნდება. განახლებულ ასლზე ტესტირება: ლოგიკური გზისთვის სარეპეტიციო სერვერზე, in-place-ისთვის staging სერვერზე ან ცივი backup-იდან აღდგენილ ასლზე.

რა გატესტო, დაახლოებით იმის მიხედვით, რამდენად ხშირად ტყდება:

1. ყველა ანგარიში შედის. არა მხოლოდ მთავარი აპლიკაციის მომხმარებელი - read-only ანგარიშგების ანგარიში, backup მომხმარებელი, cron job-ის მომხმარებელი. mysql_native_password-ზე დარჩენილი ანგარიში აქ ჩავარდება და სხვაგან არსად.
2. ყველა client და driver უერთდება. ძველი connector-ები ჩვეულებრივი პრობლემაა: driver, რომელსაც caching_sha2_password არ შეუძლია, იტყობინება, რომ plugin ვერ ჩაიტვირთა. შეამოწმე ენის driver-ები, GUI ხელსაწყოები და ნებისმიერი backup ან monitoring აგენტი. MySQL remote connections ამ plugin-ის TLS ქცევას ეხება.
3. ტესტების კომპლექტი გადის. აპლიკაციის საკუთარი ტესტები 8.4-ზე გაუშვი. migration-ებს განსაკუთრებული ყურადღება სჭირდება: ORM, რომელიც foreign key-ს არაუნიკალურ სვეტზე ქმნის, 8.4-ზე ვარდება, თუმცა არსებულები განახლებას გადაურჩნენ.
4. დაგეგმილი job-ები და სკრიპტები მუშაობს. ყველაფერი, რაც SHOW SLAVE STATUS-ს, FLUSH HOSTS-ს ან RESET MASTER-ს გასცემს, ახლა syntax შეცდომით ვარდება. მოძებნე შენს repository-ებსა და crontab-ებში.
5. ნელი query-ები სწრაფი რჩება. ნაგულისხმევი sql_mode 8.0-თან შედარებით არ შეცვლილა, ამიტომ query-ების შედეგები იდენტური უნდა იყოს, მაგრამ გეგმები შეიძლება გადაინაცვლოს InnoDB-ის ახალი ნაგულისხმევებისა და optimizer-ის ცვლილებების გამო. 8.0-ზე performance_schema.events_statements_summary_by_digest-იდან ყველაზე მძიმე ბრძანებები აიღე, თითოეულზე EXPLAIN გაუშვი ორივე ვერსიაზე და შეადარე. MySQL ინდექსები და EXPLAIN განმარტავს, როგორ წაიკითხო სხვაობები, slow query log კი იმას დაიჭერს, რაც გამოგრჩა, როცა რეალური ტრაფიკი მოვა.

პატარა სერვერზე პირველი დღის განმავლობაში მეხსიერებას მიაყურადე. 8.4-ის temptable_max_ram ნაგულისხმევი მეხსიერების 3%-ია, მაგრამ არასდროს 1 GB-ზე ნაკლები, რაც 1 ან 2 GB-იან მანქანაზე დროებით ცხრილებს განზრახულზე გაცილებით მეტის გამოყენების საშუალებას აძლევს. თუ 8.0-ზე არ დაგიყენებია, ახლა დააყენე აშკარად.

Rollback: რის გაუქმებაა შესაძლებელი და რისი - არა#

ამას ხალხი რთული გზით სწავლობს, ამიტომ ზუსტად უნდა ითქვას.

8.4-დან 8.0-ზე in-place downgrade მხარდაჭერილი არ არის. როგორც კი 8.4 data directory-ზე გაეშვა, data dictionary ახალ ვერსიას ატარებს. თუ მასზე 8.0 გაუშვი, InnoDB უარს ამბობს შეტყობინებით Downgrade is not supported. არ არსებობს ხელსაწყო, რომელიც უკან გადააკეთებს. უკან დასაბრუნებელი ერთადერთი სწრაფი გზა ნაბიჯი 1-ის ცივი ასლია: 8.4 გააჩერე, მისი data directory განზე გადადე, ასლი აღადგინე, 8.0-ის პაკეტები და ძველი კონფიგურაცია თავიდან დააყენე და გაუშვი. ყველაფერი, რაც ასლის აღების შემდეგ ჩაიწერა, იკარგება, ამიტომაც მისი აღებიდან 8.4-ის დატოვების გადაწყვეტილებამდე ინტერვალი მოკლე უნდა იყოს.

8.4-დან 8.0-ში ლოგიკური dump მხარდაჭერილია, მხოლოდ rollback-ისთვის. 8.4-ის სახელმძღვანელო 8.4-დან 8.0-ზე დასაბრუნებლად dump და load-ს (ან replication-ს) ასახელებს იმ პირობით, რომ მონაცემებზე 8.4-ის ახალი ფუნქციონალი არ გამოგიყენებია. ასე ინახავ განახლების შემდეგ ჩაწერილ ჩანაწერებს: 8.4 სერვერის dump აიღე და 8.0-ში ჩატვირთე. დიდ მონაცემებზე ნელია და მუშაობს მხოლოდ მანამ, სანამ schema არაფერს იყენებს, რაც 8.0-ს არ აქვს - ახალ პრივილეგიას grant-ში, GTID tag-ს, 8.1-დან 8.4-მდე შემოღებულ ფუნქციას. რაც უფრო დიდხანს მუშაობ 8.4-ზე, მით უფრო სავარაუდოა, რომ რამე შემოიპარა.

ლოგიკური გზა rollback-ს connection string-ის გადართვით აკეთებს. 8.0 სერვერი ჯერ კიდევ მუშაობს. თუ გადართვის დროს read-only რეჟიმში დატოვე, უკან გადართვა მყისიერია, 8.4-ზე ამასობაში ჩაწერილის გარდა.

უკან დაუბრუნებლობის წერტილი წინასწარ განსაზღვრე. გონივრული ვარიანტი: ცივი ასლი ან ძველი სერვერი ერთი კვირა შეინახე და ამ დროს 8.4-ისთვის სპეციფიკურ არაფერს მიჰყო ხელი. ამის შემდეგ წინ წადი და არა უკან - პრობლემები 8.4-ზე გაასწორე, რადგან 8.0 უსაფრთხოების გასწორებებს აღარ იღებს.

განახლების პრობლემების გადაჭრა#

უმეტესი ჩავარდნა რამდენიმე ნიმუშში ეტევა და error log ან client-ის შეტყობინება მათ სახელს ასახელებს.

სერვერი პაკეტების გამოცვლის შემდეგ არ ეშვება: წაიკითხე log-ის პირველი [ERROR] ხაზები. unknown variable ნიშნავს config ფაილში წაშლილ option-ს - შეამოწმე ჩართული დირექტორიებიც და არა მხოლოდ მთავარი ფაილი. შეტყობინება იმის შესახებ, რომ data directory უფრო ახალი ვერსიისაა, ნიშნავს, რომ 8.0-ს განახლებულ დირექტორიაზე უშვებ; აღადგინე ცივი ასლი.

აპლიკაცია ვერ შედის, მაგრამ mysql შედის: ანგარიში mysql_native_password-ზეა, ან driver caching_sha2_password-ისთვის ძალიან ძველია. დროებით გამოსავლად [mysqld] სექციაში mysql_native_password=ON ძველ plugin-ს თავიდან რთავს, მაგრამ 9.0-ში ის აღარ არსებობს, ამიტომ ეს რამდენიმე დღის შეღავათად ჩათვალე და არა გამოსწორებად.

checker არაფერს აჩვენებს, მაგრამ import ვარდება: checker წყარო სერვერს ამოწმებს და არა შენს dump ფაილს. definer-ის შეცდომები, SET @@GLOBAL.GTID_PURGED ხაზები და local_infile-ის უარყოფები load-ის დროის პრობლემებია; თითოეულს mysqldump-ის გზამკვლევი ეხება.

განახლებული in-place-ის შემდეგ query-ები ნელია: ყველაზე დატვირთულ ცხრილებზე ANALYZE TABLE გაუშვი, რომ სტატისტიკა ახალი იყოს, შემდეგ გეგმები შეადარე. თუ რომელიმე დატვირთვა adaptive hash index-ს ეყრდნობოდა, innodb_adaptive_hash_index=ON 8.0-ის ქცევას აბრუნებს; გაზომე ცვლილებამდე და მის შემდეგ და ნაგულისხმევად ნუ ჩართავ.

როგორ მუშაობს ეს RE:NODE-ზე#

RE:NODE-ის MySQL ხაზი უკვე MySQL 8.4 LTS-ზე მუშაობს, ამიტომ სხვაგან მდგარი 8.0 სერვერიდან მასზე გადასვლა ლოგიკური გზაა: checker ძველ სერვერზე გაუშვი, dump აიღე და ახალში ჩატვირთე root პაროლითა და მისთვის გენერირებული აპლიკაციის ბაზით. სერვერის binary-ებს შენ არ უშვებ, ამიტომ გასაკეთებელი in-place განახლება არ არსებობს, ხოლო პანელის backup-ები - მოთხოვნით ან განრიგით, აღდგენა ღილაკით, შენახვა მანქანის გარეთ - ბაზას მას შემდეგ იცავს, რაც ის მოხვდება. აპლიკაციის connection string-ის გადართვამდე ახალ სერვერზე გატესტე და ძველი 8.0 სერვერი ხელუხლებლად დატოვე, სანამ არ დარწმუნდები.

FAQ#

შეიძლება MySQL 5.7-იდან პირდაპირ 8.4-ზე განახლება?

in-place - არა. 5.7 ჯერ 8.0-ზე უნდა გადავიდეს, შემდეგ 8.0 - 8.4-ზე. 5.7-ის ლოგიკური dump ჩვეულებრივ პირდაპირ იტვირთება 8.4-ში, გამონაკლისებია დაცული სიტყვები, strict რეჟიმში ნულოვანი თარიღები და ძველი ავთენტიფიკაციის plugin-ები, ამიტომ სცადამდე checker 5.7 სერვერზე 8.4 სამიზნით გაუშვი.

ცვლის თუ არა upgrade checker რამეს ჩემს სერვერზე?

არა. ის მხოლოდ კითხულობს: კონფიგურაციას, information_schema-ისა და mysql schema-ის მეტამონაცემებს და შენახულ კოდს. საკუთარ სესიას ხსნის და Shell-ის მიმდინარე სესიას ხელს არ ახლებს. წარმოებაზე სამუშაო საათებშიც უსაფრთხოდ გაიშვება.

რამდენ ხანს გრძელდება in-place განახლება?

პაკეტების გამოცვლა ერთ-ორ წუთს იღებს. პირველ გაშვებაზე data dictionary-ის განახლება ცხრილების რაოდენობაზეა დამოკიდებული და არა მონაცემთა მოცულობაზე - ჩვეულებრივი აპლიკაციისთვის წამები, ათობით ათასი ცხრილის მქონესთვის წუთები. წინასწარი slow shutdown დატვირთულ სერვერზე, სადაც purge-ის ბევრი მოლოდინია, დროს დაამატებს.

8.4-ზე გადავიდე თუ პირდაპირ 9.x რელიზზე?

წარმოების ბაზისთვის - 8.4. ეს გრძელვადიანი მხარდაჭერის სერიაა და ქცევის ცვლილებების გარეშე იღებს გასწორებებს. 9.x Innovation რელიზები მხოლოდ შემდეგის გამოსვლამდე არის მხარდაჭერილი და სულ უფრო მეტს შლის, mysql_native_password-ის სრულად ჩათვლით.

უნდა განვაახლო აპლიკაციის MySQL driver?

მხოლოდ თუ ის caching_sha2_password-ს ვერ უმკლავდება, რაც ითქმის ძველ Node-ის mysql პაკეტზე და 5.7-ის ეპოქის driver-ებზე. ბოლო რამდენიმე წლის driver-ები მას უმკლავდებიან. შეამოწმე განახლებულ ასლს აპლიკაციის მიერ მოწოდებული driver-ის ზუსტი ვერსიით დაუკავშირდე.