MySQL प्रतिकृति - गुलाम लगातार मास्टर से पिछड़ रहा है

Question

मैं एक मास्टर-दास प्रतिकृति सेटअप के साथ MySQL-5.1.50 का उपयोग कर रहा हूं।

अधिकांश समय गुलाम मालिक से पीछे रहता है।

जब मैं दौड़ता हूं show processlist;, तो कोई क्वेरी नहीं होती है जो कि लंबा समय ले रही है। मैंने भी सक्षम slow_logकिया। हालाँकि, इसमें कोई धीमी गति से चलने वाली क्वेरी नहीं मिलती है।

दास लगातार अलर्ट दे रहा है कि प्रतिकृति मास्टर के पीछे सेकंड है। कभी-कभी, अंतराल समय बढ़ जाता है।

मैं समस्या के कारण का निदान कैसे करूं?

मुझे तत्काल मदद की ज़रूरत है, क्योंकि यह समस्या पिछले 20 दिनों से बनी हुई है।

Comments

का डुप्लीकेट stackoverflow.com/questions/8547827/...

— Koustuv चटर्जी

Answer 1

Seconds_Behind_Master वास्तव में समय यात्रा के माध्यम से अतीत को देखने जैसा है।

इस पर इस तरीके से विचार करें:

• सूर्य पृथ्वी से 93,000,000 मील दूर है
• प्रकाश की गति 186,000 मील / सेकंड है
• सरल विभाजन से पता चलता है कि सूर्य के प्रकाश को पृथ्वी तक पहुंचने में लगभग 500 सेकंड (8 मिनट 20 सेकंड) लगते हैं
• जब आप सूर्य को देखते हैं, तो आप वास्तव में सूर्य को नहीं देखते हैं। आप देखें कि यह 8 मिनट 20 सेकंड पहले कहां था।

इस तरह से, ऐसा लगता है कि मास्टर एक ही समय में बहुत सारे प्रश्नों का प्रसंस्करण कर रहा है।

आप गुलाम को देखते हैं, भागते हैं SHOW SLAVE STATUS\Gऔर यह 200 के लिए कहता है Seconds_Behind_Master। उस संख्या की गणना कैसे की जाती है? स्लेव्स क्लॉक टाइम (UNIX_TIMESTAMP (Now)) - TIMESTAMP ऑफ़ द क्वेरी जब इसे पूरा किया गया और मास्टर के बाइनरी लॉग में रिकॉर्ड किया गया।

इसके अलावा देखने के लिए एक और मीट्रिक है Seconds_Behind_Master। उस मीट्रिक को कहा जाता है Relay_Log_Space। यह दास पर सभी रिले फ़ाइलों के लिए सभी बाइट्स का योग दर्शाता है। डिफ़ॉल्ट रूप से, सबसे बड़ा एकल रिले लॉग 1GB तक सीमित है। यदि Relay_Log_Space1GB से कम है, तो यह इंगित करता है कि समानांतर में मास्टर पर निष्पादित कई लंबी चलने वाली क्वेरी। दुर्भाग्य से, एकल-थ्रेडेड प्रकृति प्रतिकृति के SQL थ्रेड के कारण, क्वेरी को एक के पीछे एक निष्पादित किया जाता है।

उदाहरण के लिए, मान लें कि आपके पास मास्टर पर निम्न परिदृश्य है:

• धीमी क्वेरी लॉग सक्षम है
• मास्टर पर समानांतर में निष्पादित 20 प्रश्न
• प्रत्येक क्वेरी में 3 सेकंड लगे
• प्रत्येक क्वेरी मास्टर बाइनरी लॉग में उसी टाइमस्टैम्प के साथ दर्ज की जाती है

जब दास अपने रिले लॉग से उन प्रश्नों को पढ़ता है और उन्हें एक-एक करके संसाधित करता है

• गुलाम की घड़ी चलती होगी
• 20 प्रश्नों में से प्रत्येक के लिए TIMESTAMP समान होगा
• अंतर 3 सेकंड बढ़ जाएगा क्वेरी पूरी हो गई है
• यह 60 सेकंड के लिए परिणाम है Seconds_Behind_Master

धीमी लॉग के संबंध में, long_query_time के लिए डिफ़ॉल्ट 10 सेकंड है। यदि रिले लॉग में आपके सभी प्रश्न 10 सेकंड से कम हैं, तो आप स्लो क्वेरी लॉग में कभी भी कुछ भी नहीं पकड़ेंगे।

मेरे पास मास्टर और स्लेव सर्वर दोनों के लिए निम्नलिखित सिफारिशें हैं

• सिफारिश # 1 : MySQL 5.5 में अपग्रेड करें । MySQL 5.5 और Percona Server 5.1.38+ के तहत, आप कई CPU तक पहुंचने के लिए InnoDB को ट्यून कर सकते हैं। मैंने इस बारे में पिछले पोस्ट लिखे हैं
  • Apr 26, 2012: CPU प्रदर्शन डेटाबेस सर्वर के लिए प्रासंगिक है?
  • Sep 20, 2011: मल्टी कोर और MySQL प्रदर्शन
  • Sep 12, 2011: MySQL को एक से अधिक कोर का उपयोग करना संभव है?
  • May 26, 2011: एकल थ्रेडेड बनाम मल्टीथ्रेडेड डेटाबेस प्रदर्शन के बारे में
• सिफारिश # 2 : सभी तालिकाओं के लिए InnoDB का उपयोग करें । InnoDB RAM में डेटा और इंडेक्स को कैश करता है, MyISAM केवल इंडेक्स को कैश करता है।
• सिफारिश # 3 : रैम बढ़ाएँ । आपको स्लेव और मास्टर समान पर अधिक डेटा और अनुक्रमित कैश करना होगा
• सिफारिश # 4 : सभी प्रश्नों को ट्यून करें। सैकड़ों बार चलने वाले प्रश्नों से मिलीसेकंड को कम करने के लिए एक लंबा रास्ता तय करना पड़ता है Seconds_Behind_Master।

अन्य ट्रॉवेल्सोटिंग

यदि आप प्रतिकृति अंतराल के कारण होने वाले प्रश्नों को देखना चाहते हैं, तो निम्न कार्य करें:

• SHOW SLAVE STATUS\G
• रिले लॉग का नाम प्राप्त करें Relay_Log_File
• STOP SLAVE;
• START SLAVE;
• ओएस में, cd /var/lib/mysqlया जहां भी रिले लॉग लिखे जाते हैं
• टेक्स्ट फ़ाइल में रिले लॉग को डंप करें

उदाहरण के लिए, आइए करते हैं SHOW SLAVE STATUS\G

               Slave_IO_State: Waiting for master to send event
                  Master_Host: 10.64.51.149
                  Master_User: replicant
                  Master_Port: 3306
                Connect_Retry: 60
              Master_Log_File: mysql-bin.000009
          Read_Master_Log_Pos: 1024035856
               Relay_Log_File: relay-bin.000030
                Relay_Log_Pos: 794732078
        Relay_Master_Log_File: mysql-bin.000009
             Slave_IO_Running: Yes
            Slave_SQL_Running: Yes
              Replicate_Do_DB:
          Replicate_Ignore_DB: search_cache
           Replicate_Do_Table:
       Replicate_Ignore_Table:
      Replicate_Wild_Do_Table:
  Replicate_Wild_Ignore_Table:
                   Last_Errno: 0
                   Last_Error:
                 Skip_Counter: 0
          Exec_Master_Log_Pos: 1024035856
              Relay_Log_Space: 794732271
              Until_Condition: None
               Until_Log_File:
                Until_Log_Pos: 0
           Master_SSL_Allowed: No
           Master_SSL_CA_File:
           Master_SSL_CA_Path:
              Master_SSL_Cert:
            Master_SSL_Cipher:
               Master_SSL_Key:
        Seconds_Behind_Master: 0
Master_SSL_Verify_Server_Cert: No
                Last_IO_Errno: 0
                Last_IO_Error:
               Last_SQL_Errno: 0
               Last_SQL_Error:
  Replicate_Ignore_Server_Ids:
             Master_Server_Id: 106451149

अगर मैं दौड़ता हूं STOP SLAVE; START SLAVE;, तो रिले लॉग बंद हो जाता है और एक नया खुल जाता है। फिर भी, आप चाहते हैं relay-bin.000030।

सामग्री को निम्नानुसार डंप करें:

cd /var/lib/mysql
mysqlbinlog relay-bin.000030 > /root/RelayLogQueries.txt
less /root/RelayLogQueries.txt

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

Comments

V5.7 के रूप में, MySQL ने बहु-थ्रेडेड फैशन में दासों में परिवर्तन लागू करने में सक्षम किया है। संबंधित दस्तावेज यहां देखे

— edigu

Answer 2

आप किस बाइनरी लॉग प्रारूप का उपयोग कर रहे हैं? क्या आप ROW या STATEMENT का उपयोग कर रहे हैं?
" SHOW GLOBAL VARIABLES LIKE 'binlog_format';"

यदि आप ROW का उपयोग बिनलॉग प्रारूप के रूप में कर रहे हैं, तो सुनिश्चित करें कि आपकी सभी तालिकाओं में प्राथमिक या विशिष्ट कुंजी है:
SELECT t.table_schema,t.table_name,engine FROM information_schema.tables t INNER JOIN information_schema .columns c on t.table_schema=c.table_schema and t.table_name=c.table_name and t.table_schema not in ('performance_schema','information_schema','mysql') GROUP BY t.table_schema,t.table_name HAVING sum(if(column_key in ('PRI','UNI'), 1,0)) =0;

यदि आप पीके या अद्वितीय कुंजी के बिना मेज पर 1 मिलियन रिकॉर्ड को हटाने के लिए उदाहरण के लिए एक डिलीट स्टेटमेंट को निष्पादित करते हैं, तो केवल एक पूर्ण टेबल स्कैन मास्टर की तरफ से होगा, जो दास पर मामला नहीं है।
जब ROW binlog_format का उपयोग किया जा रहा है, तो MySQL बाइनरी लॉग्स में बदलावों को लिखता है (स्टेटमेंट बिनलॉगफॉर्मफॉर्म की तरह स्टेटमेंट के रूप में नहीं) और उस बदलाव को स्लेव की ओर पंक्ति द्वारा पंक्ति में लागू किया जाएगा, जिसका अर्थ है कि 1 मिलियन फुल टेबल स्कैन होगा। स्वामी पर केवल एक ही डिलीट स्टेटमेंट को प्रतिबिंबित करने के लिए और यह गुलाम की समस्या का कारण बन रहा है।

Answer 3

SHOW SLAVE STATUS में सेकंड_बेहिंद_मास्टर का मान मास्टर के सिस्टम समय के बीच का अंतर है, जो उस समय जमा हो जाता है जब घटना को मूल रूप से निष्पादित किया गया था और बाइनरी लॉग में दर्ज किया गया था ... और सिस्टम समय गुलाम पर जब घटना वहां हो जाती है।

यदि दो सिस्टम की घड़ियां सिंक में नहीं हैं, तो मास्टर के पीछे सेकंड गलत मान देंगे।

Comments

MySQL 5.5 और पूर्व में, प्रतिकृति घटनाओं का निष्पादन दास पक्ष पर एकल-थ्रेडेड है। "सिस्टम उपयोगकर्ता" के रूप में चल रहे "SHOW FULL PROCESSLIST" में दो धागे होने चाहिए - एक मास्टर से घटनाओं को प्राप्त कर रहा है, दूसरा प्रश्नों को निष्पादित कर रहा है। यदि दास पिछड़ रहा है, तो उस धागे को दिखाना चाहिए कि वर्तमान में किस क्वेरी को निष्पादित किया जा रहा है। उस पर एक नज़र डालें, और संसाधन भुखमरी के लिए अपनी डिस्क / मेमोरी / सीपीयू आँकड़े भी देखें।

— माइकल - sqlbot 14