एक मास्टर/स्लेव प्रतिकृति क्लस्टर सेटअप अधिकांश संगठनों में एक सामान्य उपयोग का मामला है। MySQL प्रतिकृति का उपयोग आपके डेटा को विभिन्न वातावरणों में दोहराने में सक्षम बनाता है और गारंटी देता है कि जानकारी कॉपी हो जाती है। यह एसिंक्रोनस और सिंगल-थ्रेडेड (डिफ़ॉल्ट रूप से) है, लेकिन प्रतिकृति आपको इसे सिंक्रोनस (या वास्तव में "सेमी-सिंक्रोनस") के लिए कॉन्फ़िगर करने की अनुमति देती है और स्लेव थ्रेड को कई थ्रेड्स या समानांतर में चला सकती है।
यह विचार बहुत सामान्य है और आमतौर पर एक साधारण सेटअप के साथ आता है, जिससे इसका दास इसकी पुनर्प्राप्ति या बैकअप समाधान के रूप में कार्य करता है। हालांकि, यह हमेशा एक कीमत पर आता है, खासकर जब खराब प्रश्नों (जैसे प्राथमिक या अद्वितीय कुंजी की कमी) को दोहराया जाता है या हार्डवेयर (जैसे नेटवर्क या डिस्क आईओ मुद्दों) के साथ कुछ परेशानी होती है। जब ये समस्याएँ होती हैं, तो सबसे आम समस्या का सामना करना पड़ता है प्रतिकृति लैग।
एक प्रतिकृति अंतराल लेन-देन (ओं) या संचालन (ओं) के लिए देरी की लागत है, जिसकी गणना स्टैंडबाय / स्लेव नोड के खिलाफ प्राथमिक / मास्टर के बीच निष्पादन के समय के अंतर से की जाती है। MySQL में सबसे निश्चित मामले खराब प्रश्नों पर निर्भर करते हैं जैसे प्राथमिक कुंजी या खराब इंडेक्स की कमी, खराब नेटवर्क हार्डवेयर या खराब नेटवर्क कार्ड, विभिन्न क्षेत्रों या क्षेत्रों के बीच एक दूर का स्थान, या कुछ प्रक्रियाएं जैसे भौतिक बैकअप चलने का कारण हो सकता है वर्तमान प्रतिकृति लेनदेन को लागू करने में देरी करने के लिए आपका MySQL डेटाबेस। इन मुद्दों का निदान करते समय यह एक बहुत ही सामान्य मामला है। इस ब्लॉग में, हम देखेंगे कि इन मामलों से कैसे निपटा जाए और यदि आप MySQL प्रतिकृति लैग का अनुभव कर रहे हैं तो क्या देखें।
"शो दास स्थिति":MySQL DBA का मंत्र
कुछ मामलों में, प्रतिकृति अंतराल से निपटने के दौरान यह चांदी की गोली है और यह आपके MySQL डेटाबेस में किसी समस्या के कारण का अधिकतर खुलासा करती है। बस इस SQL कथन को अपने दास नोड में चलाएं जो कि प्रतिकृति अंतराल का अनुभव कर रहा है।
समस्याओं का पता लगाने के लिए सामान्य प्रारंभिक क्षेत्र हैं,
- Slave_IO_State - यह आपको बताता है कि धागा क्या कर रहा है। यह फ़ील्ड आपको अच्छी अंतर्दृष्टि प्रदान करेगी यदि प्रतिकृति स्वास्थ्य सामान्य रूप से चल रहा है, नेटवर्क समस्याओं का सामना करना पड़ रहा है जैसे कि मास्टर से फिर से जुड़ना, या डेटा को प्रतिबद्ध करने में बहुत अधिक समय लेना जो डिस्क की समस्याओं को डिस्क से सिंक करते समय डिस्क समस्याओं का संकेत दे सकता है। SHOW PROCESSLIST चलाते समय आप यह स्थिति मान भी निर्धारित कर सकते हैं।
- Master_Log_File - मास्टर की बिनलॉग फ़ाइल का नाम जहां वर्तमान में I/O थ्रेड लाया जा रहा है।
- Read_Master_Log_Pos - मास्टर से बिनलॉग फ़ाइल की स्थिति जहां प्रतिकृति I/O थ्रेड पहले ही पढ़ चुका है।
- Relay_Log_File - रिले लॉग फ़ाइल नाम जिसके लिए SQL थ्रेड वर्तमान में ईवेंट निष्पादित कर रहा है
- Relay_Log_Pos - Relay_Log_File में निर्दिष्ट फ़ाइल से बिनलॉग स्थिति जिसके लिए SQL थ्रेड पहले ही निष्पादित हो चुका है।
- Relay_Master_Log_File - मास्टर की बिनलॉग फ़ाइल जिसे SQL थ्रेड पहले ही निष्पादित कर चुका है और Read_Master_Log_Pos मान के अनुरूप है।
- सेकेंड्स_बिहाइंड_मास्टर - यह फ़ील्ड वर्तमान में स्लेव पर संसाधित होने वाले ईवेंट के लिए मास्टर पर टाइमस्टैम्प के विरुद्ध स्लेव पर वर्तमान टाइमस्टैम्प के बीच अंतर के लिए एक सन्निकटन दिखाती है। हालाँकि, यदि नेटवर्क धीमा है तो यह फ़ील्ड आपको सटीक अंतराल बताने में सक्षम नहीं हो सकता है क्योंकि सेकंड में अंतर स्लेव SQL थ्रेड और स्लेव I/O थ्रेड के बीच लिया जाता है। तो ऐसे मामले हो सकते हैं कि इसे धीमी गति से पढ़ने वाले दास I/O थ्रेड के साथ पकड़ा जा सकता है, लेकिन मुझे लगता है कि यह पहले से ही अलग है।
- Slave_SQL_Running_State - SQL थ्रेड की स्थिति और मान SHOW PROCESSLIST में प्रदर्शित स्थिति मान के समान है।
- पुनर्प्राप्त_Gtid_Set - GTID प्रतिकृति का उपयोग करते समय उपलब्ध। यह इस दास द्वारा प्राप्त सभी लेन-देन के अनुरूप GTID का सेट है।
- निष्पादित_Gtid_Set - GTID प्रतिकृति का उपयोग करते समय उपलब्ध। यह बाइनरी लॉग में लिखे गए GTID का सेट है।
उदाहरण के लिए, आइए नीचे का उदाहरण लेते हैं जो GTID प्रतिकृति का उपयोग करता है और एक प्रतिकृति अंतराल का अनुभव कर रहा है:
mysql> show slave status\G
*************************** 1. row ***************************
Slave_IO_State: Waiting for master to send event
Master_Host: 192.168.10.70
Master_User: cmon_replication
Master_Port: 3306
Connect_Retry: 10
Master_Log_File: binlog.000038
Read_Master_Log_Pos: 826608419
Relay_Log_File: relay-bin.000004
Relay_Log_Pos: 468413927
Relay_Master_Log_File: binlog.000038
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
Replicate_Do_DB:
Replicate_Ignore_DB:
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: 826608206
Relay_Log_Space: 826607743
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: 251
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: 45003
Master_UUID: 36272880-a7b0-11e9-9ca6-525400cae48b
Master_Info_File: mysql.slave_master_info
SQL_Delay: 0
SQL_Remaining_Delay: NULL
Slave_SQL_Running_State: copy to tmp table
Master_Retry_Count: 86400
Master_Bind:
Last_IO_Error_Timestamp:
Last_SQL_Error_Timestamp:
Master_SSL_Crl:
Master_SSL_Crlpath:
Retrieved_Gtid_Set: 36272880-a7b0-11e9-9ca6-525400cae48b:7631-9192
Executed_Gtid_Set: 36272880-a7b0-11e9-9ca6-525400cae48b:1-9191,
864dd532-a7af-11e9-85f2-525400cae48b:1-173,
df68c807-a7af-11e9-9b56-525400cae48b:1-4
Auto_Position: 1
Replicate_Rewrite_DB:
Channel_Name:
Master_TLS_Version:
1 row in set (0.00 sec)इस तरह के मुद्दों का निदान करते हुए, mysqlbinlog यह पहचानने के लिए भी आपका टूल हो सकता है कि किसी विशिष्ट बिनलॉग x और y स्थिति पर कौन सी क्वेरी चल रही है। इसे निर्धारित करने के लिए, आइए Retrieved_Gtid_Set, Relay_Log_Pos, और Relay_Log_File को लें। नीचे दिए गए आदेश को देखें:
[[email protected] mysql]# mysqlbinlog --base64-output=DECODE-ROWS --include-gtids="36272880-a7b0-11e9-9ca6-525400cae48b:9192" --start-position=468413927 -vvv relay-bin.000004
/*!50530 SET @@SESSION.PSEUDO_SLAVE_MODE=1*/;
/*!50003 SET @[email protected]@COMPLETION_TYPE,COMPLETION_TYPE=0*/;
DELIMITER /*!*/;
# at 468413927
#200206 4:36:14 server id 45003 end_log_pos 826608271 CRC32 0xc702eb4c GTID last_committed=1562 sequence_number=1563 rbr_only=no
SET @@SESSION.GTID_NEXT= '36272880-a7b0-11e9-9ca6-525400cae48b:9192'/*!*/;
# at 468413992
#200206 4:36:14 server id 45003 end_log_pos 826608419 CRC32 0xe041ec2c Query thread_id=24 exec_time=31 error_code=0
use `jbmrcd_date`/*!*/;
SET TIMESTAMP=1580963774/*!*/;
SET @@session.pseudo_thread_id=24/*!*/;
SET @@session.foreign_key_checks=1, @@session.sql_auto_is_null=0, @@session.unique_checks=1, @@session.autocommit=1/*!*/;
SET @@session.sql_mode=1436549152/*!*/;
SET @@session.auto_increment_increment=1, @@session.auto_increment_offset=1/*!*/;
/*!\C utf8 *//*!*/;
SET @@session.character_set_client=33,@@session.collation_connection=33,@@session.collation_server=8/*!*/;
SET @@session.lc_time_names=0/*!*/;
SET @@session.collation_database=DEFAULT/*!*/;
ALTER TABLE NewAddressCode ADD INDEX PostalCode(PostalCode)
/*!*/;
SET @@SESSION.GTID_NEXT= 'AUTOMATIC' /* added by mysqlbinlog */ /*!*/;
DELIMITER ;
# End of log file
/*!50003 SET [email protected]_COMPLETION_TYPE*/;
/*!50530 SET @@SESSION.PSEUDO_SLAVE_MODE=0*/;यह हमें बताता है कि यह एक DML कथन को दोहराने और निष्पादित करने का प्रयास कर रहा था जो अंतराल का स्रोत बनने का प्रयास करता है। यह तालिका 13M पंक्तियों वाली एक विशाल तालिका है।
शो प्रक्रिया सूची की जांच करें, ps, top, iostat कमांड संयोजन के साथ इंजन INNODB स्थिति दिखाएं
कुछ मामलों में, हमें अपराधी बताने के लिए गुलाम स्थिति दिखाएं पर्याप्त नहीं है। यह संभव है कि दोहराए गए कथन MySQL डेटाबेस दास में चल रही आंतरिक प्रक्रियाओं से प्रभावित हों। SHOW [FULL] PROCESSLIST और SHOW ENGINE INNODB STATUS स्टेटमेंट्स को चलाने से सूचनात्मक डेटा भी मिलता है जो आपको समस्या के स्रोत के बारे में जानकारी देता है।
उदाहरण के लिए, मान लें कि एक बेंचमार्किंग टूल चल रहा है जिससे डिस्क IO और CPU को संतृप्त किया जा सकता है। आप दोनों SQL कथन चलाकर जाँच कर सकते हैं। इसे ps और शीर्ष कमांड के साथ मिलाएं।
आप iostat चलाकर अपने डिस्क भंडारण के साथ बाधाओं को भी निर्धारित कर सकते हैं जो वर्तमान मात्रा के आंकड़े प्रदान करता है जिसका आप निदान करने का प्रयास कर रहे हैं। iostat चलाना दिखा सकता है कि आपका सर्वर कितना व्यस्त या भरा हुआ है। उदाहरण के लिए, एक दास द्वारा लिया गया जो पिछड़ रहा है लेकिन एक ही समय में उच्च आईओ उपयोग का अनुभव कर रहा है,
[[email protected] ~]# iostat -d -x 10 10
Linux 3.10.0-693.5.2.el7.x86_64 (testnode5) 02/06/2020 _x86_64_ (2 CPU)
Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
sda 0.00 0.42 3.71 60.65 218.92 568.39 24.47 0.15 2.31 13.79 1.61 0.12 0.76
dm-0 0.00 0.00 3.70 60.48 218.73 568.33 24.53 0.15 2.36 13.85 1.66 0.12 0.76
dm-1 0.00 0.00 0.00 0.00 0.04 0.01 21.92 0.00 63.29 2.37 96.59 22.64 0.01
Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
sda 0.00 0.20 392.30 7983.60 2135.60 49801.55 12.40 36.70 3.84 13.01 3.39 0.08 69.02
dm-0 0.00 0.00 392.30 7950.20 2135.60 50655.15 12.66 36.93 3.87 13.05 3.42 0.08 69.34
dm-1 0.00 0.00 0.00 0.30 0.00 1.20 8.00 0.06 183.67 0.00 183.67 61.67 1.85
Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
sda 0.00 1.40 370.93 6775.42 2557.04 46184.22 13.64 43.43 6.12 11.60 5.82 0.10 73.25
dm-0 0.00 0.00 370.93 6738.76 2557.04 47029.62 13.95 43.77 6.20 11.64 5.90 0.10 73.41
dm-1 0.00 0.00 0.00 0.30 0.00 1.20 8.00 0.03 107.00 0.00 107.00 35.67 1.07
Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
sda 0.00 0.00 299.80 7253.35 1916.88 52766.38 14.48 30.44 4.59 15.62 4.14 0.10 72.09
dm-0 0.00 0.00 299.80 7198.60 1916.88 51064.24 14.13 30.68 4.66 15.70 4.20 0.10 72.57
dm-1 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
sda 0.00 0.10 215.50 8939.60 1027.60 67497.10 14.97 59.65 6.52 27.98 6.00 0.08 72.50
dm-0 0.00 0.00 215.50 8889.20 1027.60 67495.90 15.05 60.07 6.60 28.09 6.08 0.08 72.75
dm-1 0.00 0.00 0.00 0.30 0.00 1.20 8.00 0.01 32.33 0.00 32.33 30.33 0.91
Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
sda 0.00 0.90 140.40 8922.10 625.20 54709.80 12.21 11.29 1.25 9.88 1.11 0.08 68.60
dm-0 0.00 0.00 140.40 8871.50 625.20 54708.60 12.28 11.39 1.26 9.92 1.13 0.08 68.83
dm-1 0.00 0.00 0.00 0.30 0.00 1.20 8.00 0.01 27.33 0.00 27.33 9.33 0.28
Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
sda 0.00 1.70 284.50 8621.30 24228.40 51535.75 17.01 34.14 3.27 8.19 3.11 0.08 72.78
dm-0 0.00 0.00 290.90 8587.10 25047.60 53434.95 17.68 34.28 3.29 8.02 3.13 0.08 73.47
dm-1 0.00 0.00 0.00 2.00 0.00 8.00 8.00 0.83 416.45 0.00 416.45 63.60 12.72
Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
sda 0.00 0.30 851.60 11018.80 17723.60 85165.90 17.34 142.59 12.44 7.61 12.81 0.08 99.75
dm-0 0.00 0.00 845.20 10938.90 16904.40 83258.70 17.00 143.44 12.61 7.67 12.99 0.08 99.75
dm-1 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
sda 0.00 1.10 24.60 12965.40 420.80 51114.45 7.93 39.44 3.04 0.33 3.04 0.07 93.39
dm-0 0.00 0.00 24.60 12890.20 420.80 51114.45 7.98 40.23 3.12 0.33 3.12 0.07 93.35
dm-1 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
sda 0.00 0.00 3.60 13420.70 57.60 51942.00 7.75 0.95 0.07 0.33 0.07 0.07 92.11
dm-0 0.00 0.00 3.60 13341.10 57.60 51942.00 7.79 0.95 0.07 0.33 0.07 0.07 92.08
dm-1 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00उपरोक्त परिणाम उच्च IO उपयोग और एक उच्च लेखन प्रदर्शित करता है। इससे यह भी पता चलता है कि औसत कतार आकार और औसत अनुरोध आकार बढ़ रहा है जिसका अर्थ है कि यह एक उच्च कार्यभार का संकेत है। इन मामलों में, आपको यह निर्धारित करने की आवश्यकता है कि क्या ऐसी बाहरी प्रक्रियाएं हैं जो MySQL को प्रतिकृति थ्रेड्स को चोक करने का कारण बनती हैं।
ClusterControl कैसे मदद कर सकता है?
ClusterControl के साथ, स्लेव लैग से निपटना और अपराधी का निर्धारण करना बहुत आसान और कुशल है। यह आपको सीधे वेब UI में बताता है, नीचे देखें:
यह आपको वर्तमान स्लेव लैग के बारे में बताता है जो आपके स्लेव नोड्स अनुभव कर रहे हैं। इतना ही नहीं, SCUMM डैशबोर्ड के साथ, यदि सक्षम किया गया है, तो आपको अपने दास नोड या यहां तक कि पूरे क्लस्टर के स्वास्थ्य के बारे में अधिक जानकारी प्रदान करता है:
न केवल ये चीजें ClusterControl में उपलब्ध हैं, यह आपको यह भी प्रदान करती हैं इन सुविधाओं के साथ खराब प्रश्नों से बचने की क्षमता, जैसा कि नीचे देखा गया है,
अनावश्यक अनुक्रमणिका आपको यह निर्धारित करने की अनुमति देती है कि ये अनुक्रमणिका निम्न के लिए प्रदर्शन समस्याओं का कारण बन सकती हैं आने वाली क्वेरी जो डुप्लिकेट इंडेक्स का संदर्भ देती हैं। यह आपको उन तालिकाओं के बारे में भी बताता है जिनमें कोई प्राथमिक कुंजी नहीं होती है जो आमतौर पर दास अंतराल की एक सामान्य समस्या होती है जब एक निश्चित SQL क्वेरी या लेनदेन जो प्राथमिक या अद्वितीय कुंजी के बिना बड़ी तालिकाओं को संदर्भित करता है जब इसे दासों को दोहराया जाता है।
निष्कर्ष
मास्टर-स्लेव प्रतिकृति सेटअप में MySQL प्रतिकृति अंतराल से निपटना एक आम समस्या है। इसका निदान करना आसान हो सकता है, लेकिन इसे हल करना मुश्किल है। सुनिश्चित करें कि आपके पास प्राथमिक कुंजी या अद्वितीय कुंजी के साथ आपकी तालिकाएं मौजूद हैं, और स्लेव लैग के कारण का निवारण और निदान करने के तरीके के बारे में चरणों और उपकरणों का निर्धारण करें। हालांकि समस्याओं को हल करते समय दक्षता हमेशा महत्वपूर्ण होती है।
