MariaDB
 sql >> डेटाबेस >  >> RDS >> MariaDB

MySQL गैलेरा क्लस्टर स्ट्रीमिंग प्रतिकृति के लिए एक गाइड:भाग दो

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

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

यह अत्यधिक अनुशंसा की जाती है कि आप अपने एप्लिकेशन/क्लाइंट के साथ इंटरैक्ट करने वाले विशिष्ट लेनदेन के लिए सत्र-स्तर पर स्ट्रीमिंग प्रतिकृति सक्षम करें।

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

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

नीचे एक उदाहरण दिया गया है कि इन दो मापदंडों को कैसे सेट किया जाए:

SET SESSION wsrep_trx_fragment_unit='statements';

SET SESSION wsrep_trx_fragment_size=3;

इस उदाहरण में, खंड तीन कथनों पर सेट है। लेन-देन से प्रत्येक तीन बयानों के लिए, नोड एक टुकड़ा उत्पन्न करेगा, दोहराएगा और प्रमाणित करेगा।

टुकड़े बनाते समय आप कुछ प्रतिकृति इकाइयों के बीच चयन कर सकते हैं:

  • बाइट्स - यह टुकड़े के आकार को बाइट्स में परिभाषित करता है।
  • पंक्तियां - यह फ़्रेगमेंट आकार को फ़्रेगमेंट अपडेट की पंक्तियों की संख्या के रूप में परिभाषित करता है।
  • बयान - यह खंड के आकार को एक टुकड़े में बयानों की संख्या के रूप में परिभाषित करता है।

प्रतिकृति इकाई और टुकड़े का आकार चुनें जो उस विशिष्ट ऑपरेशन के लिए सबसे उपयुक्त हो जिसे आप चलाना चाहते हैं।

स्ट्रीमिंग प्रतिकृति कार्रवाई में

जैसा कि मारियाडब 10.4 में बड़े लेनदेन को संभालने पर हमारे अन्य ब्लॉग में चर्चा की गई है, हमने प्रदर्शन किया और परीक्षण किया कि इस मानदंड के आधार पर सक्षम होने पर स्ट्रीमिंग प्रतिकृति ने कैसा प्रदर्शन किया...

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

और परिणाम हैं

Transactions: 82.91 per sec., queries: 1658.27 per sec. (100%)

Transactions: 54.72 per sec., queries: 1094.43 per sec. (66%)

Transactions: 54.76 per sec., queries: 1095.18 per sec. (66%)

Transactions: 70.93 per sec., queries: 1418.55 per sec. (86%)

इस उदाहरण के लिए हम Percona XtraDB क्लस्टर 8.0.15 का उपयोग सीधे उनकी परीक्षण शाखा से Percona-XtraDB-Cluster_8.0.15.5-27dev.4.2_Linux.x86_64.ssl102.tar.gz का उपयोग करके कर रहे हैं। निर्माण।

फिर हमने नीचे दी गई मेजबान जानकारी के साथ 3-नोड गैलेरा क्लस्टर की कोशिश की:

testnode11 = 192.168.10.110

testnode12 = 192.168.10.120

testnode13 = 192.168.10.130

हमने अपने sysbench डेटाबेस से एक तालिका को पहले से भर दिया और एक बहुत बड़ी पंक्तियों को हटाने का प्रयास किया। 

[email protected][sbtest]#> select count(*) from sbtest1;

+----------+

| count(*) |

+----------+

| 12608218 |

+----------+

1 row in set (25.55 sec)

सबसे पहले, स्ट्रीमिंग प्रतिकृति के बिना चल रहा है,

[email protected][sbtest]#> select @@wsrep_trx_fragment_unit, @@wsrep_trx_fragment_size,  @@innodb_lock_wait_timeout;

+---------------------------+---------------------------+----------------------------+

| @@wsrep_trx_fragment_unit | @@wsrep_trx_fragment_size | @@innodb_lock_wait_timeout |

+---------------------------+---------------------------+----------------------------+

| bytes                     | 0 |                         50000 |

+---------------------------+---------------------------+----------------------------+

1 row in set (0.00 sec)

फिर दौड़ें,

[email protected][sbtest]#> delete from sbtest1 where id >= 2000000;

हालांकि, हमें रोलबैक मिल गया...

---TRANSACTION 648910, ACTIVE 573 sec rollback

mysql tables in use 1, locked 1

ROLLING BACK 164858 lock struct(s), heap size 18637008, 12199395 row lock(s), undo log entries 11961589

MySQL thread id 183, OS thread handle 140041167468288, query id 79286 localhost 127.0.0.1 root wsrep: replicating and certifying write set(-1)

delete from sbtest1 where id >= 2000000

प्रवाह नियंत्रण के किसी भी संकेत का अवलोकन एकत्र करने के लिए ClusterControl डैशबोर्ड का उपयोग करना, चूंकि लेन-देन पूरी तरह से मास्टर (सक्रिय-लेखक) नोड पर प्रतिबद्ध समय तक चलता है, प्रवाह नियंत्रण के लिए गतिविधि का कोई संकेत नहीं है:

यदि आप सोच रहे हैं, तो ClusterControl का वर्तमान संस्करण अभी तक उपलब्ध नहीं है। गैलेरा क्लस्टर 4 के साथ पीएक्ससी 8.0 के लिए सीधा समर्थन है (क्योंकि यह अभी भी प्रयोगात्मक है)। हालाँकि, आप इसे आयात करने का प्रयास कर सकते हैं... लेकिन आपके डैशबोर्ड को सही ढंग से काम करने के लिए इसमें मामूली बदलाव की आवश्यकता है।

क्वेरी प्रक्रिया पर वापस जाएं। वापस लुढ़कते ही यह विफल हो गया!

[email protected][sbtest]#> delete from sbtest1 where id >= 2000000;

ERROR 1180 (HY000): Got error 5 - 'Transaction size exceed set threshold' during COMMIT

wsrep_max_ws_rows या wsrep_max_ws_size पर ध्यान दिए बिना,

[email protected][sbtest]#> select @@global.wsrep_max_ws_rows, @@global.wsrep_max_ws_size/(1024*1024*1024);

+----------------------------+---------------------------------------------+

| @@global.wsrep_max_ws_rows | @@global.wsrep_max_ws_size/(1024*1024*1024) |

+----------------------------+---------------------------------------------+

|                          0 |               2.0000 |

+----------------------------+---------------------------------------------+

1 row in set (0.00 sec)

आखिरकार, यह दहलीज पर पहुंच गया।

इस समय के दौरान सिस्टम टेबल mysql.wsrep_streaming_log खाली है, जो दर्शाता है कि स्ट्रीमिंग प्रतिकृति नहीं हो रही है या सक्षम नहीं है,

[email protected][sbtest]#> select count(*) from mysql.wsrep_streaming_log;

+----------+

| count(*) |

+----------+

|        0 |

+----------+

1 row in set (0.01 sec)



[email protected][sbtest]#> select count(*) from mysql.wsrep_streaming_log;

+----------+

| count(*) |

+----------+

|        0 |

+----------+

1 row in set (0.00 sec)

और यह अन्य 2 नोड्स (testnode12 और testnode13) पर सत्यापित है।

अब, स्ट्रीमिंग प्रतिकृति के साथ इसे सक्षम करने का प्रयास करते हैं,

[email protected][sbtest]#> select @@wsrep_trx_fragment_unit, @@wsrep_trx_fragment_size, @@innodb_lock_wait_timeout;

+---------------------------+---------------------------+----------------------------+

| @@wsrep_trx_fragment_unit | @@wsrep_trx_fragment_size | @@innodb_lock_wait_timeout |

+---------------------------+---------------------------+----------------------------+

| bytes                     | 0 |                      50000 |

+---------------------------+---------------------------+----------------------------+

1 row in set (0.00 sec)



[email protected][sbtest]#> set wsrep_trx_fragment_unit='rows'; set wsrep_trx_fragment_size=100; 

Query OK, 0 rows affected (0.00 sec)



Query OK, 0 rows affected (0.00 sec)



[email protected][sbtest]#> select @@wsrep_trx_fragment_unit, @@wsrep_trx_fragment_size, @@innodb_lock_wait_timeout;

+---------------------------+---------------------------+----------------------------+

| @@wsrep_trx_fragment_unit | @@wsrep_trx_fragment_size | @@innodb_lock_wait_timeout |

+---------------------------+---------------------------+----------------------------+

| rows                      | 100 |                      50000 |

+---------------------------+---------------------------+----------------------------+

1 row in set (0.00 sec)

गैलेरा क्लस्टर स्ट्रीमिंग प्रतिकृति सक्षम होने पर क्या अपेक्षा करें?

जब testnode11 में क्वेरी की गई हो,

[email protected][sbtest]#> delete from sbtest1 where id >= 2000000;

क्या होता है कि यह चर wsrep_trx_fragment_size के सेट मान के आधार पर लेन-देन के टुकड़े को टुकड़े-टुकड़े कर देता है। आइए इसे अन्य नोड्स में जांचें:

टेस्टनोड12 होस्ट करें

[email protected][sbtest]#> pager sed -n '/TRANSACTIONS/,/FILE I\/O/p'; show engine innodb status\G nopager; show global status like 'wsrep%flow%'; select count(*) from mysql.wsrep_streaming_log;

PAGER set to 'sed -n '/TRANSACTIONS/,/FILE I\/O/p''

TRANSACTIONS

------------

Trx id counter 567148

Purge done for trx's n:o < 566636 undo n:o < 0 state: running but idle

History list length 44

LIST OF TRANSACTIONS FOR EACH SESSION:

..

...

---TRANSACTION 421740651985200, not started

0 lock struct(s), heap size 1136, 0 row lock(s)

---TRANSACTION 553661, ACTIVE 190 sec

18393 lock struct(s), heap size 2089168, 1342600 row lock(s), undo log entries 1342600

MySQL thread id 898, OS thread handle 140266050008832, query id 216824 wsrep: applied write set (-1)

--------

FILE I/O

1 row in set (0.08 sec)



PAGER set to stdout

+----------------------------------+--------------+

| Variable_name                    | Value |

+----------------------------------+--------------+

| wsrep_flow_control_paused_ns     | 211197844753 |

| wsrep_flow_control_paused        | 0.133786 |

| wsrep_flow_control_sent          | 633 |

| wsrep_flow_control_recv          | 878 |

| wsrep_flow_control_interval      | [ 173, 173 ] |

| wsrep_flow_control_interval_low  | 173 |

| wsrep_flow_control_interval_high | 173          |

| wsrep_flow_control_status        | OFF |

+----------------------------------+--------------+

8 rows in set (0.00 sec)



+----------+

| count(*) |

+----------+

|    13429 |

+----------+

1 row in set (0.04 sec)

टेस्टनोड13 होस्ट करें

[email protected][sbtest]#> pager sed -n '/TRANSACTIONS/,/FILE I\/O/p'; show engine innodb status\G nopager; show global status like 'wsrep%flow%'; select count(*) from mysql.wsrep_streaming_log;

PAGER set to 'sed -n '/TRANSACTIONS/,/FILE I\/O/p''

TRANSACTIONS

------------

Trx id counter 568523

Purge done for trx's n:o < 567824 undo n:o < 0 state: running but idle

History list length 23

LIST OF TRANSACTIONS FOR EACH SESSION:

..

...

---TRANSACTION 552701, ACTIVE 216 sec

21587 lock struct(s), heap size 2449616, 1575700 row lock(s), undo log entries 1575700

MySQL thread id 936, OS thread handle 140188019226368, query id 600980 wsrep: applied write set (-1)

--------

FILE I/O

1 row in set (0.28 sec)



PAGER set to stdout

+----------------------------------+--------------+

| Variable_name                    | Value |

+----------------------------------+--------------+

| wsrep_flow_control_paused_ns     | 210755642443 |

| wsrep_flow_control_paused        | 0.0231273 |

| wsrep_flow_control_sent          | 1653 |

| wsrep_flow_control_recv          | 3857 |

| wsrep_flow_control_interval      | [ 173, 173 ] |

| wsrep_flow_control_interval_low  | 173 |

| wsrep_flow_control_interval_high | 173          |

| wsrep_flow_control_status        | OFF |

+----------------------------------+--------------+

8 rows in set (0.01 sec)



+----------+

| count(*) |

+----------+

|    15758 |

+----------+

1 row in set (0.03 sec)

ध्यान से, प्रवाह नियंत्रण अभी शुरू हुआ!

और WSREP कतारें भेजने/प्राप्त करने की भी शुरुआत हो रही है:

होस्ट टेस्टनोड12 (192.168.10.120)  होस्ट testnode13 (192.168.10.130)

अब, परिणाम के बारे में अधिक विस्तार से बताते हैं mysql.wsrep_streaming_log तालिका से,

[email protected][sbtest]#> pager sed -n '/TRANSACTIONS/,/FILE I\/O/p'|tail -8; show engine innodb status\G nopager;

PAGER set to 'sed -n '/TRANSACTIONS/,/FILE I\/O/p'|tail -8'

MySQL thread id 134822, OS thread handle 140041167468288, query id 0 System lock

---TRANSACTION 649008, ACTIVE 481 sec

mysql tables in use 1, locked 1

53104 lock struct(s), heap size 6004944, 3929602 row lock(s), undo log entries 3876500

MySQL thread id 183, OS thread handle 140041167468288, query id 105367 localhost 127.0.0.1 root updating

delete from sbtest1 where id >= 2000000

--------

FILE I/O

1 row in set (0.01 sec)

फिर इसका परिणाम लेते हुए,

[email protected][sbtest]#> select count(*) from mysql.wsrep_streaming_log;

+----------+

| count(*) |

+----------+

|    38899 |

+----------+

1 row in set (0.40 sec)

यह बताता है कि स्ट्रीमिंग प्रतिकृति का उपयोग करके कितना टुकड़ा दोहराया गया है। अब, कुछ बुनियादी गणित करते हैं:

[email protected][sbtest]#> select 3876500/38899.0;

+-----------------+

| 3876500/38899.0 |

+-----------------+

|         99.6555 |

+-----------------+

1 row in set (0.03 sec)

मैं शो इंजन INNODB STATUS\G परिणाम से पूर्ववत लॉग प्रविष्टियां ले रहा हूं और फिर mysql.wsrep_streaming_log रिकॉर्ड की कुल संख्या को विभाजित करता हूं। जैसा कि मैंने इसे पहले सेट किया है, मैंने wsrep_trx_fragment_size=100 को परिभाषित किया है। परिणाम आपको दिखाएगा कि वर्तमान में गैलेरा द्वारा कुल प्रतिकृति लॉग को कितना संसाधित किया जा रहा है।

यह ध्यान रखना महत्वपूर्ण है कि स्ट्रीमिंग प्रतिकृति क्या हासिल करने की कोशिश कर रही है... "नोड लेन-देन को टुकड़ों में तोड़ देता है, फिर लेन-देन के दौरान दासों पर उन्हें प्रमाणित और दोहराता है। प्रगति। एक बार प्रमाणित हो जाने के बाद, खंड को परस्पर विरोधी लेन-देन द्वारा निरस्त नहीं किया जा सकता है।"

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

अब, एक विशाल तालिका को हटाने का निर्णय? 

[email protected][sbtest]#> delete from sbtest1 where id >= 2000000;

Query OK, 12034538 rows affected (30 min 36.96 sec)

यह बिना किसी असफलता के सफलतापूर्वक समाप्त होता है!

अन्य नोड्स में यह कैसा दिखता है? टेस्टनोड12 में,

[email protected][sbtest]#> pager sed -n '/TRANSACTIONS/,/FILE I\/O/p'|tail -8; show engine innodb status\G nopager; show global status like 'wsrep%flow%'; select count(*) from mysql.wsrep_streaming_log;

PAGER set to 'sed -n '/TRANSACTIONS/,/FILE I\/O/p'|tail -8'

0 lock struct(s), heap size 1136, 0 row lock(s)

---TRANSACTION 421740651985200, not started

0 lock struct(s), heap size 1136, 0 row lock(s)

---TRANSACTION 553661, ACTIVE (PREPARED) 2050 sec

165631 lock struct(s), heap size 18735312, 12154883 row lock(s), undo log entries 12154883

MySQL thread id 898, OS thread handle 140266050008832, query id 341835 wsrep: preparing to commit write set(215510)

--------

FILE I/O

1 row in set (0.46 sec)



PAGER set to stdout

+----------------------------------+--------------+

| Variable_name                    | Value |

+----------------------------------+--------------+

| wsrep_flow_control_paused_ns     | 290832524304 |

| wsrep_flow_control_paused        | 0 |

| wsrep_flow_control_sent          | 0 |

| wsrep_flow_control_recv          | 0 |

| wsrep_flow_control_interval      | [ 173, 173 ] |

| wsrep_flow_control_interval_low  | 173 |

| wsrep_flow_control_interval_high | 173          |

| wsrep_flow_control_status        | OFF |

+----------------------------------+--------------+

8 rows in set (0.53 sec)



+----------+

| count(*) |

+----------+

|   120345 |

+----------+

1 row in set (0.88 sec)

यह कुल 120345 अंशों पर रुकता है, और यदि हम पिछली कैप्चर की गई पूर्ववत लॉग प्रविष्टियों पर फिर से गणित करते हैं (पूर्ववत लॉग मास्टर से भी समान हैं),

[email protected][sbtest]#> select 12154883/120345.0;                                                                                                                                                   +-------------------+

| 12154883/120345.0 |

+-------------------+

|          101.0003 |

+-------------------+

1 row in set (0.00 sec)

तो हमारे पास कुल 120345 . था 12034538 . को हटाने के लिए लेन-देन को खंडित किया जा रहा है पंक्तियाँ।

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

[email protected][sbtest]#> set wsrep_trx_fragment_size=0;

Query OK, 0 rows affected (0.04 sec)

निष्कर्ष

स्ट्रीमिंग प्रतिकृति सक्षम होने के साथ, यह महत्वपूर्ण है कि आप यह पहचानने में सक्षम हों कि आपके टुकड़े का आकार कितना बड़ा हो सकता है और आपको कौन सी इकाई चुननी है (बाइट्स, रो, स्टेटमेंट)।

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

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

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

अंत में, यदि आप स्ट्रीमिंग प्रतिकृति का उपयोग कर रहे हैं, तो अवांछित समस्याओं से बचने के लिए उस वर्तमान सत्र में एक बार हो जाने के बाद इसे हमेशा अक्षम करना न भूलें।


  1. Database
    2.   
  2. Mysql
    3.   
  3. Oracle
    4.   
  4. Sqlserver
    5.   
  5. PostgreSQL
    6.   
  6. Access
    7.   
  7. SQLite
    8.   
  8. MariaDB

  1. MySQL में लॉक वेट टाइमआउट से अधिक त्रुटि को कैसे ठीक करें

  2. मारियाडीबी बैकअप में जाना

  3. मारियाडीबी में MONTHNAME () कैसे काम करता है

  4. कैसे जोड़ें () मारियाडीबी में काम करता है

  5. मारियाडीबी में एक तारीख से एक महीना घटाएं