यदि आपके पास एक MySQL आउटेज है तो कदम उठाने के लिए

एक MySQL आउटेज का सीधा सा मतलब है कि आपकी MySQL सेवा दूसरे के दृष्टिकोण से पहुंच योग्य या अनुत्तरदायी नहीं है। आउटेज संभावित कारणों के एक समूह से उत्पन्न हो सकते हैं..

• नेटवर्क समस्या - कनेक्टिविटी समस्या, स्विच, रूटिंग, रिज़ॉल्वर, लोड-बैलेंसर टियर।
• संसाधन की समस्या - चाहे आप संसाधनों की सीमा तक पहुंच गए हों या अड़चन।
• गलत विन्यास - गलत अनुमति या स्वामित्व, अज्ञात चर, गलत पासवर्ड, विशेषाधिकार बदल गया।
• लॉकिंग - ग्लोबल या टेबल लॉक दूसरों को डेटा एक्सेस करने से रोकता है।

इस ब्लॉग पोस्ट में, यदि आप MySQL (Linux वातावरण) में खराबी से जूझ रहे हैं, तो हम कुछ कदम उठाएंगे।

एक कदम:त्रुटि कोड प्राप्त करें

जब आपके पास कोई आउटेज होता है, तो आपका आवेदन कुछ त्रुटियों और अपवादों को बाहर कर देगा। ये त्रुटियां आमतौर पर एक त्रुटि कोड के साथ आती हैं, जो आपको समस्या का निवारण करने और आउटेज को पुनर्प्राप्त करने के लिए आपको क्या सामना करना पड़ रहा है और आगे क्या करना है, इस पर एक मोटा विचार देगा।

त्रुटि पर अधिक विवरण प्राप्त करने के लिए, त्रुटि का अर्थ जानने के लिए क्रमशः MySQL त्रुटि कोड या मारियाडीबी त्रुटि कोड पृष्ठों की जांच करें।

दूसरा चरण:क्या MySQL सर्वर चल रहा है?

टर्मिनल के माध्यम से सर्वर में लॉग इन करें और देखें कि क्या MySQL डेमॉन चल रहा है और सही पोर्ट को सुन रहा है। Linux में, कोई निम्न कार्य करेगा:

सबसे पहले, MySQL प्रक्रिया की जांच करें:

$ ps -ef | grep -i mysql

आपको बदले में कुछ मिलना चाहिए। अन्यथा, MySQL नहीं चल रहा है। यदि MySQL नहीं चल रहा है, तो इसे प्रारंभ करने का प्रयास करें:

$ systemctl start mysql # systemd

$ service mysql start # sysvinit/upstart

$ mysqld_safe # manual

यदि आप उपरोक्त चरण में कोई त्रुटि देख रहे हैं, तो आपको MySQL त्रुटि लॉग को देखना चाहिए, जो ऑपरेटिंग सिस्टम और MySQL कॉन्फ़िगरेशन फ़ाइल में log_error के लिए MySQL चर कॉन्फ़िगरेशन के आधार पर भिन्न होता है। RedHat-आधारित सर्वर के लिए, फ़ाइल सामान्यतः यहाँ स्थित होती है:

$ cat /var/log/mysqld.log

लॉग स्तर "[त्रुटि]" वाली नवीनतम पंक्तियों पर ध्यान दें। "[चेतावनी]" के साथ लेबल की गई कुछ पंक्तियाँ कुछ समस्याओं का संकेत दे सकती हैं, लेकिन वे बहुत ही असामान्य हैं। अधिकांश समय, गलत कॉन्फ़िगरेशन और संसाधन समस्याओं का पता यहां से लगाया जा सकता है।

यदि MySQL चल रहा है, तो जांचें कि क्या यह सही पोर्ट को सुन रहा है:

$ netstat -tulpn | grep -i mysql

tcp6       0 0 :::3306                 :::* LISTEN   1089/mysqld

आपको पोर्ट 3306 पर PID 1089 के साथ सभी इंटरफेस (:::3306 या 0.0.0.0:3306) पर सुनने की प्रक्रिया का नाम "mysqld" मिलेगा और स्थिति "LISTEN" है। यदि आप देखते हैं कि उपरोक्त पंक्ति 127.0.0.1:3306 दिखाती है, तो MySQL केवल स्थानीय रूप से सुन रहा है। सभी IP पतों को सुनने के लिए, या बस लाइन पर टिप्पणी करने के लिए आपको MySQL कॉन्फ़िगरेशन फ़ाइल में bind_address मान बदलने की आवश्यकता हो सकती है।

तीसरा चरण:कनेक्टिविटी समस्याओं की जांच करें

यदि MySQL सर्वर MySQL त्रुटि लॉग के अंदर त्रुटि के बिना ठीक चल रहा है, तो संभावना है कि कनेक्टिविटी समस्याएँ हो रही हैं, बहुत अधिक है। पिंग (यदि ICMP सक्षम है) के माध्यम से होस्ट से कनेक्टिविटी की जाँच करके प्रारंभ करें और एप्लिकेशन सर्वर से MySQL सर्वर से टेलनेट:

(application-server)$ ping db1.mydomain.com

(application-server)$ telnet db1.mydomain.com 3306

Trying db1.mydomain.com...

Connected to 192.168.0.16.

Escape character is '^]'.

O

5.6.46-86.2sN&nz9NZ�32?&>H,EV`_;mysql_native_password

यदि आप MySQL पोर्ट से जुड़ सकते हैं तो आपको टेलनेट आउटपुट में कुछ लाइनें दिखनी चाहिए। अब, एप्लिकेशन सर्वर से MySQL क्लाइंट का उपयोग करके एक बार फिर प्रयास करें:

(application-server)$ mysql -u db_user -p -h db1.mydomain.com -P3306

ERROR 1045 (28000): Access denied for user 'db_user'@'db1.mydomain.com' (using password: YES)

उपरोक्त उदाहरण में, त्रुटि हमें इस बारे में थोड़ी जानकारी देती है कि आगे क्या करना है। उपरोक्त शायद इसलिए कि किसी ने "db_user" के लिए पासवर्ड बदल दिया है या इस उपयोगकर्ता के पासवर्ड की समय सीमा समाप्त हो गई है। यह MySQL 5.7 से एक सामान्य व्यवहार है। 4 और इसके बाद के संस्करण, जहां स्वचालित पासवर्ड समाप्ति नीति डिफ़ॉल्ट रूप से 360 दिनों की सीमा के साथ सक्षम है - जिसका अर्थ है कि सभी पासवर्ड वर्ष में एक बार समाप्त हो जाएंगे।

चरण चार:MySQL प्रक्रिया सूची की जाँच करें

यदि MySQL कनेक्टिविटी समस्याओं के बिना ठीक चल रहा है, तो यह देखने के लिए कि वर्तमान में कौन सी प्रक्रियाएं चल रही हैं, MySQL प्रक्रिया सूची देखें:

mysql> SHOW FULL PROCESSLIST;

+-----+------+-----------+------+---------+------+-------+-----------------------+-----------+---------------+

| Id  | User | Host      | db | Command | Time | State | Info                  | Rows_sent | Rows_examined |

+-----+------+-----------+------+---------+------+-------+-----------------------+-----------+---------------+

| 117 | root | localhost | NULL | Query   | 0 | init | SHOW FULL PROCESSLIST |       0 | 0 |

+-----+------+-----------+------+---------+------+-------+-----------------------+-----------+---------------+

1 row in set (0.01 sec)

जानकारी और समय कॉलम पर ध्यान दें। कुछ MySQL ऑपरेशन डेटाबेस को स्टाल करने और अनुत्तरदायी बनने के लिए पर्याप्त विनाशकारी हो सकते हैं। निम्नलिखित SQL कथन, यदि चल रहे हैं, डेटाबेस या तालिका तक पहुँचने के लिए दूसरों को अवरुद्ध कर सकते हैं (जो कि एप्लिकेशन के दृष्टिकोण से MySQL सेवा का एक संक्षिप्त आउटेज ला सकता है):

• रीड लॉक के साथ फ्लश टेबल
• लॉक टेबल ...
• टेबल बदलें ...

कुछ लंबे समय तक चलने वाले लेन-देन दूसरों को भी रोक सकते हैं, जो अंततः उसी संसाधनों तक पहुंचने की प्रतीक्षा कर रहे अन्य लेनदेन के लिए समयबाह्य का कारण बन सकते हैं। आप या तो आक्रामक लेन-देन को समाप्त कर सकते हैं ताकि दूसरों को समान पंक्तियों तक पहुँचने की अनुमति मिल सके या लंबे लेन-देन के समाप्त होने के बाद कतार में लेन-देन का पुन:प्रयास किया जा सके।

निष्कर्ष

MySQL आउटेज के जोखिम को कम करने के लिए सक्रिय निगरानी वास्तव में महत्वपूर्ण है। यदि आपका डेटाबेस ClusterControl द्वारा प्रबंधित किया जाता है, तो सभी उल्लिखित पहलुओं की निगरानी उपयोगकर्ता से बिना किसी अतिरिक्त कॉन्फ़िगरेशन के स्वचालित रूप से की जा रही है। आपको अपने इनबॉक्स में लंबे समय तक चलने वाली क्वेरी, सर्वर गलत कॉन्फ़िगरेशन, सीमा से अधिक संसाधन और बहुत कुछ जैसे विसंगतियों का पता लगाने के लिए अलार्म प्राप्त होंगे। साथ ही, होस्ट या नेटवर्क के साथ कुछ गलत होने पर ClusterControl स्वचालित रूप से आपकी डेटाबेस सेवा को पुनर्प्राप्त करने का प्रयास करेगा।

आप हमारे श्वेतपत्र को पढ़कर MySQL और MariaDB डिजास्टर रिकवरी के बारे में अधिक जान सकते हैं।