मेरा MySQL डेटाबेस दूषित है... अब मैं क्या करूँ?

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

आमतौर पर जब MySQL डेटा दूषित हो जाता है, तो अनुशंसा की जाती है कि इसे अंतिम बैकअप से पुनर्स्थापित करें, DR सर्वर पर स्विच करें या प्रभावित नोड को हटा दें यदि आपके पास अन्य नोड्स से तुरंत डेटा की सेवा करने के लिए गैलेरा क्लस्टर है। कुछ मामलों में आप नहीं कर सकते - यदि बैकअप नहीं है, तो क्लस्टर कभी सेट नहीं किया गया था, आपकी प्रतिकृति बहुत लंबे समय से बंद है, या DR प्रक्रिया का कभी परीक्षण नहीं किया गया था। भले ही आपके पास बैकअप हो, फिर भी आप पुनर्प्राप्ति का प्रयास करने के लिए कुछ कार्रवाइयां करना चाहेंगे क्योंकि इसे वापस ऑनलाइन होने में कम समय लग सकता है।

MyISAM, द बैड एंड बदसूरत

MyISAM की तुलना में InnoDB अधिक दोष-सहिष्णु है। InnoDB में auto_recovery विशेषताएं हैं और यह पुराने MyISAM इंजन की तुलना में अधिक सुरक्षित है।

जब बहुत सारे लेखन होते हैं और उस टेबल पर बहुत सारे ताले होते हैं तो माईसाम टेबल आसानी से दूषित हो सकते हैं। स्टोरेज इंजन फाइल सिस्टम कैश में डेटा "लिखता है", जिसे डिस्क पर फ्लश करने से पहले कुछ समय लग सकता है। इसलिए यदि आपका सर्वर अचानक पुनरारंभ होता है, तो कैश में कुछ अज्ञात मात्रा में डेटा खो जाता है। MyISAM डेटा के दूषित होने का यह एक सामान्य तरीका है। MyISAM से InnoDB में माइग्रेट करने की सिफारिश की गई है, लेकिन ऐसे मामले हो सकते हैं जहां यह संभव नहीं है।

प्रीमियम नॉन नोसेरे, बैकअप

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

अपने सभी डेटाबेस से सभी फाइलों का बैकअप लेने के लिए, इन चरणों का पालन करें:

MySQL सर्वर बंद करें

service mysqld stop

अपने डेटादिर के लिए निम्न कमांड टाइप करें।

cp -r /var/lib/mysql /var/lib/mysql_bkp

हमारे पास डेटा निर्देशिका की बैकअप प्रतिलिपि होने के बाद, हम समस्या निवारण शुरू करने के लिए तैयार हैं।

डेटा भ्रष्टाचार पहचान

त्रुटि लॉग आपका सबसे अच्छा दोस्त है। आमतौर पर, जब डेटा भ्रष्टाचार होता है, तो आपको त्रुटि लॉग में प्रासंगिक जानकारी (दस्तावेज़ीकरण के लिंक सहित) मिलेगी। यदि आप नहीं जानते कि यह कहाँ स्थित है, तो my.cnf और वेरिएबल log_error की जाँच करें, अधिक विवरण के लिए इस लेख को देखें https://dev.mysql.com/doc/refman/8.0/en/error-log-destination-configuration। एचटीएमएल. आपको यह भी पता होना चाहिए कि आपका स्टोरेज इंजन टाइप है। आप यह जानकारी त्रुटि लॉग या info_schema में पा सकते हैं।

mysql> select table_name,engine from information_schema.tables where table_name = '<TABLE>' and table_schema = '<DATABASE>';

डेटा भ्रष्टाचार के साथ समस्याओं का निदान करने के लिए मुख्य उपकरण/आदेश चेक टेबल, मरम्मत तालिका, और myisamchk हैं। Mysqlcheck क्लाइंट तालिका रखरखाव करता है:यह जाँच करता है, मरम्मत करता है (MyISAM), MySQL के चलने के दौरान तालिकाओं का अनुकूलन या विश्लेषण करता है।

mysqlcheck -uroot -p <DATABASE>

DATABASE को डेटाबेस के नाम से बदलें, और TABLE को उस तालिका के नाम से बदलें जिसे आप जाँचना चाहते हैं:

mysqlcheck -uroot -p <DATABASE> <TABLE>

Mysqlcheck निर्दिष्ट डेटाबेस और तालिकाओं की जाँच करता है। यदि कोई तालिका चेक पास कर लेती है, तो mysqlcheck तालिका के लिए ठीक प्रदर्शित करता है।

employees.departments                              OK
employees.dept_emp                                 OK
employees.dept_manager                             OK
employees.employees                                OK
Employees.salaries
Warning  : Tablespace is missing for table 'employees/salaries'
Error    : Table 'employees.salaries' doesn't exist in engine
status   : Operation failed
employees.titles                                   OK

डेटा भ्रष्टाचार के मुद्दे अनुमति के मुद्दों से भी संबंधित हो सकते हैं। कुछ मामलों में, ओएस आर/डब्ल्यू मुद्दों के कारण माउंट पॉइंट को केवल-पढ़ने के लिए स्विच कर सकता है या यह उस उपयोगकर्ता के कारण हो सकता है जिसने गलती से डेटा फ़ाइलों का स्वामित्व बदल दिया है। ऐसे मामलों में, आपको त्रुटि लॉग में प्रासंगिक जानकारी मिलेगी।

[[email protected] employees]# ls -rtla
...
-rw-rw----. 1 mysql mysql  28311552 05-10 06:24 titles.ibd
-rw-r-----. 1 root  root  109051904 05-10 07:09 salaries.ibd
drwxr-xr-x. 7 mysql mysql      4096 05-10 07:12 ..
drwx------. 2 mysql mysql      4096 05-10 07:17 .

MySQL क्लाइंट

MariaDB [employees]> select count(*) from salaries;
ERROR 1932 (42S02): Table 'employees.salaries' doesn't exist in engine

त्रुटि लॉग प्रविष्टि

2018-05-10  9:15:38 140703666226944 [ERROR] InnoDB: Failed to find tablespace for table `employees`.`salaries` in the cache. Attempting to load the tablespace with space id 9
2018-05-10  9:15:38 140703666226944 [ERROR] InnoDB: Operating system error number 13 in a file operation.
2018-05-10  9:15:38 140703666226944 [ERROR] InnoDB: The error means mysqld does not have the access rights to the directory.
2018-05-10  9:15:38 140703666226944 [ERROR] InnoDB: Cannot open datafile for read-only: './employees/salaries.ibd' OS error: 81
2018-05-10  9:15:38 140703666226944 [ERROR] InnoDB: Operating system error number 13 in a file operation.
2018-05-10  9:15:38 140703666226944 [ERROR] InnoDB: The error means mysqld does not have the access rights to the directory.
2018-05-10  9:15:38 140703666226944 [ERROR] InnoDB: Could not find a valid tablespace file for `employees/salaries`. Please refer to http://dev.mysql.com/doc/refman/5.7/en/innodb-troubleshooting-datadict.html for how to resolve the issue.

InnoDB तालिका पुनर्प्राप्त करना

यदि आप डेटाबेस तालिका के लिए InnoDB संग्रहण इंजन का उपयोग कर रहे हैं, तो आप InnoDB पुनर्प्राप्ति प्रक्रिया चला सकते हैं।
स्वत:पुनर्प्राप्ति सक्षम करने के लिए MySQL को सक्षम करने के लिए innodb_force_recovery विकल्प की आवश्यकता है। Innodb_force_recovery, InnoDB को प्रारंभ करने के लिए बाध्य करता है, जबकि पृष्ठभूमि संचालन को चलने से रोकता है, ताकि आप अपनी तालिकाओं को डंप कर सकें।

ऐसा करने के लिए my.cnf खोलें और [mysqld] अनुभाग में निम्न पंक्ति जोड़ें:

[mysqld]
innodb_force_recovery=1
service mysql restart

आपको innodb_force_recovery=1 से my.cnf फ़ाइल में परिवर्तनों को सहेजना चाहिए, और फिर अपने ऑपरेटिंग सिस्टम के लिए उपयुक्त कमांड का उपयोग करके MySQL सर्वर को पुनरारंभ करना चाहिए। यदि आप अपनी टेबल को 3 या उससे कम के innodb_force_recovery मान के साथ डंप करने में सक्षम हैं, तो आप अपेक्षाकृत सुरक्षित हैं। कई मामलों में आपको 4 तक जाना होगा और जैसा कि आप पहले से ही जानते हैं कि यह डेटा को दूषित कर सकता है।

[mysqld]
innodb_force_recovery=1
service mysql restart

यदि उच्च मूल्य में परिवर्तन की आवश्यकता है, तो छह अधिकतम और सबसे खतरनाक है।

एक बार जब आप अपना डेटाबेस शुरू करने में सक्षम हो जाते हैं, तो सभी डेटाबेस को डेटाबेस में निर्यात करने के लिए निम्न कमांड टाइप करें। sql फ़ाइल:

mysqldump --all-databases --add-drop-database --add-drop-table > dump.sql

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

service mysqld stop

यदि आप डेटाबेस को छोड़ने में असमर्थ थे, तो इसे मैन्युअल रूप से हटाने के लिए निम्न आदेश टाइप करें।

cd /var/lib/mysql
rm -rf <DATABASE>

सुनिश्चित करें कि आप आंतरिक डेटाबेस निर्देशिकाओं को नहीं हटाते हैं।
आपके द्वारा किए जाने के बाद, InnoDB पुनर्प्राप्ति मोड को अक्षम करने के लिए [mysqld] में निम्न पंक्ति पर टिप्पणी करें।

#innodb_force_recovery=...

my.cnf फ़ाइल में परिवर्तन सहेजें, और फिर MySQL सर्वर प्रारंभ करें

service mysqld start

चरण 5 में आपके द्वारा बनाई गई बैकअप फ़ाइल से डेटाबेस को पुनर्स्थापित करने के लिए निम्न आदेश टाइप करें:

mysql> tee import_database.log
mysql> source dump.sql

MyISAM की मरम्मत

यदि mysqlcheck किसी तालिका के लिए त्रुटि की रिपोर्ट करता है, तो इसे ठीक करने के लिए -repair ध्वज के साथ mysqlcheck कमांड टाइप करें। सर्वर चालू होने और चलने के दौरान mysqlcheck मरम्मत विकल्प काम करता है।

mysqlcheck -uroot -p -r <DATABASE> <TABLE>

यदि सर्वर डाउन है और किसी भी कारण से mysqlcheck आपकी तालिका की मरम्मत नहीं कर सकता है, तो आपके पास अभी भी myisamchk का उपयोग करके फ़ाइलों पर सीधे पुनर्प्राप्ति करने का विकल्प है। Myisamchk के साथ, आपको यह सुनिश्चित करने की आवश्यकता है कि सर्वर में टेबल खुली नहीं हैं।

MySQL बंद करो

service mysqld stop
cd /var/lib/mysql

उस निर्देशिका में बदलें जहां डेटाबेस स्थित है।

cd /var/lib/mysql/employees
myisamchk <TABLE>

डेटाबेस में सभी तालिकाओं की जाँच करने के लिए, निम्न कमांड टाइप करें:

myisamchk *.MYI

यदि पिछला आदेश काम नहीं करता है, तो आप अस्थायी फ़ाइलों को हटाने का प्रयास कर सकते हैं जो myisamchk को ठीक से चलने से रोक रही हैं। ऐसा करने के लिए, डेटा डीआईआर निर्देशिका में वापस बदलें, और फिर निम्न आदेश चलाएँ:

ls */*.TMD

यदि कोई .TMD फ़ाइलें सूचीबद्ध हैं, तो उन्हें हटा दें:

rm */*.TMD

फिर myisamchk फिर से चलाएँ।

किसी तालिका को सुधारने का प्रयास करने के लिए, तालिका को उस तालिका के नाम से प्रतिस्थापित करते हुए, जिसे आप सुधारना चाहते हैं, निम्न आदेश निष्पादित करें:

myisamchk --recover <TABLE>

MySQL सर्वर को पुनरारंभ करें

service mysqld start

डेटा हानि से कैसे बचें

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

संभावित डेटा भ्रष्टाचार के प्रभाव को कम करने के लिए आपको हमेशा क्लस्टर सिस्टम पर विचार करना चाहिए। यह केवल कुछ समय की बात है जब डेटाबेस क्रैश हो जाएगा या दूषित हो जाएगा, इसलिए एक कॉपी होना अच्छा है जिसे आप स्विच कर सकते हैं। यह मास्टर/गुलाम प्रतिकृति हो सकता है। स्विचओवर की जटिलता को कम करने और पुनर्प्राप्ति समय (आरटीओ) को कम करने के लिए यहां महत्वपूर्ण पहलू सुरक्षित स्वचालित पुनर्प्राप्ति है।