मैसकल दुर्घटनाग्रस्त हो गया और शुरू नहीं होगा

हमारा उत्पादन mysql सर्वर बस दुर्घटनाग्रस्त हो गया और वापस नहीं आएगा। यह एक segfault त्रुटि दे रहा है। मैं एक रिबूट की कोशिश की, और अभी पता नहीं है कि और क्या करने की कोशिश की। यहाँ स्टैकट्रेस है:

140502 14:13:05 [नोट] प्लगइन 'फेडर्ड' अक्षम है।
InnoDB: लॉग स्कैन चौकी lsn 108 1057948207 से आगे बढ़ गया
140502 14:13:06 InnoDB: डेटाबेस को सामान्य रूप से बंद नहीं किया गया था!
InnoDB: क्रैश रिकवरी शुरू करना।
InnoDB: .ibd फ़ाइलों से टेबलस्पेस जानकारी पढ़ना ...
InnoDB: डबल-राइट से संभावित आधे-लिखित डेटा पेजों को पुनर्स्थापित करना
InnoDB: बफर ...
InnoDB: वसूली करना: लॉग इन क्रम संख्या 108 1058059648
InnoDB: 1 लेनदेन (ओं) को वापस रोल किया जाना चाहिए या साफ किया जाना चाहिए
InnoDB: पूर्ववत करने के लिए कुल 15 पंक्ति संचालन में
InnoDB: Trx आईडी काउंटर 0 562485504 है
140502 14:13:06 InnoDB: डेटाबेस में लॉग रिकॉर्ड के एक लागू बैच शुरू ...
InnoDB: पर्केंट्स में प्रगति: 4 5 6 7 8 9 10 11 12 13 14 15 15 17 17 18 19 20 21 22 23 24 25 26 28 28 30 30 31 32 32 34 35 35 37 37 39 40 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 
InnoDB: पूरा बैच लागू करें
InnoDB: पृष्ठभूमि में शुरू करने से बिना लेनदेन के रोलबैक शुरू होता है
140502 14:13:06 InnoDB: आईडी 0 562485192, पूर्ववत करने के लिए 15 पंक्तियों के साथ वापस trx रोलिंग
140502 14:13:06 InnoDB: शुरू किया; लॉग क्रम संख्या 108 1058059648
140502 14:13:06 InnoDB: फ़ाइल में थ्रेड 1873206128 में जोरदार विफलता ../../../storage/innobase/fsp/fsp0fsp.c लाइन 1593
InnoDB: असफल मुखरता: frag_n_used> 0
InnoDB: हम जानबूझकर मेमोरी ट्रैप उत्पन्न करते हैं।
InnoDB: http://bugs.mysql.com पर एक विस्तृत बग रिपोर्ट सबमिट करें।
InnoDB: यदि आपको बार-बार जोर से विफलताएं या दुर्घटनाएँ होती हैं, तो भी
InnoDB: mysqld स्टार्टअप के तुरंत बाद, वहाँ हो सकता है
InnoDB: InnoDB टेबलस्पेस में भ्रष्टाचार। कृपया देखें
InnoDB: http://dev.mysql.com/doc/refman/5.1/en/forcing-recovery.html
InnoDB: जबरन वसूली के बारे में।
140502 14:13:06 - mysqld को सिग्नल 6 मिला;
यह हुआ क्योंकि आपने कीट को मारा है। यह भी संभव है कि यह बाइनरी
या पुस्तकालयों में से एक इसके खिलाफ जुड़ा हुआ था, भ्रष्ट है, अनुचित तरीके से बनाया गया है,
या ग़लतफ़हमी। यह त्रुटि भी खराब हार्डवेयर की वजह से हो सकता है।
हम पूरी कोशिश करेंगे कि कुछ ऐसी जानकारी सामने आए जिससे निदान की उम्मीद की जा सके
समस्या, लेकिन जब से हम पहले ही दुर्घटनाग्रस्त हो चुके हैं, कुछ निश्चित रूप से गलत है
और यह विफल हो सकता है।

key_buffer_size = 16777216
read_buffer_size = 131,072
max_used_connections = 0
max_threads = 151
threads_connected = 0
यह संभव है कि mysqld तक का उपयोग कर सके 
key_buffer_size + (read_buffer_size + Sort_buffer_size) * max_threads = 345919 K
स्मृति के बाइट्स
आशा है कि यह ठीक है; यदि नहीं, तो समीकरण में कुछ चर घटाएं।

thd: 0x0
पीछे चलने का प्रयास। यह जानने के लिए आप निम्न जानकारी का उपयोग कर सकते हैं
जहां मेरीस्केल की मृत्यु हो गई। यदि आप इसके बाद कोई संदेश नहीं देखते हैं, तो कुछ चला गया
बहुत गलत ...
stack_bottom = (nil) thread_stack 0x30000
140502 14:13:06 [नोट] इवेंट शेड्यूलर: लोड की गई 0 ईवेंट
140502 14:13:06 [नोट] / usr / sbin / mysqld: कनेक्शन के लिए तैयार।
संस्करण: '5.1.41-3ubuntu12.10' सॉकेट: '/var/run/mysqld/mysqld.sock' पोर्ट: 3306 (उबंटू)
/ usr / sbin / mysqld (my_print_stacktrace + 0x2d) [0xb7579cbd]
/ usr / sbin / mysqld (हैंडल_सेगफ़ॉल्ट + 0x494) [0xb7245854]
[0xb6fc0400]
/lib/tls/i686/cmov/libc.so.6(abort+0x182) [0xb6cc5a82]
/ usr / sbin / mysqld (+ 0x4867e9) [0xb74647e9]
/ usr / sbin / mysqld (btr_page_free_low + 0x122) [0xb74f1622]
/ usr / sbin / mysqld (btr_compress + 0x684) [0xb74fn4ca4]
/ usr / sbin / mysqld (btr_cur_compress_if_useful + 0xe7) [0xb74284e7]
/ usr / sbin / mysqld (btr_cur_pessimistic_delete + 0x332) [0xb7429e72]
/ usr / sbin / mysqld (btr_node_ptr_delete + 0x82) [0xb74f4012]
/ usr / sbin / mysqld (btr_discard_page + 0x175) [0xb74f41e5]
/ usr / sbin / mysqld (btr_cur_pessimistic_delete + 0x3e8) [0xb7429f28]
/ usr / sbin / mysqld (+ 0x526197) [0xb7504197]
/ usr / sbin / mysqld (row_undo_ins + 0x1b1) [0xbb47478]
/ usr / sbin / mysqld (row_undo_step + 0x25f) [0xb74x210f]
/ usr / sbin / mysqld (que_run_threads + 0x58a) [0xb74a31da]
/ usr / sbin / mysqld (trx_rollback_or_clean_all_without_sess + 0x3e3) [0xb74ded43]
/lib/tls/i686/cmov/libpthread.so.0(+0x596e) [0xb6f9f96e]
/lib/tls/i686/cmov/libc.so.6(clone+0x5e) [0xb6d65a4e]
Http://dev.mysql.com/doc/mysql/en/crashing.html पर मैनुअल पेज शामिल है
जानकारी जो आपको यह पता लगाने में मदद करे कि दुर्घटना का कारण क्या है।

कोई सिफारिशें?

mysql innodb crash

— tilleryj
स्रोत

पहली चीजें पहले; किसी ने MySQL कॉन्फ़िगरेशन को किसी तरह बदल दिया है? इसके लिए नवीनतम संशोधन तिथि देखें /etc/mysql/my.cnf।

— जने पिक्कारेनैन

नं। एक मासूमल्ड करने के लिए innodb_force_recovery = 3 सेट करने के बाद, तब गिरा और DB को पढ़ा। इसने इसे ठीक कर दिया।

— tilleryj

जवाबों:

आउच।

InnoDB: immediately after the mysqld startup, there may be
InnoDB: corruption in the InnoDB tablespace. Please refer to
InnoDB: http://dev.mysql.com/doc/refman/5.1/en/forcing-recovery.html
InnoDB: about forcing recovery.

सुझाए गए वेबपृष्ठ की जाँच करें: http://dev.mysql.com/doc/refman/5.1/en/forcing-recovery.html ।

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

अपना संपादित करें /etc/my.cnfऔर जोड़ें:

 innodb_force_recovery = 1

... यह देखने के लिए कि क्या आप अपने डेटाबेस में जा सकते हैं और अपना डेटा प्राप्त कर सकते हैं / दूषित तालिका ढूंढ सकते हैं।

आमतौर पर, जब ऐसा होता है तो यह फिर से निर्मित होता है (कम से कम एक दूषित तालिका या दो)।

से http://chepri.com/mysql-innodb-corruption-and-recovery/ :

बंद करो mysqld( service mysql stop)।
बैकअप /var/lib/mysql/ib*
निम्नलिखित पंक्ति को इसमें जोड़ें /etc/my.cnf:
```
innodb_force_recovery = 1
```
(वे 4 का सुझाव देते हैं, लेकिन 1 से शुरू करने के लिए सबसे अच्छा है और अगर यह शुरू नहीं होगा तो वृद्धि)
पुनः आरंभ mysqld( service mysql start)।
सभी तालिकाएं डंप करें: mysqldump -A > dump.sql
उन सभी डेटाबेस को छोड़ें जिनकी वसूली की आवश्यकता है।
बंद करो mysqld( service mysql stop)।
हटाना /var/lib/mysql/ib*
बाहर टिप्पणी innodb_force_recoveryमें/etc/my.cnf
पुनः आरंभ करें mysqld। Mysql त्रुटि लॉग देखें। डिफ़ॉल्ट रूप से यह देखना चाहिए /var/lib/mysql/server/hostname.com.errकि यह नई ib*फाइलें कैसे बनाता है।
डेटाबेस को डंप से पुनर्स्थापित करें: mysql < dump.sql

— जोनाथन
स्रोत

मैं सबसे पहले इस बात पर विचार करूंगा कि आपके पास फाइल सिस्टम भ्रष्टाचार या एक खराब डिस्क हो सकता है।

— बॉम्बे

सभी innodb_force_recovery मानों को 6 तक आज़माएँ और innodb_purge_threads = 0 जोड़ दें - कभी-कभी मुख्य सूत्र कोई भी प्रारंभ नहीं कर सकता, आप इसे त्रुटि लॉग में देखेंगे

— akuzminsky

मुझे पता है कि यह एक पुराना धागा है, लेकिन यह निर्धारित करने पर कोई भी विस्तार कि किस डेटाबेस को पुनर्प्राप्ति की आवश्यकता है?

— nkanderson

@nicolekanderson मैं उस बिंदु पर कुछ स्पष्टीकरण भी चाहूंगा। जब मैं mysqldump चलाता हूं, तो यह मुझे किसी भी तरह से इंगित नहीं करता है कि डेटाबेस में से कोई भी भ्रष्ट था।

— एंड्रयू थैडियस मार्टिन

उत्तर में बिंदु 10 - डेटाबेस सर्वर को पुनरारंभ करने और त्रुटि लॉग को पढ़ने की कोशिश करें, इसे दुर्घटनाग्रस्त तालिकाओं का नाम देना चाहिए। mysqldump आपको केवल तालिकाओं की एक प्रति देता है, कुछ भी नहीं।

— जोनाथन

मैं mysql: 5.7 docker छवि का उपयोग करते समय इसी त्रुटि का सामना कर रहा था। मुख्य गलती रूट उपयोगकर्ता बनाने की कोशिश कर रही थी जो डिफ़ॉल्ट रूप से मौजूद है। अधिक जानकारी: https://github.com/docker-library/mysql/issues/129

जैसा कि ऊपर दिए गए लिंक में दिया गया है, समाधान डॉक इमेज को शुरू करते समय पर्यावरण चर में MYSQL_USER और MYSQL_PASSWORD सेट नहीं करना था।

— rahuljain1311
स्रोत

मैकलेरा सिएरा 10.12.4 (16E1919) पर चलने वाले कर्नेल आतंक के बाद लारवेल होमस्टेड (वैग्रेंट) में मेरे साथ ऐसा हुआ:

$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 14.04.3 LTS
Release:    14.04
Codename:   trusty

$ mysql -V
mysql  Ver 14.14 Distrib 5.7.9, for Linux (x86_64) using  EditLine 
wrapper

यहां कुछ संसाधन दिए गए हैं, जिन्हें आप आजमा सकते हैं, हालांकि मरम्मत के किसी भी विकल्प ने मेरे लिए काम नहीं किया है :

https://dev.mysql.com/doc/refman/5.7/en/forcing-innodb-recovery.html

https://forums.mysql.com/read.php?22,603093,604631#msg-604631

https://support.plesk.com/hc/en-us/articles/213939865-How-to-fix-InnoDB-corruption-cases-for-the-MySQL-database

मैंने mysql config में बल पुनर्प्राप्ति को जोड़ने का प्रयास किया (1 पर शुरू किया और उत्तरोत्तर उच्चतर माना जाता है क्योंकि उच्च संख्या स्थायी रूप से स्थायी भ्रष्टाचार का कारण बन सकती है):

sudo nano /etc/mysql/my.cnf

[mysqld]
innodb_force_recovery = 1
#innodb-read-only=1
#innodb_purge_threads=0
#key_buffer_size=16M
#event-scheduler=disabled

किसी अन्य विंडो में, चलाएँ:

tail -f /var/log/mysql/error.log

फिर सक्षम किए गए विभिन्न विकल्पों के साथ mysqld को पुनरारंभ करने का प्रयास करें:

sudo /etc/init.d/mysql restart

यदि यह समय समाप्त हो जाता है, तो आप mysql प्रक्रियाओं को फिर से शुरू करने के लिए मजबूर कर सकते हैं:

# process id is first column with number, just ignore lines with grep because they list the process running 'grep mysql'
ps aux | grep mysql
sudo kill -9 <process-id>
sudo /etc/init.d/mysql restart

अगर यह काम करता है, तो लॉग कुछ इस तरह दिखाई देगा:

Version: '5.7.9' socket: '/var/run/mysqld/mysqld.sock' port: 3306 MySQL Community Server (GPL)

यदि यह विफल रहता है, तो लॉग कुछ इस तरह दिखाई देगा:

InnoDB: Assertion failure in thread 140049488692992 in file log0recv.cc line 1420

जब बदतर से बदतर हो गया, तो मैंने डेटाबेस को भ्रष्ट होने की संभावना को हटाने की कोशिश की:

sudo ls -alt /var/lib/mysql

यह पता चला कि मैं जिस डेटाबेस पर काम कर रहा था, वह सूची के शीर्ष पर सबसे हाल ही में संशोधित किया गया था। सौभाग्य से मेरे पास उस दिन से इसके लिए एक एसक्यूएल डंप था इसलिए इसे हटाने में सक्षम था:

sudo rm -rf /var/lib/mysql/<database_name>

मैंने अन्य सभी फ़ाइलों को छोड़ दिया, और mysql वैसे भी शुरू करने में सक्षम था।

अद्यतन करें: innodb_force_recovery = 1जब mysql फिर से काम कर रहा है, तो उसे अक्षम करना सुनिश्चित करें, अन्यथा जब आप डेटाबेस और तालिकाओं को संशोधित करने का प्रयास करेंगे तो आपको त्रुटियां मिलेंगी।

फिर मैंने सीक्वल प्रो के साथ डेटाबेस को फिर से बनाया, अपने डेटा को फिर से जोड़ा और अपने अन्य प्रोजेक्ट्स से सभी डेटाबेस को फेंकने के बिना आगे बढ़ने में सक्षम था।

आगे बढ़ते हुए, मुझे यह मान लेना चाहिए कि कोई भी mysql डेटाबेस दूषित हो सकता है और दैनिक बैकअप रखने की कोशिश कर सकता है और डेटाबेस रिक्रिएशन स्क्रिप्ट को प्रलेखित या मेरे निरंतर एकीकरण टूल में कोडित कर सकता है।

— ज़ैक मॉरिस
स्रोत