MySQL-ის დისტანციური კავშირი: ჰოსტი, პორტი, TLS და კლიენტები

დისტანციურ MySQL სერვერთან დასაკავშირებლად ხუთი რამ გჭირდება: ჰოსტის სახელი ან IP მისამართი, პორტი, მომხმარებლის სახელი, მისი პაროლი და ბაზის სახელი. ამათით mysql -h host -P port -u user -p database prompt-ს გაძლევს, და იგივე ხუთი მნიშვნელობა ქმნის შენი აპლიკაციის connection string-ს. წარუმატებლობების უმეტესობა სამიდან ერთ-ერთი ადგილიდან მოდის: ქსელი (პორტი არასწორია ან მიუწვდომელია), ანგარიში (მომხმარებელი არსებობს სხვა host pattern-ისთვის, ვიდრე ის, საიდანაც უკავშირდები) ან ავთენტიკაციის plugin (ძველი კლიენტი, რომელმაც არ იცის caching_sha2_password, რომელსაც MySQL 8.4 ნაგულისხმევად იყენებს და რომელიც პირველად დაშიფრულ კავშირს ითხოვს).

ეს გზამკვლევი თითოეულ ნაწილს იმ თანმიმდევრობით გადის, რომლითაც მათ წააწყდები: საჭირო მონაცემები, command-line კლიენტი, დაშიფვრა და --ssl-mode, ავთენტიკაციის plugin, connection string-ები გავრცელებული runtime-ებისთვის, გრაფიკული ხელსაწყოები და შეცდომის შეტყობინებები, რომლებსაც ხალხი რეალურად აწყდება. აქ ყველაფერი MySQL 8.4 LTS-ს ეხება, შენიშვნებით იქ, სადაც 8.0 სხვანაირად იქცევა.

ხუთი მონაცემი და საიდან მოდის ისინი#

შენს საკუთარ მანქანაზე MySQL 3306-ზე უსმენს და ანგარიში, რომელსაც იყენებ, ხშირად root@localhost-ია. ჰოსტინგის ბაზაზე ამათგან არცერთი არ არის უსაფრთხო ვარაუდი. ჰოსტი არის ის მისამართი, რომელსაც პროვაიდერი გაძლევს, პორტი შეიძლება ნებისმიერი იყოს, ხოლო ანგარიში, რომელიც ყოველდღიურად უნდა გამოიყენო, არის აპლიკაციის მომხმარებელი უფლებებით ერთ ბაზაზე და არა root.

RE:NODE-ზე MySQL სერვერი იქმნება root პაროლით, აპლიკაციის ბაზით და აპლიკაციის მომხმარებლით, ყველა გენერირებული, და მასთან მიდიხარ გეგმის ჰოსტსა და პორტზე, რომლებიც პანელშია ნაჩვენები. სწორედ ეს ორი მნიშვნელობაა დასაკოპირებელი: 3306-ს ნუ გამოიცნობ. ბაზის გეგმებზე proxy სლოტი არ არის, ამიტომ სერვერს პირდაპირ ამ მისამართსა და პორტზე უკავშირდები და არა პანელის მიერ მართული დომენისა და სერტიფიკატის გავლით.

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

დაკავშირება mysql command-line კლიენტით#

mysql კლიენტი მოჰყვება MySQL სერვერის ყველა პაკეტს და მხოლოდ-კლიენტის პაკეტებს (mysql-client Debian-სა და Ubuntu-ზე, mysql Homebrew-ზე, MySQL Installer ან ZIP არქივი Windows-ზე). გამოიყენე 8.x სერიის ან უფრო ახალი კლიენტი. 8.0-ზე ძველი კლიენტები ნაგულისხმევ 8.4 ანგარიშზე ავთენტიკაციას ვერ გადიან, რაც ქვემოთაა განხილული.

$ mysql -h db.example.net -P 30412 -u app -p appdbEnter password:Welcome to the MySQL monitor.  Commands end with ; or \g.Server version: 8.4.6 MySQL Community Server - GPLmysql>

-p მის შემდეგ არაფრით კლიენტს პაროლს გკითხვინებს, რაც მას shell-ის ისტორიიდან და პროცესების სიიდან შორს ინახავს. -pSecret (გამოტოვების გარეშე) მუშაობს, მაგრამ პაროლს ~/.bash_history-ში ტოვებს. -p Secret (გამოტოვებით) იმას არ აკეთებს, რასაც ჰგავს: Secret ბაზის სახელად აღიქმება და პაროლს მაინც გკითხავს.

შესვლის შემდეგ შეამოწმე, სად აღმოჩნდი:

SELECT CURRENT_USER(), USER(), DATABASE(), @@version, @@port;

USER() არის სახელი და ჰოსტი, რომლითაც წარადგინე თავი; CURRENT_USER() არის ანგარიში, რომელსაც MySQL რეალურად დაამთხვია, და სწორედ მისი უფლებები მოქმედებს. თუ ეს ორი მოულოდნელად განსხვავდება - დაუკავშირდი როგორც app, მაგრამ დაემთხვა ''@'%', ანონიმური ანგარიში - იპოვე მიზეზი, რის გამოც შენი grant-ები თითქოს არ მუშაობს. \s (ან status) კავშირის შეჯამებას ბეჭდავს, მათ შორის იმასაც, დაშიფრულია თუ არა კავშირი:

SSL:                    Cipher in use is TLS_AES_256_GCM_SHA384Connection:             db.example.net via TCP/IPServer version:         8.4.6 MySQL Community Server - GPLProtocol version:       10

მონაცემების შენახვა option ფაილში

ყოველ ჯერზე ჰოსტისა და პორტის აკრეფა მოგბეზრდება. კლიენტი option ფაილებს კითხულობს და [client] ჯგუფი ~/.my.cnf-ში (ან %APPDATA%\MySQL\.mylogin.cnf ქვემოთ მოცემული ხელსაწყოს მეშვეობით) ნაგულისხმევ მნიშვნელობებს აწვდის:

[client]host=db.example.netport=30412user=appssl-mode=REQUIRED

პაროლი ჩვეულებრივ ფაილში ნუ ჩაწერ და კლიენტს დააცალე გკითხოს, ან გამოიყენე mysql_config_editor, რომელიც ბუნდოვან .mylogin.cnf-ს წერს:

$ mysql_config_editor set --login-path=prod --host=db.example.net \    --port=30412 --user=app --password$ mysql --login-path=prod appdb

ეს დაბუნდოვნება შემთხვევით მზერას აჩერებს და არა მონდომებულ მკითხველს. ორივე ფაილზე დააყენე chmod 600. კლიენტი უარს ამბობს ყველასთვის ჩასაწერად ღია option ფაილის წაკითხვაზე და ამას გეტყვის კიდეც.

დაშიფვრა: ssl-mode და რას ნიშნავს თითოეული მნიშვნელობა#

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

MySQL 8.x პირველი გაშვებისას data დირექტორიაში self-signed სერტიფიკატსა და გასაღებს აგენერირებს, თუ ოპერატორმა ეს არ გამორთო, და ამიტომაც სერვერების უმეტესობა TLS-ს თავიდანვე გთავაზობს. self-signed სერტიფიკატი კავშირს შიფრავს, მაგრამ ვერაფერს ამტკიცებს იმაზე, ვინ არის მეორე მხარეს, ამიტომ VERIFY_CA და VERIFY_IDENTITY მასზე ჩავარდება, თუ CA ფაილს არ მოგცემენ და მას --ssl-ca=ca.pem-ით არ გადასცემ.

საჯარო ინტერნეტით მისაწვდომი ბაზისთვის მინიმუმ REQUIRED დააყენე. თანამედროვე აპარატურაზე ეს გაზომვად არაფერს ჯდება და ხურავს შემთხვევას, როცა არასწორად კონფიგურირებული სერვერი ჩუმად ღია ტექსტამდე გამოგიყვანს. შემდეგ დაადასტურე \s-ით ან SQL-იდან:

SHOW SESSION STATUS LIKE 'Ssl_version';SHOW SESSION STATUS LIKE 'Ssl_cipher';

ცარიელი Ssl_cipher ნიშნავს, რომ session დაშიფრული არ არის. MySQL 8.4 ნაგულისხმევად მხოლოდ TLS 1.2-სა და 1.3-ს იღებს და ამოიღო ძველი სერვერის მხარის --ssl გადამრთველი და have_ssl ცვლადი; თუ გზამკვლევი have_ssl-ის შემოწმებას გეუბნება, ის 5.7-ისთვის ან 8.0-ისთვის დაიწერა.

სერვერსაც შეუძლია დაჟინება. REQUIRE SSL ანგარიშზე (ALTER USER 'app'@'%' REQUIRE SSL;) ამ მომხმარებელს ნებისმიერ დაუშიფრავ კავშირზე უარს ეუბნება, ხოლო require_secure_transport=ON - ყველას. ორივე ღირს ცოდნად, თუ root ანგარიში შენ გიჭირავს.

caching_sha2_password და პირველი კავშირის პრობლემა#

MySQL 8.0-დან ნაგულისხმევი ავთენტიკაციის plugin არის caching_sha2_password. MySQL 8.4-ში ძველი mysql_native_password plugin უბრალოდ მოდიდან კი არ გადავიდა - ის ნაგულისხმევად გამორთულია და სერვერის კონფიგურაციაში mysql_native_password=ON-ით უნდა ჩაირთოს, სანამ მისი გამომყენებელი რომელიმე ანგარიში შევა. MySQL 9.0-ში ის სულ ამოღებულია. ყველგან caching_sha2_password-ზე დაგეგმე.

plugin-ს ერთი თავისებურება აქვს, რომელიც დამაბნეველი შეცდომების უმეტესობას იწვევს. როცა მომხმარებელი სერვერის restart-ის (ან პაროლის შეცვლის) შემდეგ პირველად გადის ავთენტიკაციას, სერვერს ამ მომხმარებლის ქეშირებული hash არ აქვს და მის გამოსათვლელად პაროლი უსაფრთხოდ გამოგზავნილი სჭირდება. „უსაფრთხოდ“ ნიშნავს ერთ-ერთს:

1. კავშირი TLS-ით არის დაშიფრული და ამ შემთხვევაში პაროლი გვირაბის შიგნით მიდის, ან
2. კლიენტი სერვერის RSA საჯარო გასაღებს იღებს და პაროლს მისით შიფრავს.

თუ არცერთი არ სრულდება, შესვლა ამით ვარდება:

ERROR 2061 (HY000): Authentication plugin 'caching_sha2_password' reportederror: Authentication requires secure connection.

წამალი TLS-ის გამოყენებაა, რაც ისედაც უნდა აკეთებდე. თუ არ შეგიძლია, კლიენტს გასაღების მოთხოვნა შეუძლია --get-server-public-key-ით (command line), allowPublicKeyRetrieval=true-ით (JDBC) ან შენი driver-ის ეკვივალენტური ოფციით. დაუშიფრავ კავშირზე გასაღების მოთხოვნა ღიაა man-in-the-middle-ისთვის, რომელიც მას შეცვლის, და სწორედ ამიტომ არ არის ის ნაგულისხმევად ჩართული.

მეორე შეცდომა ძველ კლიენტებსა და ძველ driver-ებს ეკუთვნის:

Authentication plugin 'caching_sha2_password' cannot be loaded

ეს არის 5.7-ის ეპოქის კლიენტი, ძველი PHP mysqlnd ან ბიბლიოთეკა, როგორიცაა Node-ის ორიგინალი mysql პაკეტი (არა mysql2), რომელსაც ეს plugin არასოდეს უსწავლია. განაახლე კლიენტი ან driver. მომხმარებლის თავიდან შექმნა mysql_native_password-ით მხოლოდ მაშინ მუშაობს, თუ სერვერზე ეს plugin ჩართულია, ხოლო 8.4-ზე ის გამორთულია, თუ ვინმემ არ ჩართო - კლიენტის გამოსწორება უკეთესი გაცვლაა. MySQL 8.4 LTS: რა შეიცვალა ავთენტიკაციის ცვლილებების სრულ სიას შეიცავს.

Connection string-ები გავრცელებული runtime-ებისთვის#

ყველა driver-ს იგივე ხუთი მნიშვნელობა სჭირდება, სხვადასხვანაირად დალაგებული. შეინახე ისინი გარემოს ცვლადებში და string აწყე გაშვებისას; როგორ - ამას გარემოს ცვლადები და საიდუმლოებები ფარავს.

DB_HOST=db.example.netDB_PORT=30412DB_USER=appDB_PASSWORD=change-meDB_NAME=appdbDATABASE_URL=mysql://app:change-me@db.example.net:30412/appdb

URL ტყდება, თუ პაროლი შეიცავს @, :, / ან # სიმბოლოს, რადგან ისინი URL-ის სინტაქსის ნაწილია. ან percent-encode გაუკეთე (@ ხდება %40), ან ნაწილები ცალ-ცალკე გადაეცი, რასაც driver-ების უმეტესობა უშვებს.

import mysql from "mysql2/promise";const pool = mysql.createPool({  host: process.env.DB_HOST,  port: Number(process.env.DB_PORT),  user: process.env.DB_USER,  password: process.env.DB_PASSWORD,  database: process.env.DB_NAME,  connectionLimit: 10,  ssl: { rejectUnauthorized: false }, // TLS on, self-signed certificate accepted});

from sqlalchemy import create_engineimport osurl = (f"mysql+pymysql://{os.environ['DB_USER']}:{os.environ['DB_PASSWORD']}"       f"@{os.environ['DB_HOST']}:{os.environ['DB_PORT']}/{os.environ['DB_NAME']}"       "?charset=utf8mb4")engine = create_engine(url, pool_size=5, pool_recycle=1800,                       # TLS on; no CA given, so a self-signed cert is accepted                       connect_args={"ssl": {"check_hostname": False}})

$dsn = sprintf('mysql:host=%s;port=%d;dbname=%s;charset=utf8mb4',    getenv('DB_HOST'), getenv('DB_PORT'), getenv('DB_NAME'));$pdo = new PDO($dsn, getenv('DB_USER'), getenv('DB_PASSWORD'), [    PDO::ATTR_ERRMODE => PDO::ERRMODE_EXCEPTION,]);

jdbc:mysql://db.example.net:30412/appdb?sslMode=REQUIRED&characterEncoding=UTF-8

ორი პარამეტრი ყველა string-ში უნდა იყოს. სიმბოლოების ნაკრები უნდა იყოს utf8mb4, თორემ შენი აპლიკაცია ერთ დღეს emoji-ს ოთხ კითხვის ნიშნად შეინახავს - იხილე utf8mb4 და collation-ები. და რაღაცამ უმოქმედო კავშირები უნდა განაახლოს, სანამ სერვერის wait_timeout (ნაგულისხმევად 28800 წამი, რვა საათი) მათ დახურავს, თორემ წყნარი ღამის შემდეგ პირველი მოთხოვნა „MySQL server has gone away“-ით ჩავარდება. ამას SQLAlchemy-ში pool_recycle აგვარებს, სხვა driver-ებში კი pool-ის idle timeout. რამხელა უნდა იყოს თითოეული pool, ცალკე თემაა: MySQL-ის კავშირების ლიმიტები და pooling.

კონკრეტულად PHP-ისთვის PHP PDO და MySQL უფრო ღრმად შედის prepared statement-ებსა და შეცდომის რეჟიმებში, ხოლო C#-ის მხარე - MySqlConnector Oracle-ის Connector/NET-ის წინააღმდეგ - .NET PostgreSQL-ით, MySQL-ით ან SQL Server-ით-შია.

GUI ხელსაწყოები: Workbench, DBeaver, HeidiSQL და სხვები#

გავრცელებული გრაფიკული კლიენტებიდან ნებისმიერი გამოდგება და ყველა ერთსა და იმავე ველებს ითხოვს. განსხვავება ისაა, სად მალავენ TLS-ისა და საჯარო გასაღების ოფციებს.

• MySQL Workbench (Oracle, უფასო): Connection Method Standard (TCP/IP), ჰოსტი, პორტი, მომხმარებელი. SSL ჩანართზე Use SSL დააყენე Require-ზე. Workbench ყველაზე ახლოსაა სერვერის საკუთარ შესაძლებლობებთან, ვიზუალური EXPLAIN-ის ჩათვლით.
• DBeaver (უფასო community გამოცემა): ახალი MySQL კავშირი, შეავსე Server Host და Port. Driver properties ჩანართზე allowPublicKeyRetrieval დააყენე true-ზე, თუ TLS-ს არ იყენებ და საჯარო გასაღების შეცდომას აწყდები; SSL ჩანართზე მონიშნე Use SSL და self-signed სერტიფიკატისთვის სერტიფიკატის შემოწმება მოხსენი.
• HeidiSQL (Windows, უფასო): Network type MariaDB or MySQL (TCP/IP), შემდეგ SSL ჩანართი. მსუბუქი და სწრაფი, დათვალიერებისა და სწრაფი რედაქტირებისთვის კარგი.
• TablePlus, DataGrip, Beekeeper Studio: იგივე ველები, TLS SSL ან Advanced ჩანართის ქვეშ.

ყველასთვის საერთო ხაფანგი ჩაშენებული driver-ის ვერსიაა. ხელსაწყო, რომელსაც ძველი connector მოჰყვება, შეიძლება ზემოთ ნახსენები plugin-ის შეცდომით ჩავარდეს, მაშინაც კი, როცა command-line კლიენტი მუშაობს. ხელსაწყოს ან მის შიგნით არსებული driver-ის განახლება ამას აგვარებს. MySQL-ის GUI კლიენტების შედარება თითოეულს უფრო დეტალურად განიხილავს.

როცა კავშირი ვარდება: შეცდომების გაშიფვრა#

ERROR 2003 (HY000): Can't connect to MySQL server on 'db.example.net:3306' (110)

ქსელის წარუმატებლობა, სანამ MySQL-მდე მიღწევაც კი მოხერხდებოდა. შეცდომა 110 timeout-ია (რაღაც პაკეტებს აგდებს: firewall, არასწორი მისამართი), 111 არის „connection refused“ (მისამართი სწორია, მაგრამ ამ პორტზე არაფერი უსმენს). ჯერ პორტი შეამოწმე - შეტყობინებაში 3306 გამცემია იმისა, რომ კლიენტმა ნაგულისხმევი გამოიყენა, რადგან -P დაგავიწყდა. შემდეგ შეამოწმე, უშვებს თუ არა შენი საკუთარი ქსელი გამავალ კავშირებს ამ პორტზე; ზოგიერთი ოფისისა და კამპუსის ქსელი ვებ ტრაფიკის გარდა ყველაფერს ბლოკავს. nc -vz db.example.net 30412 ან Windows-ზე Test-NetConnection db.example.net -Port 30412 გეტყვის, პასუხობს თუ არა პორტი საერთოდ.

ERROR 1045 (28000): Access denied for user 'app'@'198.51.100.7' (using password: YES)

MySQL-მდე მიაღწიე და მან შესვლა უარყო. ან პაროლია არასწორი, ან არ არსებობს app ანგარიში, რომლის host pattern-იც შენს მისამართს 198.51.100.7 ემთხვევა. შეტყობინება აჩვენებს ჰოსტს, რომელიც MySQL-მა დაინახა, და სწორედ ის უნდა დაემთხვეს. using password: NO ნიშნავს, რომ კლიენტმა პაროლი საერთოდ არ გაგზავნა - ჩვეულებრივ -p აკლია ან გარემოს ცვლადი ცარიელია. MySQL-ის მომხმარებლები და უფლებები განმარტავს, როგორ ემთხვევა host pattern-ები.

ERROR 1044 (42000): Access denied for user 'app'@'%' to database 'other'

შეხვედი წარმატებით, მაგრამ მოითხოვე ბაზა, რომელზეც ანგარიშს უფლებები არ აქვს. დაუკავშირდი სწორ ბაზას ან grant მოითხოვე.

ERROR 1129 (HY000): Host '198.51.100.7' is blocked because of many connection errors

შენმა მისამართმა იმაზე მეტი წარუმატებელი handshake გააკეთა, ვიდრე max_connect_errors უშვებს (ნაგულისხმევად 100). ადმინისტრატორის უფლებების მქონე ვინმე ამას TRUNCATE TABLE performance_schema.host_cache;-ით ასუფთავებს. MySQL 8.4-ში FLUSH HOSTS აღარ არის; მისი შემცვლელი ეს TRUNCATE-ია (ან mysqladmin flush-hosts). შემდეგ იპოვე ის, რაც ვარდებოდა - ჩვეულებრივ health check, რომელიც TCP კავშირს ხსნის და შესვლის გარეშე ხურავს.

ERROR 1040 (HY000): Too many connections

სერვერმა max_connections-ს მიაღწია (ნაგულისხმევად 151). რაღაც კავშირებს აჟონავს ან pool იმაზე დიდია, ვიდრე სერვერს შეუძლია ზიდოს. ლიმიტის აწევა იშვიათად არის გამოსავალი; Connection pool-ები და ლიმიტები განმარტავს, რატომ.

ERROR 2013 (HY000): Lost connection to MySQL server during queryERROR 2006 (HY000): MySQL server has gone away

კავშირი მოკვდა. ჩვეული მიზეზები: სერვერმა უმოქმედო კავშირი wait_timeout-ის შემდეგ დახურა, ერთმა ბრძანებამ max_allowed_packet-ს გადააჭარბა (8.x-ში ნაგულისხმევად 64 MB), სერვერი გადაიტვირთა, ან შუაში მდგარმა ქსელურმა მოწყობილობამ დიდხანს უმოქმედო TCP session მოკლა. pool-ის კავშირები timeout-ზე უფრო ხშირად განაახლე და ამ შეცდომაზე თავიდან დაუკავშირდი.

დისტანციური ბაზის დაცვა#

ინტერნეტიდან მისაწვდომი ბაზა სამიზნეა იმ წამიდანვე, როგორც კი გაჩნდება. სკანერები ყოველ მისამართსა და პორტზე, რომელსაც პოულობენ, root-ს გავრცელებული პაროლებით მთელი დღე ცდიან. დაცვა რთული არ არის:

• აპლიკაციისთვის აპლიკაციის მომხმარებელი გამოიყენე და არა root. root ადმინისტრირებისთვის დაიტოვე და გრძელი გენერირებული პაროლი მიეცი.
• მოითხოვე TLS ყველაფრისთვის, რაც ინტერნეტს კვეთს.
• ყოველ აპლიკაციას საკუთარი მომხმარებელი მიეცი უფლებებით მხოლოდ საკუთარ ბაზაზე, რომ ერთი მონაცემის გაჟონვამ დანარჩენი არ გამოაჩინოს.
• შეცვალე პაროლი იმ წამს, როცა შეიძლება გაჟონილიყო (commit-ში მოხვედრილი .env, screenshot მხარდაჭერის თემაში) - MySQL 8 ორმაგ პაროლებს უჭერს მხარს RETAIN CURRENT PASSWORD-ით, ასე რომ შეცვლა გათიშვის გარეშე შეგიძლია.
• ადევნე თვალი წარუმატებელ შესვლებს. performance_schema.host_cache შეცდომებს თითო მისამართზე ითვლის.

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

FAQ#

რომელ პორტს იყენებს MySQL?

ნაგულისხმევად 3306-ს, ხოლო 33060-ს X Protocol-ისთვის, რომელსაც MySQL Shell-ის document store იყენებს. ჰოსტინგის სერვერს ნებისმიერ პორტზე შეუძლია მოსმენა, ამიტომ გამოიყენე ის, რომელსაც პროვაიდერი გაძლევს, და ნაგულისხმევს ნუ ივარაუდებ. თუ -P დაგავიწყდა, კლიენტი ჩუმად 3306-ზე გადადის.

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

იმიტომ, რომ localhost ნიშნავს „ეს მანქანა“ და MySQL-ში ასევე ნიშნავს „გამოიყენე Unix socket“. შენი ლეპტოპიდან localhost შენი ლეპტოპია. გამოიყენე სერვერის ჰოსტის სახელი ან მისამართი და დარწმუნდი, რომ არსებობს ანგარიში host pattern-ით, რომელიც იმ ადგილს ემთხვევა, საიდანაც უკავშირდები.

მჭირდება TLS, თუ ჩემი პაროლი ძლიერია?

კი. TLS-ის გარეშე ყოველი query და ყოველი შედეგი ქსელს ღია ტექსტად კვეთს, ხოლო caching_sha2_password restart-ის შემდეგ პირველი შესვლისთვის RSA გასაღების გაცვლაზე უნდა გადავიდეს. დააყენე --ssl-mode=REQUIRED ან მისი ეკვივალენტი შენს driver-ში.

როგორ გამოვასწორო „Authentication plugin caching_sha2_password cannot be loaded“?

განაახლე კლიენტი ან driver ისეთზე, რომელიც MySQL 8-ის ავთენტიკაციას უჭერს მხარს: 8.x ან უფრო ახალი mysql კლიენტი, Node-ში mysql2 და არა mysql, მიმდინარე PHP, მიმდინარე Connector/J. ანგარიშის mysql_native_password-ზე ჩამოყვანა მხოლოდ მაშინ მუშაობს, თუ 8.4 სერვერზე ეს plugin ჩართულია, ის კი ნაგულისხმევად გამორთულია.

შემიძლია დაკავშირება ბაზის მითითების გარეშე?

კი. command line-ზე ნუ მიუთითებ და შესვლის შემდეგ გაუშვი USE appdb;, ან ცხრილის სახელებს წინ ბაზის სახელი მიუწერე. აპლიკაციებმა ბაზა კავშირში უნდა დაასახელონ, რომ ყოველი query იქ გაეშვას, სადაც ელი.