MySQL को ठीक से कैसे मारें?


28

मेरे पास सीपीएनएल के साथ सेंटोस 64 बिट स्थापित है और मैं उपयोग करता हूं:

service mysql stop

यह केवल समय-समय पर टिक करता है और ऐसा कभी नहीं लगता है कि यह बंद हो गया है। लॉग में यह बहुत सारे पोस्ट करता है:

130303 17:42:38 [Warning] /usr/sbin/mysqld: Forcing close of thread

में err.logफ़ाइल, मैं इनमें से बहुत से देखें:

[Warning] /usr/sbin/mysqld: Forcing close of thread

यह तात्कालिक हुआ करता था। किसी भी विचार क्यों यह करता है और कैसे ठीक करने के लिए?

अभी मुझे करना है killall -9 mysqlलेकिन क्या कोई बेहतर तरीका है?

सर्वर भी बहुत सक्रिय है।

क्या यह एक कॉन्फ़िगरेशन समस्या है? क्या मेरे पास मेमरी सेटिंग्स बहुत अधिक हैं?

[mysqld]
default-storage-engine=MyISAM
local-infile=0
symbolic-links=0
skip-networking
max_connections = 500
max_user_connections = 20
key_buffer = 512M
myisam_sort_buffer_size = 64M
join_buffer_size = 64M
read_buffer_size = 12M
sort_buffer_size = 12M
read_rnd_buffer_size = 12M
table_cache = 2048
thread_cache_size = 16K
wait_timeout = 30
connect_timeout = 15
tmp_table_size = 64M
max_heap_table_size = 64M
max_allowed_packet = 64M
max_connect_errors = 10
query_cache_limit = 1M
query_cache_size = 64M
query_cache_type = 1
low_priority_updates=1
concurrent_insert=ALWAYS
log-error=/var/log/mysql/error.log
tmpdir=/home/mysqltmp
myisam_repair_threads=4
[mysqld_safe]
open_files_limit = 8192
log-error=/var/log/mysql/error.log

[mysqldump]
quick
max_allowed_packet = 512M

[myisamchk]
key_buffer = 64M
sort_buffer = 64M
read_buffer = 16M
write_buffer = 16M

जवाबों:


37

यह करने के लिए बस चलाने के लिए mysql बंद करने के लिए सबसे चालाक तरीका है

mysqladmin -uroot -p -h127.0.0.1 --protocol=tcp shutdown

यहाँ क्यों है:

Mysql सेवा फ़ाइल ( /etc/init.d/mysql) सॉकेट फ़ाइल की उपस्थिति पर निर्भर करती है। ऐतिहासिक रूप से बोलना, MySQL 4.0 पर वापस जाना, सॉकेट फ़ाइल कभी-कभी बेवजह गायब हो जाती है। यह service mysql stopकाम करने के एक मानक को बाधित करता है ।

यह कहना पर्याप्त नहीं है

mysqladmin -uroot -p -h127.0.0.1 shutdown

क्योंकि mysqld से रूट किया जाएगा के रूप में एक उपयोगकर्ता में आने root@127.0.0.1के लिए root@localhostअगर टीसीपी / आईपी स्पष्ट रूप से सक्षम नहीं है। डिफ़ॉल्ट रूप से, mysqld प्रतिरोध के कम से कम पथ चुनें और कनेक्ट करेगा root@127.0.0.1करने के लिए root@localhostसॉकेट फ़ाइल के माध्यम से। फिर भी, अगर कोई सॉकेट फ़ाइल नहीं है, तो root@localhostकभी कनेक्ट नहीं होगा।

यहां तक ​​कि mysqladmin पर MySQL प्रलेखन यह कहता है:

यदि आप एक यूनिक्स सॉकेट फ़ाइल का उपयोग कर एक स्थानीय सर्वर से कनेक्ट करते समय mysqladmin शटडाउन को निष्पादित करते हैं, तो mysqladmin सर्वर की प्रक्रिया आईडी फ़ाइल को हटाने तक इंतजार करता है, यह सुनिश्चित करने के लिए कि सर्वर ठीक से बंद हो गया है।

यही कारण है कि टीसीपी / आईपी को सक्षम करना अत्यावश्यक है:

mysqladmin -uroot -p -h127.0.0.1 --protocol=tcp shutdown

Sept 30, 2011 को वापस, मैं के अपने खुद के संस्करण की पटकथा लिखी mysqld_multiबुलाया mysqlservice(मेरी पोस्ट देखें: एक ही मेजबान पर कई उदाहरण चल रहा है )। यह विभिन्न बंदरगाहों से mysqld को जोड़ने के लिए एक आभासी इंजन के रूप में कार्य करता है। आपको बस my.cnfस्वनिर्धारित मापदंडों के साथ खुद को लाना होगा । उस स्क्रिप्ट में, मैं इस तरह से शटडाउन जारी करता हूं:

stop() {
  ${ECHO} -n $"Stopping ${PROGNAME}"
  ${MYSQLD_STOP}
  ATTEMPTS=0
  STOPPING_MYSQLD=1
  MINUTES_TO_TRY=10
  (( TICKS_TO_TRY = MINUTES_TO_TRY*240 ))
  while [ ${STOPPING_MYSQLD} -eq 1 ]
  do
    ${ECHO} -n "."
    ${SLEEP} 0.25
    MYSQLD_HAS_BEEN_SHUTDOWN=`${TAIL} ${MYSQL_ERROR_LOG} | ${GREP} -c "Shutdown complete$"`
    (( ATTEMPTS++ ))
    if [ ${ATTEMPTS} -eq ${TICKS_TO_TRY}   ] ; then STOPPING_MYSQLD=0 ; fi
    if [ ${MYSQLD_HAS_BEEN_SHUTDOWN} -eq 1 ] ; then STOPPING_MYSQLD=2 ; fi
  done
  ${ECHO}
  if [ ${STOPPING_MYSQLD} -eq 2 ]
  then
    ${ECHO} "Stopped ${PROGNAME}"
  else
    ${TAIL} -30 ${MYSQL_ERROR_LOG}
  fi
}

लेकिन क्या है ${MYSQLD_STOP}?

MYSQL_CONN="-uroot -p<rootpassword> -P${MYSQLD_PORT} -h127.0.0.1 --protocol=tcp"
MYSQLD_STOP="${MYSQLADMIN} ${MYSQL_CONN} shutdown"

कृपया ध्यान दें कि मैं उपयोग करता हूं 127.0.0.1और एक स्पष्ट बंदरगाह। इस तरह, मैं सॉकेट फ़ाइल पर निर्भर नहीं हूं।

मैंने हमेशा अपने mysqladmin --protocol=tcp shtudownहैंक्स के शटडाउन के उचित विकल्प के रूप में उपयोग किया है यदि service mysql stopहैंग हो जाता है। पर कर रहा kill -9है mysqldऔर mysqld_safeअंतिम रिसॉर्ट्स के अंतिम में होना चाहिए। (हां, मैंने पिछली बार तीन बार कहा था)।

कई बार, mysqld ने mysql.sock को बिना किसी चेतावनी के हटा दिया है। अन्य लोगों ने इस मुद्दे को पिछले कुछ वर्षों में देखा है:

उपसंहार

रहस्य सिर्फ इतना है जैसा मैंने कहा: टीसीएस / आईपी ( --protocol=tcp) और मुद्दे के माध्यम से mysqladmin का उपयोग करके mysql से कनेक्ट करें shutdown। यह काम करने के लिए नहीं है, क्योंकि बंद विशेषाधिकार में है mysql.userप्रमाणीकृत शटडाउन के अनन्य प्रयोजन के लिए। यह मेरे कार्यदिवस को कुछ समय बचाता है जब मैं लिनक्स सर्वर पर mysqld को बंद करते समय अपनी विंडोज मशीन से रिमोट शटडाउन जारी करने में सक्षम था।

अद्यतन 2013-03-06 22:48 ईएसटी

यदि आप इस बात से चिंतित हैं कि शटडाउन के दौरान क्या हो रहा है, तो शटडाउन समय में हेरफेर करने का एक तरीका है और जिस तरह से डेटा को डिस्क में फ्लश किया जाता है, खासकर यदि आपके पास बफ़र पूल में बहुत सारे इनोबीडी डेटा हैं

शुक्रिया # 1

यदि आपके पास बहुत सारे गंदे पृष्ठ हैं, तो आप innodb_max_dirty_pages_pct से 0 कर सकते हैं।

SET GLOBAL innodb_max_dirty_pages_pct = 0;

इसे बंद करने से 15-30 मिनट पहले सेट करें। यह mysqld को डिस्क पर लिखने के लिए गंदे पृष्ठों की कम से कम संभव राशि देगा।

सुगम # २

डिफ़ॉल्ट रूप से, innodb_fast_shutdown 1. इस विकल्प के लिए तीन मान हैं

  • 0: InnoDB एक धीमा शटडाउन, एक पूर्ण पर्ज और एक इन्सर्ट बफ़र शट डाउन करने से पहले करता है।
  • 1: InnoDB शटडाउन में इन परिचालनों को छोड़ देता है, एक प्रक्रिया जिसे तीव्र शटडाउन के रूप में जाना जाता है।
  • 2: InnoDB अपने लॉग को फ्लश करता है और ठंड को कम कर देता है, जैसे कि MySQL दुर्घटनाग्रस्त हो गया था; कोई प्रतिबद्ध लेन-देन खो नहीं जाता है, लेकिन क्रैश रिकवरी ऑपरेशन अगले स्टार्टअप को अधिक समय लेता है।

प्रलेखन आगे यह कहता है:

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

आपातकालीन या समस्या निवारण स्थितियों में innodb_fast_shutdown = 2 का उपयोग करें, यदि डेटा पर भ्रष्टाचार का खतरा है, तो सबसे तेज़ बंद करें।

ज्यादातर मामलों में innodb_max_dirty_pages_pct और innodb_fast_shutdown के लिए चूक ठीक होनी चाहिए।


2
सॉकेट फ़ाइल रेड हैट डेरिवेटिव्स पर गायब हो जाती है क्योंकि tmpwatchइसे हटा दिया जाता है, साथ ही इसमें बाकी सब कुछ /tmpएक कॉन्फ़िगर किया गया है जो इसके कॉन्फ़िगर थ्रेशोल्ड से अधिक पुराना है।
माइकल - sqlbot

धन्यवाद, @ माइकल- sqlbot मैं किसी से सुनने की जरूरत है, अंत में। मुझे लगता है कि यही वजह है कि MySQL AB (प्री-ओरेकल, प्री-सन) में किसी ने mysql.userइस तरह के सिरदर्द से बचने के लिए SHUTDOWN विशेषाधिकार जोड़ने का फैसला किया ।
RolandoMySQLDBA

डेबियन या उबंटू उपयोग पर mysqladmin --defaults-file=/etc/mysql/debian.cnf shutdown... उस फ़ाइल में रूट-जैसे MySQL खाते के लिए क्रेडेंशियल्स होते हैं।
0xC0000022L

हमेशा की तरह, @RolandoMySQLDBA आप स्टैक एक्सचेंज साइटों पर सर्वश्रेष्ठ डीबीए संसाधनों में से एक हैं। यहाँ महान काम जिसने मुझे 6+ साल बाद मदद की।
जेकगॉल्ड

5

ऐसा लगता है जैसे आपका प्रश्न "कैसे" MySQL को बंद करने के बारे में कम है और इस बारे में अधिक है कि आपका धीरे-धीरे क्यों बंद हो रहा है।

में एक ऐसी ही सवाल का मेरा उत्तर है, मैं एक चिकनी पुनः आरंभ, जो गतिविधि की मात्रा आप अनुरोध के बाद कि MySQL शुरू होना होता है कि कम करके मदद के लिए कुछ सुझाव की पेशकश बंद प्रक्रिया

यदि आप SHOW FULL PROCESSLIST;उस आइटम # 1 के लगातार उपयोगकर्ता नहीं हैं , क्योंकि आपको अपने सर्वर में क्या चल रहा है, इस बात का आभास होना चाहिए कि शटडाउन इतना धीमा हो रहा है। यदि लंबे समय तक चलने वाले प्रश्न हैं, जो बाधित करने के लिए सुरक्षित हैं, तो आप उन्हें मार सकते हैं KILL <thread-id>

अन्य सुझावों को फिर से लिखना:

ग्लोबल वैरिएबल innodb_fast_shutdown = 1(डिफ़ॉल्ट) को सेट करने से InnoDB के शटडाउन के हिस्से में तेजी आएगी। यह केवल सुरक्षित है, हालांकि, यदि आप अपग्रेड करने के लिए असंबंधित कारणों से सर्वर को बंद कर रहे हैं। यदि आप अपग्रेड के लिए बंद कर रहे हैं, तो इसे 0 पर सेट किया जाना चाहिए।

FLUSH TABLES;सुंदर रूप से उपयोग करने से सभी खुले टेबल बंद हो जाते हैं। यदि बाद के प्रश्नों द्वारा संदर्भित किया जाता है, तो उन्हें फिर से खोल दिया जाएगा, लेकिन इस क्रिया को अंततः उस समय को कम करना चाहिए, जब आप शटडाउन का अनुरोध करने के समय को समाप्त कर देते हैं और जिस समय शटडाउन पूरा हो जाता है, क्योंकि यह कुछ प्रारंभिक हाउसकीपिंग करता है और इससे भी महत्वपूर्ण बात यह है कि यह चरण निर्धारित करता है अंतिम चरण के लिए ...

FLUSH TABLES WITH READ LOCK;सभी खुली हुई तालिकाओं को बंद कर देता है और आपके वर्तमान क्लाइंट कनेक्शन के स्वामित्व वाले एक विशेष लॉक को प्राप्त करता है जो किसी अन्य कनेक्शन को पूरे सर्वर पर किसी भी टेबल पर लिखने से रोकता है। mysql>जब तक आप इस लॉक के मालिक नहीं होंगे, तब तक आपको अपना प्रॉम्प्ट वापस नहीं मिलेगा , जिस बिंदु पर आप शटडाउन अनुरोध जारी कर सकते हैं - लेकिन इस सत्र से डिस्कनेक्ट न करें।

व्यस्त सर्वर पर, इन चरणों को सर्वर पर गतिविधि के स्तर को कम करना चाहिए, चीजों को अधिक शांत करना चाहिए, और शटडाउन या पुनरारंभ को अधिक सुचारू रूप से बनाने में मदद करनी चाहिए।


2

यह संभावित है कि MySQL को पूरी तरह से बंद नहीं किया गया है, लेकिन बंद करने के दौरान सफाई गतिविधियां (रोलबैक आदि) कर रहा है। यदि आप इसे बंद करते समय वह सब नहीं करने देते हैं, तो अक्सर शुरू होने पर आपको इंतजार करना होगा।

यहाँ देखने के लिए कुछ है: एक टर्मिनल विंडो में शटडाउन mysql जबकि दूसरी टर्मिनल विंडो में एरर लॉग (टेल-एफ [yourerror.log]) देखते हुए। त्रुटि लॉग आपको दिखाएगा कि MySQL क्या कर रहा है।


1

मुझे आपके अनुभव के बारे में सुनने के लिए खेद है और आशा है कि इस तरह से मूर्खतापूर्ण MySQL परिदृश्यों के साथ मेरा अनुभव, आपकी मदद कर सकता है।

सर्वर से MySQL सेवा को मारने का तरीका जानने के बजाय, कुछ मामलों में, आपको यह निर्धारित करने के लिए कि क्या कोई सेवा दुरुपयोग है ( धारणा एक पर आधारित है) CentOS / RHEL पर्यावरण ):

 /usr/bin/iostat
 /usr/bin/uptime
 top -c

सिस्टम के भीतर औसत सिस्टम लोड और शीर्ष-खपत संसाधनों की पहचान करने के लिए निम्नलिखित का उपयोग करें।

mytopसिस्टम द्वारा संसाधित किए जा रहे SQL कथनों पर एक समग्र दृश्य प्राप्त करने के लिए आपको इंस्टॉल करना होगा ।

स्थापित करने के लिए mytop, बस निम्नलिखित कार्य करें:

 cd /root
 wget http://jeremy.zawodny.com/mysql/mytop/mytop-1.6.tar.gz
 tar -zxvf /root/mytop-1.6.tar.gz
 cd /root/mytop-1.6
 perl Makefile.pl
 make
 make install
 chmod 644 /usr/local/bin/mytop
 vi /usr/local/bin/mytop 

(किसी भी पाठ संपादक का उपयोग करें जिसे आप पसंद करते हैं)

के लिए खोजें "long|!" => \$config{long_nums},

इसे टिप्पणी के रूप में #"long|!" => \$config{long_nums},

chmod 555 /usr/local/bin/mytop

और आप mytop के साथ जाने के लिए अच्छे हैं । MySQL के बयानों के माध्यम से जाँच करने के लिए इसका उपयोग करें जो आपकी MySQL सेवा को रोक रहे हैं और उन्हें रोकते हैं।

उपरोक्त निर्देशों का निष्पादन आपको निम्नलिखित क्षमता प्रदान करेगा:

  • आपके सर्वर की स्थिति / स्वास्थ्य का निदान
  • अड़चन के कारण का निदान

एक बार जब आप अड़चन का कारण समाप्त कर लेते हैं, तो आपके पास एक आसान दिन होना चाहिए जब आप MySQL सेवा को पुनरारंभ करने का प्रयास करते हैं। मुझे आशा है कि आपको उपरोक्त जानकारी उपयोगी होगी।

नोट: mytop प्राचीन और अचिन्त्य है। आप शायद innotopएक आधुनिक प्रणाली पर उपयोग करना चाहिए ।


0

MySQL के init-script सिग्नल के मानक कार्यान्वयन SIGTERM के साथ MySQL का संकेत देता है और MySQL के लिए निश्चित समय तक बंद होने का इंतजार करता है।

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

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

दुर्भाग्य से आपके प्रश्न में पर्याप्त जानकारी नहीं है जिससे मुझे आपकी समस्या का उचित समाधान सुझाया जा सके। मुझे उम्मीद है कि इस मुद्दे को समझने में मदद मिलेगी।

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.