خطأ 2002 (HY000): لا يمكن الاتصال بخادم MySQL المحلي من خلال المقبس '/var/run/mysqld/mysqld.sock' (2)

لقد واجهت هذه المشكلة في السابق وحلها عن طريق تثبيت mysql-server ، لذا تأكد من تثبيت mysql-server ، وليس mysql-client أو أي شيء آخر.

يعني هذا الخطأ أن الملف /var/run/mysqld/mysqld.sock غير موجود ، إذا لم تقم بتثبيت mysql-server ، فلن يكون الملف موجودًا. ولكن إذا كان mysql-server مثبتًا بالفعل وكان قيد التشغيل ، فأنت بحاجة إلى التحقق من ملفات التكوين.

ملفات التكوين هي:

/etc/my.cnf
/etc/mysql/my.cnf
/var/lib/mysql/my.cnf

في /etc/my.cnf ، قد يكون تكوين ملف socket هو /tmp/mysql.sock وفي /etc/mysql/my.cnf قد يكون تكوين ملف socket /var/run/mysqld/mysqld.sock. لذلك ، قم بإزالة أو إعادة تسمية /etc/mysql/my.cnf ، واسمحوا mysql استخدام /etc/my.cnf ، ثم قد يتم حل المشكلة.

جرب هذا:

mysql -h 127.0.0.1 -P 3306 -u root -p <database>

أيضًا (لمعرفة ما إذا كان يعمل):

telnet 127.0.0.1 3306 

ربما هو مجرد خطأ في ملف my.cnf ، في /etc/somewhere (حسب توزيع Linux ).

أرى كل هذه الإجابات ، لكن لا شيء / أعرض الخيار على إعادة تعيين كلمة المرور و لا إجابة مقبولة . السؤال الفعلي هو نسيت كلمة المرور الخاصة به ، لذلك يحتاج إلى إعادة تعيين ، لا نرى ما إذا كان يعمل أم لا (مثبت أم لا) لأن معظم هذه الإجابات تعني.

لإعادة تعيين كلمة المرور

اتبع هذه الخطوات (يمكن أن تكون مفيدة إذا نسيت كلمة مرورك حقًا ويمكنك تجربتها في أي وقت ، حتى لو لم تكن في موقف في الوقت الحالي):

1. إيقاف mysql

   Sudo /etc/init.d/mysql stop
   

   أو لإصدارات التوزيع الأخرى:

   Sudo /etc/init.d/mysqld stop
   

2. بدء الخلية في الوضع الآمن

   Sudo mysqld_safe --skip-grant-tables &
   

3. تسجيل الدخول إلى الخلية باستخدام الجذر

   mysql -uroot
   

4. حدد قاعدة بيانات MySQL لاستخدامها

   use mysql;
   

5. إعادة ضبط كلمة المرور

   update user set password=PASSWORD("mynewpassword") where User='root';
   

6. اغسل الامتيازات

   flush privileges;
   

7. أعد تشغيل الخادم

   quit
   

8. توقف وابدأ الخادم مرة أخرى

   أوبونتو وديبيان:

   Sudo /etc/init.d/mysql stop
   ...
   Sudo /etc/init.d/mysql start
   

   على CentOS و Fedora و RHEL:

   Sudo /etc/init.d/mysqld stop
   ...
   Sudo /etc/init.d/mysqld start
   

9. تسجيل الدخول بكلمة مرور جديدة

   mysql -u root -p
   

10. اكتب كلمة المرور الجديدة واستمتع بالخادم مرة أخرى كما لم يحدث شيء

تم أخذ هذا من إعادة تعيين كلمة مرور جذر MySQL.

التحديث مأخوذ من تعليق دانيال أدناه:

في MySQL 5.7 ، تمت إزالة حقل كلمة المرور في حقل جدول mysql.user ، والآن اسم الحقل هو "certification_string" ، لذلك يجب أن تكون الخطوة 5:

 update user set authentication_string=password('mynewpassword') where user='root';

جربت الخطوات التالية:

1. تسجيل الدخول كـ super user أو استخدام Sudo
2. افتح /etc/mysql/my.cnf باستخدام gedit
3. ابحث عن bind-address ، وقم بتغيير قيمته إلى عنوان IP الخاص بجهاز مضيف خادم قاعدة البيانات. بالنسبة لي ، كان localhost أو 127.0.0.1
4. أحفظ وأغلق الملف.
5. أعود إلى المحطة الطرفية وقم بتنفيذ Sudo service mysql start

وانها عملت بالنسبة لي.

لقد أصلحت هذه المشكلة عن طريق تنفيذ الأمر التالي:

mysql.server start

وإذا كنت تستخدم نظام التشغيل mac واستخدمت الشراب لتثبيت mysql ، فما عليك سوى استخدام:

brew services start mysql

كان لدي مشكلة مماثلة. لن تبدأ mysql:

Sudo service mysql start
start: Job failed to start

إذا قمت بتعطيل apparmor:

Sudo aa-complain /etc/apparmor.d/*

ذهبت المشكلة بعيدا. كانت المشكلة هي أن mysqld كان يحاول الوصول إلى /run/mysqld/mysqld.sock لكن ملف تعريف apparmor أعطى الإذن فقط لـ /var/run/mysqld/mysqld.sock (/ var/run مرتبط بـ/run ، لذلك هذه هي في الواقع نفس الشيء). لست متأكدًا من عدم استخدام mysqld لمسار var نظرًا لأنه تم تعيينه في جميع ملفات التكوين ، ولكن يمكنك حل المشكلة عن طريق إضافة ما يلي إلى /etc/apparmor.d/usr.sbin.mysqld

/run/mysqld/mysqld.pid rw,
/run/mysqld/mysqld.sock rw,

لقد حللت ذلك بقتل عملية mysql:

ps -ef | grep mysql
kill [the id]

ثم بدأت تشغيل الخادم مرة أخرى باستخدام:

Sudo /etc/init.d/mysql restart

لكن start يعمل أيضًا:

Sudo /etc/init.d/mysql start

ثم قمت بتسجيل الدخول كـ admin ، وقد انتهيت.

في حالتي ، كان القرص ممتلئًا ولم يتمكن mysqld من البدء.

محاولة إعادة تشغيل خدمة mysql.

خدمة إعادة تشغيل الخلية

أو

خدمة mysql توقف

خدمة mysql البداية

إذا لم يتعرف على أمر "stop" ، فهو بالتأكيد مساحة القرص. يجب أن تجعل بعض المساحة في قسم mysql مخصصة أو تجعل القرص أكبر.

تحقق من مساحة القرص مع

مدافع ح

بطريقة ما لم تنشئ عملية خادم MySQL المقبس ، أو أن العميل يبحث عن المقبس في المكان الخطأ.

سيكون اقتراحي الأول هو التحقق من تشغيل خادم MySQL. قد يكون الاقتراح الثاني ، هل يعمل خادم MySQL على مضيف آخر؟ إذا كان الأمر كذلك ، فأضف علامة -h <hostname> إلى عميل MySQL في الجهاز الطرفي.

إذا كان MySQL قيد التشغيل بالفعل ، ويتم تشغيله محليًا ، فتحقق من ملف my.cnf. يجب أن يكون هناك خط مثل

socket = /var/run/mysqld/mysqld.sock

معرفة ما إذا كان هذا يطابق موقع مأخذ التوصيل الذي ذكرته في مشاركتك.

من التجربة ، أود أن أقول أن السيناريو الأكثر ترجيحًا هو أن خادم MySQL الخاص بك إما أنه لا يعمل على الإطلاق أو أنه لا يعمل على المضيف نفسه حيث تقوم بتشغيل عميل MySQL الخاص بك من الجهاز الطرفي.

لقد واجهت نفس المشكلة بعد أن اضطررت إلى إعادة تشغيل خادم الإنتاج الخاص بي. أقوم بتشغيل Debian 8.1 (Jessie) على قطرة DigitalOcean.

هذا ما فعلته لحل مشكلتي:

1. تحقق من وجود الملف /var/run/mysqld/mysqld.sock. إذا لم يحدث ذلك ، فقم بإنشائه يدويًا عن طريق إدخال touch /var/run/mysqld/mysqld.sock (وهو ما كان علي فعله).

2. لذلك يمكن لعملية MySQL استخدام هذا الملف. تغيير ملكية الملف المذكور عن طريق إدخال chown mysql /var/run/mysqld/mysqld.sock.

3. بمجرد الانتهاء من "2" ، أعد تشغيل خدمة MySQL عن طريق إدخال service mysql restart أو /etc/init.d/mysql restart.

بعد الاطلاع على الخطوات المذكورة أعلاه ، تم حل مشكلتي. نادراً ما أواجه هذه المشكلة ، وربما يكون هناك طريقة أفضل ، لذلك ، يمكنك تقديم تعليقات بناءة إذا لزم الأمر :).

قد لا يعمل خادم mysql الخاص بك. تأكد من تشغيله عن طريق كتابة mysql.server start في الجهاز.

إليك ما الذي نجح لي:

ln -s /var/lib/mysql/mysql.sock /tmp/mysql.sock
service mysql restart

هذا يخلق رابط.

تحقق من المعلمة "bind-adress" في my.cnf.

جرب مع الأمر:

mysql -h 127.0.0.1 -P 3306 -u root -p

• -h للمضيف 127.0.0.1 ، أي مضيف محلي

• -P (إشعار -P كأحرف كبيرة) للمنفذ 3306 ، أي المنفذ الافتراضي لـ MySQL

إذا كنت تستخدم Amazon EC2 ، وكنت تواجه هذه المشكلة في المثيل ، فأنت بحاجة فقط إلى القيام بما يلي:

Sudo yum install mysql-server
Sudo service mysqld restart

لا يحتوي Amazon EC2 على خادم مثبت (يتم تثبيت العميل فقط) ، لذلك في حالة الحاجة إلى تثبيت ذلك على حالتك ، وبعد هذه المحاولة

 mysql -u root -p

للتحقق مما إذا كان ذلك يعمل.

أعتقد كلما حصلت على الخطأ

خطأ 2002 (HY000): لا يمكن الاتصال بخادم MySQL المحلي من خلال المقبس '/var/lib/mysql/mysql.sock'

سأوصي أولاً بالتحقق مما إذا كان البرنامج الخفي الخاص بـ mysql يعمل ... معظم الوقت لن يتم تشغيله افتراضيًا. يمكنك التحقق من ذلك بواسطة /etc/init.d/mysqld status.

إذا لم يكن قيد التشغيل ، فقم بتشغيله أولاً:

.../etc/init.d/mysqld start.

أراهن أنها ستعمل 110 ٪.

بدلاً من استخدام المضيف المحلي:

mysql -u myuser -pmypassword -h localhost mydatabase

استخدم 127.0.0.1

mysql -u myuser -pmypassword -h 127.0.0.1 mydatabase

(لاحظ أيضًا ، عدم وجود مسافة بين -p و mypassword)

استمتع :)

تأكد من أن لديك نسخ احتياطية من قواعد البيانات الهامة ثم حاول إزالة تثبيت MySQL الأشياء ذات الصلة:

apt-get remove --purge mysql\*

ثم تثبيته مرة أخرى :

apt-get install mysql-server mysql-client

هذا يعمل بالنسبة لي وتم حفظ البيانات.

إذا أظهر PHP MySQL أخطاء قد تضطر إلى إعادة تثبيت PHP MySQL :

apt-get install php5-fpm php5-mysql

إذا كان لديك XAMPP مثبتًا على جهاز Linux ، فحاول نسخ ملف my.cnf من /opt/lampp/etc/my.cnf إلى /etc/my.cnf.

بعد ذلك ، قم بتشغيل mysql -u root مرة أخرى ... يجب أن يكون لديك الآن المقبس الصحيح وتكون قادرًا على تشغيل عميل MySQL.

لقد حصلت على هذه المشكلة أيضًا ، لكني فعلت:

Sudo service mysql restart 

عملت معي.

لقد وجدت الحل

قبل إطلاق النار الأمر: mysql_secure_installation

• الخطوة 1: Sudo systemctl stop mariadb
• الخطوة 2: Sudo systemctl start mariadb
• الخطوة 3: mysql_secure_installation

بعد ذلك سوف يطلب كلمة مرور الجذر ويمكنك ببساطة اضغط أدخل وقم بتعيين كلمة مرور الجذر الجديدة.

في حالتي ، عملت من خلال القيام ببعض الأبحاث والتطوير:

أنا قادر على الاتصال باستخدام MySQL

root-debian#mysql -h 127.0.0.1 -u root -p

لكنه لا يعمل مع mysql -u root -p.

لم أجد أي رمز bind-address في my.cnf . لذا فقد تغلبت على المعلمة socket=/var/lib/mysql/mysqld.sock في my.cnf والتي كانت تسبب لي مشكلة في تسجيل الدخول.

بعد إعادة تشغيل الخدمة ، سارت الأمور على ما يرام:

[email protected]:~# mysql -u root -p
Enter password:
Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 5
Server version: 5.6.19 MySQL Community Server (GPL)

في حالتي ، كان المنفذ الافتراضي 3306 قيد الاستخدام من قبل بعض العمليات الأخرى ، وبالتالي لم يكن قيد التشغيل. بعد أن توقفت عن الخدمة الأخرى وفعلت Sudo service mysql start ، عملت بشكل جيد. راجع للشغل ، يمكنك استخدام شيء مثل Sudo lsof -Pn -iTCP:3306 لمعرفة من الذي قد يستخدم المنفذ.

افتح الجهاز ونوع:

Sudo apt-get purge mysql-client-core-5.6

Sudo apt-get autoremove

Sudo apt-get autoclean

Sudo apt-get install mysql-client-core-5.5

Sudo apt-get install mysql-server  

سيكون كل من عميل MySQL الأساسي وحزم خادم MySQL هو نفس الإصدار 5.5. يعد MySQL Client 5.5 و MySQL Server 5.5 الإصدارات الحالية "الأفضل" من هذه الحزم في Ubuntu 14.04 وفقًا لما يحدده مشرفو الحزمة.

إذا كنت تفضل تثبيت MySQL Client 5.6 و MySQL Server 5.6 ، يمكنك أيضًا العثور على حزم mysql-client-core-5.6 و mysql-server-5.6 في Ubuntu Software Center. الشيء المهم هو أن أرقام إصدار العميل والخادم تتطابق في كلتا الحالتين.

هذا عملت لي.

إذا كان التثبيت الخاص بك مؤخرًا ، فيجب تأكيد ما إذا كان التثبيت الخاص بك هو خادم التثبيت ... مثل mysql-server-5.5 .. ربما قمت بتثبيت "mysql" فقط .. هذا هو العميل فقط بدلاً من الخادم.

في حالتي ، يبدو أنني لم أتمكن حقًا من قتل عملية mysql ، عندما أركض

Sudo service mysql stop
ps -ef | grep mysql

كانت عملية mysql موجودة دائمًا ، يبدو أنها كانت تمنع ملف مأخذ التوصيل ولم تتمكن عملية mysql الجديدة من إنشائها بنفسها.

لذلك ساعد هذا

cd /var/run
Sudo cp mysqld/ mysqld.bc -rf
Sudo chown mysql:mysql mysqld.bc/
Sudo service mysql stop
Sudo cp mysqld.bc/ mysqld -rf
Sudo chown mysql:mysql mysqld -R
Sudo /usr/sbin/mysqld --skip-grant-tables --skip-networking &

الآن أنا قادر على تسجيل الدخول باستخدام قاعدة البيانات

mysql -u root

ثم لتحديث كلمة مرور الجذر:

UPDATE user SET authentication_string=password('YOURPASSWORDHERE') WHERE user='root';
FLUSH PRIVILEGES;

PS: واجهت مشكلة في تحديث passwod الجذر ، يبدو وكأنه مشكلة مع البرنامج المساعد "auth_socket" ، لذلك اضطررت لإنشاء مستخدم جديد مع امتيازات كاملة

insert into user set `Host` = "localhost", `User` = "super", `plugin` = "mysql_native_password", `authentication_string` = NULL, `password_expired` = "N", `password_lifetime` = NULL, `account_locked` = "N", `Select_priv` = "Y",
`Insert_priv` = "Y", `Update_priv` = "Y", `Delete_priv` = "Y", `Create_priv` = "Y", `Drop_priv` = "Y", `Reload_priv` = "Y", `Shutdown_priv` = "Y", `Process_priv` = "Y", `File_priv` = "Y",
`Grant_priv` = "Y",  `References_priv` = "Y", `Index_priv` = "Y", `Alter_priv` = "Y", `Show_db_priv` = "Y", `Super_priv` = "Y", `Create_tmp_table_priv` = "Y", `Lock_tables_priv` = "Y",
`Execute_priv` = "Y", `Repl_slave_priv` = "Y",  `Repl_client_priv` = "Y",  `Create_view_priv` = "Y", `Show_view_priv` = "Y", `Create_routine_priv` = "Y", `Alter_routine_priv` = "Y",
`Create_user_priv` = "Y",  `Event_priv` = "Y", `Trigger_priv` = "Y", `Create_tablespace_priv` = "Y";

يؤدي هذا إلى إنشاء مستخدم "super" بدون كلمة مرور ، ثم يمكنك الاتصال بـ mysql -u super

بالتجربة أقول إنك بحاجة إلى التحقق مما إذا كان الخادم يعمل أولاً ثم حاول تكوين MySQL. الحل الأخير هو إعادة تثبيت الخلية.

على خادم دبيان جيسي ، كان حل عملي هو القيام بكل بساطة

service mysql restart
service mysql reload

كمستخدم الجذر

كان لي نفس القضية. يحدث هذا في بعض الأحيان إذا تم إيقاف خدمة MySQL الخاصة بك.

لذلك عليك أن تبدأ ذلك:

Sudo service mysql start

أواجه أيضًا نفس المشكلة ، فستحدث هذه المشكلة إذا لم يتم تشغيل رمز mysql server الخاص بك افتراضيًا ، فسيتوقف مرة أخرى بعد بعض ثوانٍ حتى تتمكن من تشغيل الأمر ($ Sudo service mysql start) مرة أخرى ، ويمكنك تغييره إذا كنت تعرف ذلك.

لذلك استخدام القيادة

$ Sudo service mysql start   

(ضع كلمة مرور المستخدم إذا لزم الأمر لأننا نستخدم Sudo) ثم نركض

$ Sudo mysql -u root -p          (put user password if required )

الآن لديك قاعدة البيانات الخاصة بك

mysqld stop
mysql.server start

انه يعمل الان...

لقد تابعت البرنامج التعليميتثبيت MariaDB 10.1.16 على نظام Mac OS X مع Homebrewللتغلب على هذه المشكلة.

ولكن لا تنسَ قتل أو إلغاء تثبيت التثبيت القديم لـ MariaDB.

أنا حل هذه المشكلة مع إعادة تشغيل الخلية

/etc/init.d/mysql stop

و

/etc/init.d/mysql start

هذا هو.

كان لي نفس المشكلة. بعد الكثير من البحث لم أجد أي إجابة.

أخيرًا ، راجعت دليل /tmp ، وكانت أذوناته 755. لقد غيرت أذوناته إلى 777 وبدأ mysqld جيدًا دون أي مشكلة.

الشيء نفسه على أوبونتو 14.04 (مضمونة طاهر).

إذا قمت بتثبيت XAMPP ، فإن تثبيت mysql-server ليس هو الحل ، لأنك ستصل إلى MySQL آخر!

يجب عليك استخدام المقبس الصحيح للوصول. عادة ما يكون هذا:

/opt/lampp/var/mysql/mysql.sock

بدلاً من ذلك ، قم بتغييره إلى:

/var/run/mysqld/mysqld.sock

تحقق مما إذا كان لديك الحقوق الصحيحة:

Sudo chmod 755 /var/lib/mysql/mysql

عانيت من نفس المشاكل وهذا الأمر يعمل لي. بعد القيام بذلك ، تمكنت من تشغيل MySQL.

كانت وحدة تخزين الخادم الخاصة بي ممتلئة ، مما حال دون بدء تشغيل Mysql. حصلت على الفكرة من هنا . زيادة HD وإعادة التشغيل إصلاح المشكلة.

يمكنك أولاً التحقق مما إذا كانت الخدمة تعمل ، مع:

ps ax | grep mysql

حصلت على هذا الرد:

6104 pts/0    S      0:00 /bin/sh /usr/bin/mysqld_safe
6431 pts/0    Sl     0:01 /usr/sbin/mysqld --basedir=/usr --datadir=/var/lib/mysql --plugin-dir=/usr/lib/mysql/plugin --user=mysql --pid-file=/var/run/mysqld/m

لا توجد استجابة تعني أن الخدمة لا تعمل ، وكذلك:

service  mysql start

ما عليك سوى نسخ ملف /opt/lampp/etc/my.cnf الخاص بك إلى /etc/mysql/my.cnf.

وفي نوع المحطة:

mysql -u root

سوف تحصل على mysql> الموجه:

mysql> Update mysql.user set Password=PASSWORD('your_password') where user='root';

mysql> FLUSH PRIVILEGES;

لا أستطيع أن أشرح ذلك ، لكن في kubuntu 12.04.2 بعد

Sudo apt-get autoremove linux-headers-3.2.0-37 linux-headers-3.2.0-37-generic

بدأت العمل

أنت تفتقد الإذن لإنشاء/var/run/mysqld directory.So الرجاء إنشاء وإعطاء إذن على النحو التالي.

• mkdir -p/var/run/mysqld
• chown mysql: mysql/var/run/mysqld

بالنسبة لي تحديث حل المشكلة:

على أوبونتو:

Sudo apt-get update
Sudo apt-get upgrade

على CentOS:

Sudo yum update

تثبيت خادم mysql:

Sudo apt-get install mysql-server
enter password as root

تسجيل الدخول:

mysql -u root -p root

هنا تم تقديم -u user name و -p password أثناء تثبيت خادم MySQL. ستعمل كما عملت بالنسبة لي.

في حالتي ، كانت المشكلة تلف الصفحة في جميع قواعد البيانات الخاصة بي (راجع سجل أخطاء mysql).

أنا حلها مع إجبار InnoDB Recovery . الخدعة هي تحرير/etc/mysql/my.cnf وإضافة

innodb_force_recovery = 4

فقط اسفل

[mysqld]

ثم أعد تشغيل الخلية. بعد التحقق من أن كل شيء يعمل بشكل صحيح الآن ، قم بإزالة السطر مرة أخرى.

For CentOS Linux release 7.3
The mysql.sock file path is /var/lib/mysql/mysql.sock
Edit /etc/my.cnf file and put below entry
This will solve your problem.

[client]
user=root
password=Passw0rd
port=3306
socket=/var/lib/mysql/mysql.sock
[mysqld]
bind-address=0.0.0.0

بعد هذا إعادة تشغيل الخدمة

service mysql restart

ترتبط هذه الإجابة بالتحديث إلى MySQL 5.6 على الأجهزة التي تحتوي على كمية صغيرة من RAM

واجهت نفس المشكلة عند الترقية من MySQL 5.5 إلى 5.6 على Debian 8 (Jessie). لم يتم بدء تشغيل MySQL (كانت الحالة تظهر نشطة/منتهية) وببساطة لا يعمل service mysql start ، لأنه كما وجدت من ملف السجل /var/logs/mysql/error.log:

InnoDB: Initializing buffer pool, size = 128.0M
InnoDB: mmap(136019968 bytes) failed; errno 12
Cannot allocate memory for the buffer pool

الذاكرة لم تكن كافية: كان لدي فقط 256 ميغابايت من ذاكرة الوصول العشوائي.

في MySQL هناك إعداد ، performance_schema. بشكل افتراضي ، يتم إيقاف تشغيله في MySQL 5.5.

https://dev.mysql.com/doc/refman/5.5/ar/performance-schema-startup-configuration.html

ولكن في MySQL 5.6 ، يكون الإعداد الافتراضي قيد التشغيل ، وببساطة عن طريق إضافة السطر التالي في ملف /etc/mysql/my.cnf وإعادة التشغيل ، فقد نجح.

performance_schema = off

تحذير: إيقاف تشغيل هذا الإعداد قد تواجه مشكلات في الأداء ، لكن أعتقد أنه في بيئة التطوير لن تكون هناك مشكلة.

أيضًا ، إليك مقالة قد تكون مفيدة في تكوين MySQL لاستخدام الحد الأدنى من الذاكرة ، {تهيئة MySQL لاستخدام الحد الأدنى من الذاكرة.

إذا كنت تستخدم Ubuntu ، فقد تكون مسألة امتيازات.

تحقق من امتيازات الدليل الخاص بك. لا يكفي أن تكون في مجموعة الجذر ، كما استخدم chmod في الدلائل التي يكتبها MySQL (على سبيل المثال ، /var/run/mysqld/ لإنشاء ملف mysqld.pid).

كان هذا مفيدا بالنسبة لي.

حاول إعادة تشغيل الخادم مع

Sudo /usr/local/mysql/support-files/mysql.server start

إذا كان هناك أي خطأ ، فاتبع الخطوات التالية

1. mysqldname__

سترى السجل أدناه. لاحظ الجزء المميز من دليل MySQL هنا

mysqld: لا يمكن تغيير dir إلى '/usr/local/mysql-5.7.14-osx10.11-x86_64/data/' (خطأ: تم رفض الإذن) 2016-10-04T14: 09: 19.392581 Z 0 [تحذير] تم إهمال TIMESTAMP مع قيمة DEFAULT الضمنية. يرجى استخدام خيار الخادم - Explicit_defaults_for_timestamp (انظر الوثائق لمزيد من التفاصيل). 2016-10-04T14: 09: 19.392847Z 0 [تحذير] التكوين غير الآمن لـ - الآمن - ملف - خاص: القيمة الحالية لا تقيد موقع الملفات التي تم إنشاؤها. فكّر في تعيينه إلى مسار صالح وغير فارغ. 2016-10-04T14: 09: 19.392921Z 0 [Note] mysqld (mysqld 5.7.14) يبدأ كعملية 1402 ... 2016-10-04T14: 09: 19.397569Z 0 [تحذير] لا يمكن إنشاء ملف اختبار
/البيرة/المحلية/ماي-5.7.14-osx10.11-x86_64/البيانات/Sudharshan.lower اختبار
2016-10-04T14: 09: 19.397597Z 0 [تحذير] لا يمكن إنشاء ملف اختبار/usr/local/mysql-5.7.14-osx10.11-x86_64/data/Sudharshan.lower-test
2016-10-04T14: 09: 19.397712Z 0 [خطأ] فشل في تعيين datadir إلى /usr/local/mysql-5.7.14-osx10.11-x86_64/data/
2016-10-04T14: 09: 19.397776Z 0 [خطأ] إحباط
2016-10-04T14: 09: 19.397795Z 0 [ملاحظة] نهاية Binlog
2016-10-04T14: 09: 19.397925Z 0 [ملاحظة] mysqld: الإغلاق الكامل

2. Sudo chown -R _mysql:_mysql /usr/local/mysql-5.7.14-osx10.11-x86_64

لاحظ مسار مجلد MySQL/usr/local في السجل السابق ، وفي حالتي كان mysql-5.7.14-osx10.11-x86_64 ، وعليك تحديثه استنادًا إلى السجل الذي تحصل عليه على جهازك لتوفير وصول للقراءة إلى دليل MySQL

3. Sudo /usr/local/mysql/support-files/mysql.server start

بدء الخلية
نجاح!

تحقق أيضًا من my.conf (/etc/mysql/my.cnf) وانظر إذا كان عنوان الربط مضبوطًا على 127.0.0.1.

إذا لم يكن كذلك ، فقد يتسبب هذا في حدوث هذه المشكلة.

بالنسبة لي كان:

افتح /etc/mysql/my.cnf أو /etc/my.cnf وابحث عن "ربط عنوان". كان 127.0.0.1. لقد قمت بتحويله إلى مضيف محلي ، لذلك يجب أن تكون نتيجة السطر 'bind-address = localhost'.

خلاف ذلك ، يجب عليك تشغيل خادم MySQL الخاص بك بعنوان IP الموجود في توجيه عنوان الربط ، أي mysql -h 127.0.0.1.

لقد واجهت هذه المشكلة الآن وحلها.

على الرغم من أنك قمت بتثبيت خادم mysql ، إلا أن البرنامج الخفي يجب أن يعمل حتى يتمكن العميل من الاتصال به.

تحقق أولاً لمعرفة ما إذا كان خادم mysql يعمل:

netstat -tap | grep mysql

يجب أن نرى شيئا من هذا القبيل:

$ Sudo netstat -tap | grep mysql
tcp        0      0 localhost:mysql         *:*          LISTEN     6639/mysqld     

إذا لم يكن لديك خادم يعمل ، فقم بتشغيل البرنامج الخفي بالأمر التالي:

/etc/init.d/mysql restart

هذا يجب أن يحل مشكلتك إذا تم تثبيته.

حل بسيط على الخادم الخاص بي: بعد الترحيل إلى خادم Debian 7 جديد باستخدام قواعد بيانات MySQL ، كان الثاني عنوان IP المحلي ، 127.0.1.1 ، مفقودًا في ملفي hosts . تؤدي إضافة هذا إلى حل التحذيرات:

echo -e "\n127.0.1.1       $(hostname)" >> /etc/hosts

لمنع حدوث المشكلة ، يجب إجراء إيقاف تشغيل رشيق للخادم من سطر الأوامر بدلاً من إيقاف تشغيل الخادم.

shutdown -h now

سيؤدي ذلك إلى إيقاف خدمات التشغيل قبل إيقاف تشغيل الجهاز.

استنادًا إلى Centos ، هناك طريقة إضافية لاستعادتها مرة أخرى عندما تواجه هذه المشكلة وهي نقل mysql.sock:

mv /var/lib/mysql/mysql.sock /var/lib/mysql/mysql.sock.bak

service mysqld start

تؤدي إعادة تشغيل الخدمة إلى إنشاء إدخال جديد يسمى mqsql.sock

أنت تعمل محليًا ، مما يعني أن عميلك يعمل على نفس جهاز الخادم الخاص بك.

تأكد من أن مستخدم Unix يمكنه الوصول/قراءة /var/run/mysqld/mysqld.sock فعليًا:

ls -als /var
ls -als /var/run
ls -als /var/run/mysqld
ls -als /var/run/mysqld/mysqld.sock

إذا لم يكن الأمر كذلك ، تحقق مع مسؤول النظام أو مسؤول قاعدة البيانات لتوفير وصول القراءة/التنفيذ الكافي إلى تلك الدلائل ، أو انقل ملف مأخذ التوصيل إلى مكان آخر.

كان لي نفس القضية. لقد وجدت هذا.

ERROR 2002 (HY000): Can’t connect to local MySQL server through socket ‘/var/lib/mysql/mysql.sock’

هذا لأنك لا تقوم بتشغيل البرنامج الخفي mysqld قبل بدء تشغيل عميل MySQL. سيتم إنشاء الملف /var/lib/mysql/mysql.sock تلقائيًا عند تشغيل أول مثيل لـ MySQL.

لإصلاح:

أولاً ابدأ تشغيل البرنامج الخفي MySQL ، ثم اكتب mysql:

/etc/init.d/mysqld start
mysql

تغيير كلمة المرور الجذر الخلية

افتراضيًا ، تكون كلمة مرور الجذر فارغة لقاعدة بيانات MySQL. إنها فكرة جيدة تغيير كلمة مرور الجذر MySQL إلى كلمة مرور جديدة من وجهة نظر الأمان.

mysql> USE mysql;
mysql> UPDATE user SET Password=PASSWORD('newpassword') WHERE user='root';
mysql> FLUSH PRIVILEGES;

بمجرد الانتهاء من ذلك ، تحقق من خلال تسجيل الدخول:

mysql -u root -p
Enter Password: <your new password>

Sudo touch /var/lib/mysql/.force_upgrade
Sudo rcmysql restart

عملت بالنسبة لي عندما كان لي هذه المشكلة

يمكن أن يحدث هذا الخطأ أيضًا إذا حاولت تغيير الدليل حيث يتم تخزين قاعدة البيانات ، ولكن فرض الدليل الخطأ في ملف التكوين (مثل خطأ مطبعي في محرك الأقراص الثاني كـ D بدلاً من D_ الدقيق). بدلاً من إخبارك بأن دليل الخطأ المطبعي غير موجود ، فإنه سيخبرك أنك لا تملك إذنًا بالوصول إليه (مما سيؤدي إلى محاولة تغيير أذونات دليل الأخطاء المطبعية ، والذي سيسمح لك بذلك). لذلك إذا حصلت على هذا الخطأ أثناء تغيير الدلائل ، فتحقق من ملف التكوين وتأكد من عدم وجود خطأ مطبعي.

هل تأكدت من تشغيل XAMPP؟

Sudo bash <path>/lampp start

بالنسبة لي ، المسار هو

Sudo bash /opt/lampp/lampp start

كنت أواجه هذه المشكلة أيضًا ولم تساعدني أي من هذه الإجابات. كانت المشكلة مختلفة ، ولكن الخطأ كان هو الوصف الذي حدده البروتوكول الاختياري.

أتحقق من سجلات MySQL في /var/log/mysql ، ورأيت هذا:

150309  5:03:19 [ERROR] /usr/sbin/mysqld: unknown variable   'lower_case_tables_names=1'

لقد فتحت الملف /etc/mysql/my.cnf وأنفقت على ذلك السطر #. بعد القيام بذلك ، تمكنت من الاتصال بقاعدة البيانات.

بصراحة أنا لا أعرف ما هي المشكلة. تمت جدولة إعادة تشغيل خادم linode بسبب الصيانة ، ولم يظهر هذا الخطأ في أي مكان.

يجب عليك التحقق من مالك المجموعة لـ /var/run/mysqld. إذا لم تكن mysql.mysql ، فقم بما يلي:

su root
chown mysql.mysql /var/run/mysqld

قد تكون مشكلة في ملف التكوين. واجهت مشكلة مماثلة ، ولم أجد حلاً على الويب. لقد لاحظت أن لدي ملفين my.cnf ، أحدهما في /etc/mysql والآخر في /etc. اتبع الخطوات التالية:

1. تحقق من وجود ملفات my.cnf على جهاز الكمبيوتر الخاص بك باستخدام locate my.cnf.

2. إذا كان هناك إدخالان ، أي /etc/my.cnf و /etc/mysql/my.cnf ، فأعد تسمية /etc/mysql/my.cnf إلى شيء آخر ، على سبيل المثال /etc/mysql/my.cnf.old

حاول تشغيل MySQL مرة أخرى.

لقد كانت حالتي بسبب توقف mysql بسبب مجلد /var/log/mysql المفقود المحدد في /etc/mysql/my.cnf. بعد إنشائه ، يمكنني أن أبدأ mysql وقد استمر كالعادة.

ترقية MySQL إصلاحه بالنسبة لي. على الخوادم القائمة على RHEL ، فقط قم بتشغيل:

Sudo yum upgrade mysql-server

لقد قمت بحل هذه المشكلة عن طريق إزالة هذا السطر من /etc/mysql/my.conf في قسم mysqld ([mysqld]):

default-character-set=utf8

إعادة التشغيل وأنه يعمل بشكل جيد.

كان لي هذا على Ubuntu وكما لاحظت ، كان هناك أكثر من مثيل لمايكلد.

يبدو أن الشكل السابق لم يتوقف بالكامل ، في حين أن الجديد قد بدأ بالفعل. لم يكن تشغيل "/etc/init.d/mysql stop" مفيدًا ، فقد كان دائمًا ما يُرجع "OK" وتم إطلاق مثيل جديد تلقائيًا بعد ذلك مباشرةً:

        $ Sudo /etc/init.d/mysql stop
         * Stopping MySQL database server mysqld        [ OK ] 
        $ pgrep mysql
        28315
        $ Sudo /etc/init.d/mysql stop
         * Stopping MySQL database server mysqld        [ OK ] 
        $ pgrep mysql
        28570
        $ Sudo /etc/init.d/mysql stop
         * Stopping MySQL database server mysqld        [ OK ] 
        $ pgrep mysql
        28763
        ..... etc ...

لحسن الحظ ، قام الأمر التالي بإصلاح المشكلة:

    $ Sudo service mysql stop
    mysql stop/waiting

    $ ps -ef | grep mysql
    29841 26858  0 10:59 pts/8    00:00:00 grep --color=auto mysql <--- IT's gone ! 

بعد ذلك تمكنت من بدء mysql مرة أخرى ورؤية أنه تم إنشاء mysql.sock بنجاح.

نصيحة: اسأل دائمًا MySQL عن المشكلة. في حالتي ، less /var/log/mysql/error.log وشاهد هذا:

2015-07-28 12:01:48 23224 [ERROR] /usr/sbin/mysqld: unknown variable 'log_slow_queries=/var/log/mysql/mysql-slow.log'
2015-07-28 12:01:48 23224 [ERROR] Aborting

إنه يشكو ، لأنني ألغيت هذا الخيار في my.cnf ، لكن بعد التعليق على هذا الخيار ، بدأ دون أي مشكلة.

في /etc/mysql/my.cnf ، تحقق من السطر الأخير ليكون:

!includedir /etc/mysql/conf.d/

من المحتمل أن تغرق هذه الإجابة هنا ، لكن ربما يتعثر أحدهم بطريق الخطأ.

في حالتي ، منعت SELinux المستخدم/التطبيق من الاتصال بمقبس خادم MySQL (MariaDB). على RHEL ، تحقق من /var/log/audit/audit.log إذا كان لديك SELinux ممكّنًا.

في Ubuntu 18:10 Linode 1GB Ram ، لقد واجهت هذا الخطأ. بعد فحص /var/log/mysql/error.log ، صادفت هذا:

[ملاحظة] InnoDB: innodb_empty_free_list_algorithm قد تم تغييره إلى القديمة بسبب حجم تجمع المخزن المؤقت الصغير. لاستخدام backoff ، قم بزيادة تجمع المخزن المؤقت حتى 20 ميغابايت على الأقل.

لقد قمت بترقية linode الخاص بي إلى 2GB وأعيد تشغيل mariadb مع Sudo mysql. تم تشغيل mysql_secure_admin التالي ، ولكن لم يتم تعيين كلمة مرور الجذر لمستخدم ususl unitl بتغيير مستخدم الجذر لاستخدام المكون mysql_native_password. لست متأكدًا ، لكن يبدو أن الجورب قد تم إنشاؤه ، ولكن تم إيقاف تشغيل الخادم بسبب نقص الذاكرة في VPS الخاص بي.