स्ट्रीमिंग प्रतिकृति और मारियाडीबी 10.4 . के साथ बड़े लेनदेन को संभालना

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

हम मारियाडीबी गैलेरा क्लस्टर संस्करण 10.4.6 के तीन नोड्स का उपयोग करेंगे, जो 26.4.2 के गैलेरा संस्करण के साथ आता है।

MariaDB [(none)]> show global status like 'wsrep_provider%';
+-----------------------------+------------------------------------------------------------------------------------------------------------------------------------------------+
| Variable_name               | Value                                                                                                                                          |
+-----------------------------+------------------------------------------------------------------------------------------------------------------------------------------------+
| wsrep_provider_capabilities | :MULTI_MASTER:CERTIFICATION:PARALLEL_APPLYING:TRX_REPLAY:ISOLATION:PAUSE:CAUSAL_READS:INCREMENTAL_WRITESET:UNORDERED:PREORDERED:STREAMING:NBO: |
| wsrep_provider_name         | Galera                                                                                                                                         |
| wsrep_provider_vendor       | Codership Oy <[email protected]>                                                                                                              |
| wsrep_provider_version      | 26.4.2(r4498)                                                                                                                                  |
+-----------------------------+------------------------------------------------------------------------------------------------------------------------------------------------+
4 rows in set (0.001 sec)

स्ट्रीमिंग प्रतिकृति से निपटने के लिए तीन मुख्य दर्द बिंदु हैं:

लंबे लेन-देन
बड़े लेन-देन
टेबल में हॉट स्पॉट

आइए एक-एक करके उन पर विचार करें और देखें कि कैसे स्ट्रीमिंग प्रतिकृति हमें उनसे निपटने में मदद कर सकती है, लेकिन पहले राइटसेट प्रमाणन पर ध्यान दें - उन मुद्दों को दिखाने का मूल कारण।

गलेरा क्लस्टर में राइटसेट सर्टिफिकेशन

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

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

यहां मुख्य मुद्दा यह है कि गैलेरा प्रारंभिक नोड के अलावा अन्य नोड्स पर किसी भी लॉकिंग का परिचय नहीं देता है, जिस पर लेनदेन खोला गया था। प्रमाणन प्रक्रिया इस उम्मीद पर आधारित है कि यदि एक नोड लेनदेन को निष्पादित कर सकता है, तो अन्य भी इसे करने में सक्षम होना चाहिए। यह सच है लेकिन, जैसा कि हमने चर्चा की, ऐसे कोने के मामले हैं जिनमें ऐसा होने की संभावना काफी कम हो जाती है।

गैलेरा 4 में, स्ट्रीमिंग प्रतिकृति के साथ, व्यवहार बदल गया है और सभी नोड्स में सभी ताले लिए जा रहे हैं। लेन-देन को भागों में विभाजित किया जाएगा और प्रत्येक भाग को सभी नोड्स पर प्रमाणित किया जाएगा। सफल प्रमाणन के बाद क्लस्टर में सभी नोड्स पर पंक्तियों को लॉक कर दिया जाएगा। कुछ चर हैं जो नियंत्रित करते हैं कि यह वास्तव में कैसे किया जाता है - wsrep_trx_fragment_size और wsrep_trx_fragment_unit परिभाषित करते हैं कि टुकड़ा कितना बड़ा होना चाहिए और इसे कैसे परिभाषित किया जाना चाहिए। यह बहुत बारीक नियंत्रण है:आप खंड इकाई को बाइट्स, स्टेटमेंट या पंक्तियों के रूप में परिभाषित कर सकते हैं जो लेनदेन में संशोधित प्रत्येक पंक्ति के लिए प्रमाणीकरण चलाना संभव बनाता है। आइए देखें कि आप वास्तविक जीवन में स्ट्रीमिंग प्रतिकृति से कैसे लाभ उठा सकते हैं।

स्ट्रीमिंग प्रतिकृति के साथ काम करना

आइए निम्नलिखित परिदृश्य पर विचार करें। हमारे पास चलाने के लिए एक लेन-देन है जिसमें कम से कम 30 सेकंड लगते हैं:

BEGIN; UPDATE sbtest.sbtest1 SET k = k - 2 WHERE id < 2000 ; UPDATE sbtest.sbtest1 SET k = k + 1 WHERE id < 2000 ; UPDATE sbtest.sbtest1 SET k = k + 1 WHERE id < 2000 ; SELECT SLEEP(30); COMMIT;

फिर, जब यह चल रहा हो, हम SQL को निष्पादित करेंगे जो समान पंक्तियों को छूता है। इसे दूसरे नोड पर क्रियान्वित किया जाएगा:

BEGIN; UPDATE sbtest.sbtest1 SET k = k - 1 WHERE id < 20 ; UPDATE sbtest.sbtest1 SET k = k + 1 WHERE id < 20 ; COMMIT;

परिणाम क्या होगा?

दूसरा लेन-देन पूरा होते ही पहला लेन-देन वापस ले लिया जाता है:

MariaDB [sbtest]> BEGIN; UPDATE sbtest.sbtest1 SET k = k - 2 WHERE id < 2000 ; UPDATE sbtest.sbtest1 SET k = k + 1 WHERE id < 2000 ; UPDATE sbtest.sbtest1 SET k = k + 1 WHERE id < 2000 ; SELECT SLEEP(30); COMMIT;
Query OK, 0 rows affected (0.001 sec)

Query OK, 667 rows affected (0.020 sec)
Rows matched: 667  Changed: 667  Warnings: 0

Query OK, 667 rows affected (0.010 sec)
Rows matched: 667  Changed: 667  Warnings: 0

Query OK, 667 rows affected (0.009 sec)
Rows matched: 667  Changed: 667  Warnings: 0

ERROR 1213 (40001): Deadlock found when trying to get lock; try restarting transaction
Query OK, 0 rows affected (0.001 sec)

दूसरे नोड पर लेन-देन सफल रहा:

MariaDB [(none)]> BEGIN; UPDATE sbtest.sbtest1 SET k = k - 1 WHERE id < 20 ; UPDATE sbtest.sbtest1 SET k = k + 1 WHERE id < 20 ; COMMIT;
Query OK, 0 rows affected (0.000 sec)

Query OK, 7 rows affected (0.002 sec)
Rows matched: 7  Changed: 7  Warnings: 0

Query OK, 7 rows affected (0.001 sec)
Rows matched: 7  Changed: 7  Warnings: 0

Query OK, 0 rows affected (0.004 sec)

इससे बचने के लिए हम पहले लेन-देन के लिए स्ट्रीमिंग प्रतिकृति का उपयोग कर सकते हैं। हम गैलेरा से प्रत्येक पंक्ति परिवर्तन को प्रमाणित करने के लिए कहेंगे:

MariaDB [sbtest]> BEGIN; SET SESSION wsrep_trx_fragment_size=1 ; SET SESSION wsrep_trx_fragment_unit='rows' ; UPDATE sbtest.sbtest1 SET k = k - 2 WHERE id < 2000 ; UPDATE sbtest.sbtest1 SET k = k + 1 WHERE id < 2000 ; UPDATE sbtest.sbtest1 SET k = k + 1 WHERE id < 2000 ; SELECT SLEEP(30); COMMIT; SET SESSION wsrep_trx_fragment_size=0;
Query OK, 0 rows affected (0.001 sec)

Query OK, 0 rows affected (0.000 sec)

Query OK, 0 rows affected (0.000 sec)

Query OK, 667 rows affected (1.757 sec)
Rows matched: 667  Changed: 667  Warnings: 0

Query OK, 667 rows affected (1.708 sec)
Rows matched: 667  Changed: 667  Warnings: 0

Query OK, 667 rows affected (1.685 sec)
Rows matched: 667  Changed: 667  Warnings: 0

जैसा कि आप देख सकते हैं, इस बार इसने ठीक काम किया। दूसरे नोड पर:

MariaDB [(none)]> BEGIN; UPDATE sbtest.sbtest1 SET k = k - 1 WHERE id < 20 ; UPDATE sbtest.sbtest1 SET k = k + 1 WHERE id < 20 ; COMMIT;
Query OK, 0 rows affected (0.000 sec)

Query OK, 7 rows affected (33.942 sec)
Rows matched: 7  Changed: 7  Warnings: 0

Query OK, 7 rows affected (0.001 sec)
Rows matched: 7  Changed: 7  Warnings: 0

Query OK, 0 rows affected (0.026 sec)

क्या दिलचस्प है, आप देख सकते हैं कि अद्यतन को निष्पादित करने में लगभग 34 सेकंड लगे - यह इस तथ्य के कारण था कि प्रारंभिक लेनदेन, स्ट्रीमिंग प्रतिकृति के माध्यम से, सभी नोड्स पर सभी संशोधित पंक्तियों को बंद कर दिया और हमारे दूसरे लेनदेन के लिए इंतजार करना पड़ा दोनों लेनदेन अलग-अलग नोड्स पर निष्पादित होने के बावजूद पूरा करने वाला पहला।

जब स्ट्रीमिंग प्रतिकृति की बात आती है तो यह मूल रूप से होता है। आवश्यकताओं और ट्रैफ़िक के आधार पर आप इसे कम सख्त तरीके से उपयोग कर सकते हैं - हमने प्रत्येक पंक्ति को प्रमाणित किया है लेकिन आप इसे प्रत्येक n-th पंक्ति या प्रत्येक कथन में बदल सकते हैं। आप प्रमाणित करने के लिए डेटा की मात्रा भी तय कर सकते हैं। यह आपके पर्यावरण की आवश्यकताओं से मेल खाने के लिए पर्याप्त होना चाहिए।

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

SET SESSION wsrep_trx_fragment_size=0;

यह कथन (wsrep_trx_fragment_size को 0 पर सेट करना) वर्तमान सत्र के लिए स्ट्रीमिंग प्रतिकृति को अक्षम करता है।

एक और बात याद रखने योग्य है - यदि आप स्ट्रीमिंग प्रतिकृति का उपयोग करते हैं, तो यह स्ट्रीमिंग डेटा को लगातार संग्रहीत करने के लिए 'mysql' स्कीमा में 'wsrep_streaming_log' तालिका का उपयोग करेगा। इस तालिका का उपयोग करके आप स्ट्रीमिंग प्रतिकृति का उपयोग करके क्लस्टर में स्थानांतरित किए जा रहे डेटा के बारे में कुछ विचार प्राप्त कर सकते हैं।

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

हमने चार परिदृश्यों का परीक्षण किया:

आधारभूत, वैश्विक wsrep_trx_fragment_size=0 सेट करें;
वैश्विक wsrep_trx_fragment_unit='rows' सेट करें; वैश्विक wsrep_trx_fragment_size=1 सेट करें;
वैश्विक wsrep_trx_fragment_unit='कथन' सेट करें; वैश्विक wsrep_trx_fragment_size=1 सेट करें;
वैश्विक wsrep_trx_fragment_unit='कथन' सेट करें; वैश्विक wsrep_trx_fragment_size=5 सेट करें;

हमने sysbench r/w टेस्ट का इस्तेमाल किया:

sysbench /root/sysbench/src/lua/oltp_read_write.lua --threads=4 --events=0 --time=300 --mysql-host=10.0.0.141 --mysql-user=sbtest --mysql-password=sbtest --mysql-port=3306 --tables=32 --report-interval=1 --skip-trx=off --table-size=100000 --db-ps-mode=disable run

परिणाम हैं:

लेन-देन:82.91 प्रति सेकंड, प्रश्न:1658.27 प्रति सेकंड। (100%)
लेन-देन:54.72 प्रति सेकंड, प्रश्न:1094.43 प्रति सेकंड। (66%)
लेन-देन:54.76 प्रति सेकंड, प्रश्न:1095.18 प्रति सेकंड। (66%)
लेन-देन:70.93 प्रति सेकंड, प्रश्न:1418.55 प्रति सेकंड। (86%)

जैसा कि आप देख सकते हैं, प्रभाव महत्वपूर्ण है, प्रदर्शन 33% तक गिर जाता है।

हमें उम्मीद है कि आपको यह ब्लॉग पोस्ट जानकारीपूर्ण लगी होगी और इसने आपको स्ट्रीमिंग प्रतिकृति में कुछ अंतर्दृष्टि प्रदान की है जो गैलेरा 4 और मारियाडीबी 10.4 के साथ आती है। हमने इस नई तकनीक से संबंधित उपयोग के मामलों और संभावित कमियों को कवर करने का प्रयास किया।