MySQL 8.4 mysql_native_password: შეცდომები და გამოსწორება

თუ აპლიკაცია MySQL 8.4-ზე გადასვლის შემდეგ აღარ უკავშირდება ბაზას და სერვერი წერს Plugin 'mysql_native_password' is not loaded, ანუ ანგარიში ჯერ კიდევ SHA-1-ზე დაფუძნებულ ძველ შესვლის მეთოდს იყენებს, 8.4 კი ამ მეთოდს გამორთულს აწვდის. გამოსავალი ორია. ნამდვილი გამოსწორებაა ანგარიშის გადაყვანა caching_sha2_password-ზე ბრძანებით ALTER USER ... IDENTIFIED WITH caching_sha2_password BY '...', მას შემდეგ, რაც დარწმუნდები, რომ აპლიკაციის დრაივერი ამ მეთოდს იცნობს. დროებითი გამოსავალია სერვერის გაშვება mysql_native_password=ON პარამეტრით, რომელიც მუშაობს 8.4-ზე და მის შემდეგ აღარსად: MySQL 9.0-მა ეს plugin სრულად ამოიღო. მსგავსი შეცდომები, რომლებიც მეორე მხრიდან მოდის - ძველი კლიენტი, რომელიც caching_sha2_password-ს ვერ ესაუბრება, ან ახალი 9.x კლიენტი, რომელსაც mysql_native_password-ის გამოყენება აღარ შეუძლია - საკუთარ გამოსწორებას საჭიროებს და მათი ერთმანეთისგან გარჩევა სამუშაოს დიდი ნაწილია.

ეს პოსტი 8.4-ზე განახლების ავტორიზაციის მხარეს დეტალურად განიხილავს. რა შეიცვალა 8.0-სა და 8.4-ს შორის, ამის ფართო სია იხილე სტატიაში MySQL 8.4 LTS: რა შეიცვალა, ხოლო ანგარიშების შექმნა და პრივილეგიების მინიჭება აღწერილია სტატიაში MySQL მომხმარებლები და პრივილეგიები.

რა შეიცვალა ვერსიიდან ვერსიამდე#

ეს plugin წლებია გასვლისკენ მიდის. ვერსიებს შორის განსხვავება იმაშია, რამდენად ხმამაღლა გატყობინებს MySQL ამას.

8.0-ის წლების გამო ბევრ ინსტალაციაში ჯერ კიდევ native ანგარიშებია. ნაგულისხმევი მეთოდი 8.0.4-ში შეიცვალა, მაგრამ 5.7-დან განახლებულმა სერვერმა ყველა არსებული ანგარიში ძველ plugin-ზე დატოვა, ბევრი ინსტალაციის ინსტრუქცია, Docker Compose ფაილი და ჰოსტინგის პანელი კი დრაივერთან პრობლემების თავიდან ასაცილებლად ადგენს default_authentication_plugin=mysql_native_password-ს. ეს ანგარიშები 8.0-ის მთელ სერიაში მუშაობდა. 8.4-ზე ეს მთავრდება.

ყურადღება მიაქციე 8.4-ის სტრიქონში არსებულ ნიუანსს. plugin არ გამქრალა: კოდი ჯერ კიდევ სერვერშია, მისი მომხმარებელი ანგარიშები კვლავ არსებობს mysql.user-ში და მონაცემები განახლებას უვნებლად გადაურჩება. უბრალოდ ის ჩატვირთული არ არის, ამიტომ ასეთ ანგარიშზე შესვლა ვერ სრულდება, ისევე როგორც CREATE USER ან ALTER USER, რომელიც მას ასახელებს. 9.x-ზე იგივე ანგარიშები განახლების შემდეგაც რჩება, მაგრამ მათი უკან ჩასართავი გადამრთველი აღარ არსებობს.

როგორ განსხვავდება ეს ორი plugin#

mysql_native_password პაროლის ორმაგ SHA-1 ჰეშს ინახავს, მარილის (salt) გარეშე. ორ ანგარიშს ერთი და იგივე პაროლით ერთი და იგივე ჰეში აქვს, SHA-1 კი საკმარისად სწრაფია იმისთვის, რომ გაჟონილი mysql.user ცხრილი იაფად გატეხო brute force-ით. თავად შესვლა challenge-response სქემაა, რომელიც პაროლს არასდროს გზავნის - ამიტომ მუშაობდა ის ორი ათწლეულის განმავლობაში TLS-ის გარეშე.

caching_sha2_password ინახავს მარილიან SHA-256 ჰეშს, რომელიც ათასობით რაუნდს გადის, რის გამოც შენახული ჰეშების გატეხვა ბევრად ძვირი ჯდება. საფასური ისაა, რომ პაროლის ამ ჰეშთან შემოწმება განზრახ ნელია, ამიტომ სერვერი ინახავს მეხსიერებაში იმ ანგარიშების cache-ს, რომლებიც ახლახან წარმატებით შევიდნენ. ამით plugin-ს ორი გზა აქვს:

• სწრაფი ავტორიზაცია - ანგარიში cache-შია, ამიტომ კლიენტი scramble-ს SHA-256-ზე დაფუძნებული პასუხით უპასუხებს და შედის ისე, რომ პაროლი ქსელში არ გადის. ეს ჩვეულებრივი შემთხვევაა.
• სრული ავტორიზაცია - ანგარიში cache-ში არ არის, რაც ხდება სერვერის გაშვების შემდეგ პირველ შესვლაზე, FLUSH PRIVILEGES-ის შემდეგ და ანგარიშის პაროლის შეცვლის შემდეგ. სერვერს საჭიროებს ნამდვილი პაროლი, რომ შეადაროს შენახულ ჰეშს, ამიტომ კლიენტმა ის უნდა გააგზავნოს, MySQL კი მას მხოლოდ უსაფრთხო არხით მიიღებს: TLS კავშირით, Unix socket-ით ან სერვერის RSA საჯარო გასაღებით დაშიფრულს.

სწორედ ეს მეორე გზაა "მუშაობდა და მერე შეწყდა" ტიპის ჩივილების წყარო. აპლიკაცია TLS-ის გარეშე უკავშირდება, რამდენიმე დღე ყველაფერი რიგზეა, რადგან ანგარიში cache-შია, სერვერი ირესტარტება და შემდეგი შესვლა ვერ ხერხდება მანამ, სანამ რაღაც ერთხელ TLS-ით არ შევა და cache-ს ისევ არ "გააცხელებს". თუ კლიენტს თავიდანვე TLS-ზე ან RSA გასაღების მიღებაზე დააყენებ, პრობლემა საერთოდ არ გაჩნდება.

შეცდომები და რომელი მხრიდან მოდის#

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

Plugin 'mysql_native_password' is not loaded

ეს 8.4-ისა და 9.x-ის სერვერი გეუბნება ანგარიშის შესახებ და არა კლიენტი. ნებისმიერი კლიენტი, რაც უნდა ახალი იყოს, ამ შეცდომას მიიღებს, როცა შედის ანგარიშით, რომლის plugin სვეტშიც ჯერ კიდევ mysql_native_password წერია. იგივე შეცდომას ბრძანების სახითაც მიიღებ, როცა CREATE USER ... IDENTIFIED WITH mysql_native_password-ს ასრულებ - სტრიქონი, რომელიც ძალიან ბევრ ძველ ინსტალაციის ინსტრუქციასა და პროვიზიონინგის სკრიპტში გვხვდება. გაასწორე ანგარიში, ან 8.4-ზე ჩართე plugin; 9.x-ზე შესაძლებელია მხოლოდ პირველი.

Authentication plugin 'caching_sha2_password' cannot be loaded

სრული შეტყობინება ჩვეულებრივ გზით მთავრდება, მაგალითად /usr/lib/mysql/plugin/caching_sha2_password.so: cannot open shared object file. კლიენტი MySQL 5.7-ის ეპოქის ბიბლიოთეკასთანაა (ან ძველ MariaDB კლიენტის ბიბლიოთეკასთან) დაკავშირებული, რომელსაც caching_sha2_password არასდროს გაუგია, ამიტომ დისკზე plugin-ის ფაილს ეძებს და ვერაფერს პოულობს. ამ ფაილის შექმნა არ დაგეხმარება. განაახლე კლიენტი ან დრაივერი; ანგარიშის native plugin-ზე დაბრუნება არასწორი მიმართულებაა, რადგან 9.x ამას საერთოდ ვერ აკეთებს.

Authentication plugin 'mysql_native_password' cannot be loaded

ეს სარკისებური შემთხვევაა და გავრცელებული გახდა მას შემდეგ, რაც 9.x კლიენტები პაკეტების მენეჯერებში გამოჩნდა - განსაკუთრებით Homebrew-ის mysql ფორმულაში. 9.x კლიენტს native plugin აღარ მოჰყვება, ამიტომ მისი ძველ 5.7 სერვერზე, MariaDB სერვერზე ან ძველ plugin-ზე მყოფ 8.x ანგარიშზე მიმართვა კლიენტის მხარეს ვერ ხერხდება. გამოსწორების გზებია: გადაიყვანე ანგარიში caching_sha2_password-ზე, თუ სერვერი ამას უჭერს მხარს, ან გამოიყენე 8.4 LTS კლიენტი იმ სერვერებისთვის, რომლებიც ამას ვერ უჭერენ (Mac-ზე brew install mysql-client@8.4).

დრაივერების საკუთარი ფორმულირებები

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

Java-ს შემთხვევა ვერსიის პრობლემა არ არის: Connector/J plugin-ს იცნობს, მაგრამ ნაგულისხმევად უარს ამბობს RSA გასაღების მიღებაზე დაუშიფრავ კავშირზე. ეს იგივე სრული ავტორიზაციის სიტუაციაა, რაც ERROR 2061, რომელიც ქვემოთაა განხილული.

იპოვე ძველ plugin-ზე დარჩენილი ანგარიშები#

რამის შეცვლამდე ჩამოწერე ისინი. გაუშვი ეს root-ით ან სხვა ანგარიშით, რომელსაც mysql სქემის წაკითხვა შეუძლია:

SELECT user, host, plugin, password_last_changedFROM mysql.userWHERE plugin = 'mysql_native_password'ORDER BY user, host;

მოელოდე, რომ დაინახავ ძველი სკრიპტებით შექმნილ აპლიკაციის ანგარიშებს, 5.7 სერვერიდან dump-ითა და ჩატვირთვით გადმოტანილ ანგარიშებს (SHOW CREATE USER-ის შედეგს plugin-იც და ჰეშიც თან მოაქვს) და ზოგჯერ თავად root-საც. შიდა ანგარიშები, როგორიცაა mysql.sys, mysql.session და mysql.infoschema, მიმდინარე სერვერზე caching_sha2_password-ს იყენებენ და ჩაკეტილია; ნუ შეეხები.

გახსოვდეს, რომ ანგარიში მომხმარებლისა და ჰოსტის ერთობლიობაა, ამიტომ 'app'@'%' და 'app'@'localhost' ცალკე ჩანაწერებია და შეიძლება სხვადასხვა plugin ჰქონდეთ. აპლიკაციას, რომელიც ორი ადგილიდან უკავშირდება, პრობლემა შეიძლება მხოლოდ ერთი მათგანიდან შეექმნას. შესვლის შემდეგ SELECT CURRENT_USER(); გაჩვენებს, რომელ ჩანაწერს დაემთხვა სესია.

MySQL Shell-ის განახლების შემმოწმებელი იგივეს ფართო სკანირების ფარგლებში აჩვენებს, თუ განახლებამდე 8.0 სერვერს ამოწმებ:

$ mysqlsh root@db.example.net:3306 -- util check-for-server-upgrade --target-version=8.4.6

ანგარიშის გადაყვანამდე შეამოწმე კლიენტი#

ანგარიშის caching_sha2_password-ზე გადაყვანა მანამდე, სანამ მისი კლიენტი ამას მხარს დაუჭერს, ერთ გაუმართაობას მეორეზე ცვლის. ბოლო რამდენიმე წლის განმავლობაში გამოშვებული ყველაფერი რიგზეა; პრობლემა ძველი დაფიქსირებული დამოკიდებულებები და ძველი სისტემური პაკეტებია.

რამდენიმე პრაქტიკული შენიშვნა ზემოთ მოცემულ სტრიქონებზე.

PHP. მხარდაჭერა 7.1 და 7.2 სერიების განმავლობაში დაემატა, მაგრამ ასეთი ძველი PHP დიდი ხანია უსაფრთხოების მხარდაჭერას მოკლებულია და ისედაც უნდა განახლდეს. PHP 7.4-ზე და ყველა 8.x რელიზზე mysqli და pdo_mysql mysqlnd-ს იყენებენ და ორივე plugin-ს ამუშავებენ. WordPress-ის ან Laravel-ის საიტი, რომელიც "unknown to the client" შეტყობინებით ჩავარდება, თითქმის ყოველთვის ძველ PHP binary-ს იყენებს სადღაც, სადაც ამას არ ელოდები - cron container-ში ან ძველ image-ზე არსებულ CLI-ში - მაშინ როცა ვებ სერვერის PHP რიგზეა. კავშირის პარამეტრები განხილულია სტატიაში PHP PDO და MySQL.

Node.js. ორიგინალურ mysql პაკეტს caching_sha2_password არასდროს უმხარდაჭერია და ის პრაქტიკულად აღარ მოვლილობს. mysql2-ს უმეტესი კოდისთვის თითქმის იდენტური API აქვს, მხარს უჭერს ორივე plugin-ს და promise-ებს; უმეტეს პროექტში ცვლილება პაკეტის სახელსა და ერთ import ხაზზე მოდის. ისეთი ORM-ები, როგორიცაა Sequelize, Knex და TypeORM, MySQL-ისთვის მიმდინარე ვერსიებში უკვე mysql2-ს იყენებენ.

Python. mysqlclient (MySQLdb მოდული) იმ C კლიენტის ბიბლიოთეკის გარსია, რომელთანაც აიგო, ამიტომ მისი მხარდაჭერა მისი საკუთარი ვერსიის კი არა, ამ ბიბლიოთეკის ვერსიაზეა დამოკიდებული. MySQL 8-ის ან უფრო ახალი კლიენტის ბიბლიოთეკასთან აგებული wheel მუშაობს; ძველთან აგებული - არა.

დესკტოპ ხელსაწყოები. MySQL Workbench 8.x, DBeaver და HeidiSQL მიმდინარე ვერსიებში ახალ plugin-ს ამუშავებენ; პრობლემა წლების წინ დაინსტალირებული და არასდროს განახლებული ასლებიდან მოდის. თითოეულის კავშირის პარამეტრები იხილე სტატიაში MySQL GUI კლიენტები.

ანგარიშის გადაყვანა ALTER USER-ით#

ანგარიშის გადამყვანი ბრძანება მოკლეა და პაროლს საჭიროებს:

ALTER USER 'app'@'%'  IDENTIFIED WITH caching_sha2_password BY 'the-current-or-a-new-password';

ორი plugin-ის შენახული ჰეშები პაროლის სხვადასხვა ფუნქციაა და SHA-1 ჰეშის SHA-256-ად გადაქცევა შეუძლებელია. MySQL-ს plugin-ის შეცვლისა და ძველი ჰეშის შენახვის საშუალება არ აქვს, ამიტომ პაროლს თავად უთითებ - იმავეს, რომელსაც აპლიკაცია უკვე იყენებს, თუ იცი და კონფიგურაციის შეცვლა არ გინდა, ან ახალს. თუ მიმდინარე პაროლს ვერავინ იხსენებს, ეს შესაძლებლობაა, რომ ნორმალური პაროლი შექმნა და იქ ჩააწერო, საიდანაც აპლიკაცია კითხულობს.

ეს ბრძანება native plugin-ის ჩართვას არ საჭიროებს. სტანდარტულ 8.4 სერვერზე ან განახლების შემდეგ 9.x-ზე root-ს native ანგარიშის პირდაპირ გადაყვანა შეუძლია; ანგარიში მანამდე ვერ შევა, მაგრამ შეცვლა შესაძლებელია.

ბევრი ანგარიშის გადასაყვანად დააგენერირე ბრძანებები და პაროლები ხელით ან საიდუმლოებების საცავიდან ჩაწერე:

SELECT CONCAT('ALTER USER ', QUOTE(user), '@', QUOTE(host),  ' IDENTIFIED WITH caching_sha2_password BY ''CHANGE_ME'';') AS stmtFROM mysql.userWHERE plugin = 'mysql_native_password';

თითოეულის შემდეგ დაადასტურე შედეგი და გამოსცადე შესვლა ამ ანგარიშით იქიდან, სადაც აპლიკაცია მუშაობს:

SHOW CREATE USER 'app'@'%';

$ mysql -h db.example.net -P 3306 -u app -p --ssl-mode=REQUIRED -e "SELECT CURRENT_USER();"

გადაყვანა მომსახურების შეწყვეტის გარეშე

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

1. მეორე ანგარიში. შექმენი 'app2'@'%' caching_sha2_password-ით და იმავე უფლებებით (SHOW GRANTS FOR 'app'@'%' გაძლევს დასაკოპირებელ ბრძანებებს), გადართე აპლიკაციის კონფიგურაცია მასზე, გააკეთე deploy, დარწმუნდი, რომ ძველი ანგარიშით აღარაფერი უკავშირდება, და მერე DROP USER 'app'@'%'.
2. იგივე ანგარიში, იგივე პაროლი, სწრაფი deploy. თუ პაროლს უცვლელად დატოვებ, იცვლება მხოლოდ plugin. კლიენტები, რომლებიც caching_sha2_password-ს უკვე უჭერენ მხარს, კონფიგურაციის ცვლილების გარეშე თავიდან უკავშირდებიან, ამიტომ გადაყვანა შეუმჩნეველია, თუ დრაივერი წინასწარ განახლდა.

ორმაგი პაროლის ფუნქცია (RETAIN CURRENT PASSWORD) აქ არ გეხმარება: MySQL ამას არ უშვებს ALTER USER-ში, რომელიც ავტორიზაციის plugin-ს ცვლის.

TLS, RSA გასაღებები და პირველი შესვლის მარცხი#

როცა ანგარიშები caching_sha2_password-ზეა, დარჩენილი მარცხები იმას უკავშირდება, რომ სრულ ავტორიზაციას უსაფრთხო არხი სჭირდება. სუფთა პასუხი TLS-ია: MySQL 8.x პირველ გაშვებაზე თავად ქმნის თვითხელმოწერილ სერტიფიკატს და კლიენტის ბიბლიოთეკები TLS-ს ნაგულისხმევად ცდილობენ (--ssl-mode=PREFERRED). კლიენტი, რომელსაც TLS გამორთული აქვს, ან ბიბლიოთეკა, რომელიც TLS-ს ნაგულისხმევად არ იყენებს, RSA-ზე გადადის, ზოგი კი გასაღების მიღებაზე უარს ამბობს, სანამ არ უთხრა.

საჯარო გასაღების მიღება დაუშიფრავ კავშირზე ღიაა man-in-the-middle თავდასხმისთვის, რომელიც თავის გასაღებს ჩაანაცვლებს, ამიტომაც არის ის ნაგულისხმევად გამორთული. კერძო ქსელში ეს გონივრული კომპრომისია; ინტერნეტით კი გამოიყენე TLS და გასაღების მიღება გამორთული დატოვე. JDBC URL, რომელიც ამას სწორად აკეთებს, ასე გამოიყურება:

jdbc:mysql://db.example.net:3306/appdb?sslMode=REQUIRED

Unix socket უსაფრთხოდ ითვლება, ამიტომ იმავე მანქანაზე localhost-ით ლოკალური კავშირები ამას არასდროს აწყდებიან. დისტანციური კავშირები ის ადგილია, სადაც ეს მნიშვნელოვანია, ხოლო ქსელის მხარეს - firewall-ებს, bind მისამართებსა და სერტიფიკატის შემოწმებას - განიხილავს სტატია MySQL დისტანციური კავშირები.

mysql_native_password-ის უკან ჩართვა 8.4-ში#

როცა აპლიკაციის გასწორება დღეს შეუძლებელია - მაგალითად, ვენდორის binary-ს შიგნით ძველი კლიენტის ბიბლიოთეკა აქვს - 8.4 საშუალებას გაძლევს plugin ისევ ჩატვირთო. ეს სერვერის გაშვების პარამეტრია:

[mysqld]mysql_native_password=ON

ბრძანების ხაზის ფორმაა --mysql-native-password=ON, ასე იწერება ის Docker Compose-ის command: ხაზში. გადატვირთე სერვერი და შეამოწმე, რომ ამოქმედდა:

SELECT plugin_name, plugin_statusFROM information_schema.pluginsWHERE plugin_name = 'mysql_native_password';

სტატუსი ACTIVE ნიშნავს, რომ ძველ plugin-ზე მყოფი ანგარიშები ისევ შეძლებენ შესვლას. სხვა სტატუსის მქონე ჩანაწერი ან ჩანაწერის არარსებობა ნიშნავს, რომ პარამეტრი არ წაიკითხა - შეამოწმე, რომელ კონფიგურაციის ფაილებს ტვირთავს სერვერი სინამდვილეში, ბრძანებით mysqld --verbose --help | grep -A1 "Default options".

აქ ორ ხაფანგში ხშირად ვარდებიან. პირველია 8.0-ის ეპოქის პარამეტრი default_authentication_plugin=mysql_native_password, რომელსაც ბევრი ძველი Compose ფაილი და my.cnf ფრაგმენტი შეიცავს. ეს ცვლადი 8.4-ში ამოიღეს და სერვერი კონფიგურაციაში მისი არსებობისას არ ირთვება, შეცდომის ჟურნალში უცნობ ცვლადს აღნიშნავს. წაშალე ის; თუ ნამდვილად გჭირდება native ახალი ანგარიშების ნაგულისხმევად, 8.4-ში ეკვივალენტია authentication_policy, მაგრამ ახალი native ანგარიშების შექმნის მიზეზი თითქმის არ არსებობს სერვერზე, სადაც plugin-ს მომავალი არ აქვს. მეორე ხაფანგია ამ პარამეტრისგან 9.x-ზე მუშაობის მოლოდინი. იქ ის არ არსებობს და უცნობი პარამეტრი გაშვებას ზუსტად ასევე აფერხებს.

მართულ (hosted) ბაზაზე სერვერის კონფიგურაცია პროვაიდერს ეკუთვნის, ამიტომ ამის დაყენების შესაძლებლობა მასზეა დამოკიდებული. ამის ნაცვლად ანგარიშების გადაყვანას დაგეგმე; ეს წუთებში კეთდება და არავის ნებართვას არ საჭიროებს.

8.4-დან 9.x-ზე განახლება#

MySQL 9.x Innovation რელიზებსა და შემდეგ LTS-ს native plugin საერთოდ არ აქვს. განახლება, რომლის დროსაც native ანგარიშები ჯერ კიდევ არსებობს, წარმატებით სრულდება - სერვერი ირთვება და მონაცემები უვნებელია - მაგრამ ეს ანგარიშები გამოუყენებელია მანამ, სანამ ვინმე არ შეცვლის, შეცდომა კი იგივეა: Plugin 'mysql_native_password' is not loaded. თუ მათ შორის root-ია, იმ ვიღაცამ სხვა გზით უნდა შეძლოს შესვლა, ეს კი სწორედ ის --skip-grant-tables-ით რესტარტის სცენარია, რომლის თავიდან აცილებაც გინდა.

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

როცა ბაზას სერვერებს შორის ლოგიკური dump-ით გადაიტან, იგივე ეხება გადმოსატან ანგარიშებსაც. ძველი სერვერიდან დაკოპირებული SHOW CREATE USER ბრძანება შეიცავს IDENTIFIED WITH 'mysql_native_password' AS '*...'-ს და მისი 8.4-ზე გაშვება ვერ ხერხდება ან პრობლემას თავიდან ქმნის. ამის ნაცვლად ახალ სერვერზე ანგარიშები თავიდან შექმენი caching_sha2_password-ით - ამ გადატანას ეძღვნება სტატია MySQL-ის ახალ ჰოსტზე გადატანა. RE:NODE-ის MySQL გეგმები 8.4 LTS-ზე მუშაობს, root ანგარიში, აპლიკაციის ბაზა და აპლიკაციის მომხმარებელი კი მიმდინარე ნაგულისხმევ plugin-ზე გენერირდება, ამიტომ ანგარიშებს, რომლებითაც იწყებ, გადაყვანა არ სჭირდება; ძველი სერვერიდან მოტანილებს შეიძლება დასჭირდეს.

FAQ#

caching_sha2_password უფრო ნელია, ვიდრე mysql_native_password?

მხოლოდ სრულ ავტორიზაციაზე და მხოლოდ იმ დატვირთვისთვის, რომელიც ცარიელი cache-ით ყოველ მოთხოვნაზე ახალ კავშირს ხსნის. პირველი შესვლის შემდეგ ანგარიში cache-შია და სწრაფი ავტორიზაცია დაახლოებით იმავე ღირს, რაც ძველი plugin. connection pool, რომელსაც უმეტესი აპლიკაცია ისედაც იყენებს, განსხვავებას აქრობს; როგორ შეარჩიო მისი ზომა, ამას განმარტავს სტატია კავშირების ლიმიტები და pooling.

შემიძლია მომხმარებლის plugin-ის შეცვლა პაროლის ცოდნის გარეშე?

არა. plugin და ჰეში ერთად მიდის, MySQL კი შენახული SHA-1 ჰეშიდან SHA-256 ჰეშს ვერ გამოიყვანს. იმავე ALTER USER ბრძანებაში პაროლი უნდა დააყენო. თუ ძველი პაროლი დაკარგულია, დააყენე ახალი და განაახლე აპლიკაციის კონფიგურაცია.

რატომ მუშაობს შესვლა ჩემი ლეპტოპიდან, სერვერიდან კი არა?

ჩვეულებრივ იმიტომ, რომ ორ მანქანაზე სხვადასხვა კლიენტის ბიბლიოთეკა დგას. ლეპტოპზე მიმდინარე mysql CLI ან GUI ხელსაწყოა; სერვერზე აპლიკაცია კი image-ში ჩაშენებულ ან lock ფაილში დაფიქსირებულ ძველ დრაივერს იყენებს. შეადარე შეცდომის ზუსტი ტექსტი ზემოთ მოცემულ ცხრილს - ის გეტყვის, სერვერი უარყოფს თუ კლიენტი.

MariaDB-შიც იგივე ცვლილებაა?

არა, და აქ მათი ურთიერთშემცვლელად მიჩნევა არ შეიძლება. MariaDB ჯერ კიდევ mysql_native_password-სა და საკუთარ plugin-ებს იყენებს და სერვერზე MySQL-ის caching_sha2_password-ს არ ახორციელებს. სწორედ ამიტომ ვერ შედის MySQL 9.x კლიენტი ბევრ MariaDB სერვერზე: მან ერთადერთი plugin მოიშორა, რომელიც მათ აქვთ საერთო.

ALTER USER-ის შემდეგ მჭირდება FLUSH PRIVILEGES?

არა. ALTER USER მეხსიერებაში არსებულ უფლებებისა და ავტორიზაციის cache-ებს მაშინვე ანახლებს. FLUSH PRIVILEGES-ის მაინც გაშვება caching_sha2_password-ის cache-საც ასუფთავებს, რის გამოც ყველა ანგარიში შემდეგ შესვლაზე სრულ ავტორიზაციას გადის - TLS-ით ეს უვნებელია, TLS-ის გარეშე კლიენტებისთვის კი მოულოდნელი მარცხების წყარო.