Percona XtraDB क्लस्टर के लिए संक्रमण। एक संभव विन्यास

इसलिए, मैंने अपने संगठन में Percona XtraDB क्लस्टर को लागू करना शुरू कर दिया - डेटाबेस को नियमित MySQL सर्वर से क्लस्टर आर्किटेक्चर में स्थानांतरित करने के लिए।

संक्षेप में कार्य और इनपुट डेटा के बारे में

क्लस्टर में हमें रखने की आवश्यकता है:

• उपयोगकर्ताओं के साथ कई वेबसाइटों के डीबी
• इन उपयोगकर्ताओं के आंकड़ों के साथ डी.बी.
• टिकट प्रणाली, परियोजना प्रबंधन प्रणाली और अन्य trifles के लिए DB

दूसरे शब्दों में, MySQL पर चलने वाले हमारे लगभग सभी प्रोजेक्ट्स का डेटाबेस अब एक क्लस्टर में रहना चाहिए।

हम डीसी में दूर से अधिकांश परियोजनाओं को रखते हैं, इसलिए क्लस्टर वहां स्थित होगा।
भौगोलिक रूप से विभिन्न डेटा केंद्रों में क्लस्टर फैलाने का कार्य इसके लायक नहीं है।

क्लस्टर बनाने के लिए, समान कॉन्फ़िगरेशन के 3 सर्वर का उपयोग किया जाता है: HP DL160 G6, 2X Xeon E5620, 24 GB RAM, 4x SAS 300GB हार्डवेयर RAID 10. 10. एक अच्छा ब्रांडेड हार्डवेयर जो मैं लंबे समय से उपयोग कर रहा हूं और जिसने मुझे अभी तक निराश नहीं किया है।

पेरकोना क्यों?

- सिंक्रोनस ट्रू मल्टी-मास्टर प्रतिकृति (गलेरा)
- पेरकोना से वाणिज्यिक समर्थन की संभावना
- अनुकूलन की एक प्रभावशाली सूची के साथ MySQL का कांटा

क्लस्टर आरेख

क्लस्टर में 3 नोड्स हैं, ऊपर वर्णित प्रत्येक भौतिक सर्वर के लिए (ओएस उबंटू 12.04)।

यह सभी 3 सर्वरों के बीच एक वर्चुअल आईपी एड्रेस को रखने के लिए पारदर्शी कनेक्शन का उपयोग करता है। नोड्स पर लोड को संतुलित करने के लिए, HAProxy का उपयोग किया जाता है, निश्चित रूप से प्रत्येक सर्वर पर स्थापित किया जाता है, ताकि उनमें से एक की विफलता के मामले में, VIP के कारण लोड दूसरे द्वारा संतुलित किया जाता रहे। हमने जानबूझकर एलबी और वीआईपी के लिए समान ग्रंथियों का उपयोग करने का फैसला किया है।

नोड ए का उपयोग संदर्भ (बैकअप) नोड के रूप में किया जाता है, जिसे हमारे आवेदन अनुरोधों को लोड नहीं करेंगे। उसी समय, वह क्लस्टर की पूर्ण सदस्य होगी, और प्रतिकृति में भाग लेगी। यह इस तथ्य के कारण है कि क्लस्टर विफलता या डेटा अखंडता के उल्लंघन की स्थिति में, हमारे पास एक नोड होगा जिसमें लगभग निश्चित रूप से सबसे सुसंगत डेटा होता है जो एप्लिकेशन तक पहुंच की कमी के कारण नष्ट नहीं कर सकते थे। यह संसाधनों की बर्बादी की तरह लग सकता है, लेकिन हमारे लिए 99% डेटा विश्वसनीयता अभी भी 24/7 उपलब्धता से अधिक महत्वपूर्ण है। हम SST - स्टेट स्नैपशॉट ट्रांसफर के लिए इस विशेष नोड का उपयोग करेंगे - स्वचालित रूप से एक डंप को क्लस्टर से जुड़े एक नए नोड में डंप करने या विफलता के बाद उठाए जाने के लिए। इसके अलावा, नोड ए सर्वर के लिए एक उत्कृष्ट उम्मीदवार है, जहां से हम मानक आवधिक बैकअप निकाल देंगे।

योजनाबद्ध रूप से, इस तरह से सभी का प्रतिनिधित्व किया जा सकता है:


नोड बी और नोड सी काम के घोड़े हैं जो भार को पकड़ते हैं, लेकिन उनमें से केवल एक रिकॉर्डिंग ऑपरेशन का ख्याल रखता है। यह कई विशेषज्ञों की सिफारिश है, और नीचे मैं इस मुद्दे पर विस्तार से बताऊंगा।

HAProxy और संतुलन विवरण

HAProxy स्कैन नोड्स B और C के बीच राउंड रॉबिन पर 3306 पोर्ट पर आने का अनुरोध करता है ।
3307 पर जो आता है वह केवल नोड बी पर प्रस्तावित है। हालाँकि, यदि नोड बी अचानक दुर्घटनाग्रस्त हो जाता है, तो अनुरोध निर्दिष्ट नोड सी बैकअप पर जाएंगे ।

हमारे विचार को लागू करने के लिए (केवल नोड्स में से एक पर लिखें), एप्लिकेशन लिखे जाने चाहिए ताकि रीड रिक्वेस्ट 10.0.0.70:07306 (10.0.0.70 हमारा वीआईपी हो) के साथ कनेक्शन के माध्यम से जाएं , और लिखित अनुरोध 10.0.0.70 पर भेजे जाते हैं: 3307 ।

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

HAProxy config ( /etc/haproxy/haproxy.cfg ):

global log 127.0.0.1 local0 log 127.0.0.1 local1 notice maxconn 4096 chroot /usr/share/haproxy daemon defaults log global mode http option tcplog option dontlognull retries 3 option redispatch maxconn 2000 contimeout 5000 clitimeout 50000 srvtimeout 50000 frontend pxc-front bind 10.0.0.70:3306 mode tcp default_backend pxc-back frontend stats-front bind *:81 mode http default_backend stats-back frontend pxc-onenode-front bind 10.0.0.70:3307 mode tcp default_backend pxc-onenode-back backend pxc-back mode tcp balance leastconn option httpchk server c1 10.0.0.106:33061 check port 9200 inter 12000 rise 3 fall 3 server c2 10.0.0.107:33061 check port 9200 inter 12000 rise 3 fall 3 backend stats-back mode http balance roundrobin stats uri /haproxy/stats stats auth haproxy:password backend pxc-onenode-back mode tcp balance leastconn option httpchk server c1 10.0.0.106:33061 check port 9200 inter 12000 rise 3 fall 3 server c2 10.0.0.107:33061 check port 9200 inter 12000 rise 3 fall 3 backup backend pxc-referencenode-back mode tcp balance leastconn option httpchk server c0 10.0.0.105:33061 check port 9200 inter 12000 rise 3 fall 3 

HAProxy के लिए यह निर्धारित करने के लिए कि क्लस्टर नोड जीवित है या नहीं, क्लस्टरस्टेक उपयोगिता का उपयोग किया जाता है (percona-xtradb- क्लस्टर पैकेज में शामिल), जो नोड की स्थिति के बारे में जानकारी प्रदर्शित करता है (Synced / Not Synced) एक HTTP प्रतिक्रिया के रूप में। प्रत्येक नोड पर, xinetd सेवा को कॉन्फ़िगर किया जाना चाहिए:

/etc/xinetd.d/mysqlchk

 service mysqlchk { disable = no flags = REUSE socket_type = stream port = 9200 wait = no user = nobody server = /usr/bin/clustercheck log_on_failure += USERID only_from = 0.0.0.0/0 per_source = UNLIMITED } 

/ आदि / सेवाएं

 ... # Local services mysqlchk 9200/tcp # mysqlchk 

HAProxy एक वेब सर्वर उठाता है और आँकड़े देखने के लिए एक स्क्रिप्ट प्रदान करता है, जो क्लस्टर स्थिति की दृश्य निगरानी के लिए बहुत सुविधाजनक है।
URL इस तरह दिखता है:

  http: // VIP: 81 / haproxy / आँकड़े 

पोर्ट, साथ ही बेसिक प्राधिकरण के लिए लॉगिन और पासवर्ड विन्यास में निर्दिष्ट हैं।

अच्छी तरह से यहाँ HAProxy के माध्यम से संतुलन के साथ एक क्लस्टर की स्थापना के मुद्दे पर विचार किया गया: www.mysqlperformanceblog.com/2012/06/20/percona-xtradb-cluster-reference-altecture-with-pproxy

रखने और वीआईपी

 $ echo "net.ipv4.ip_nonlocal_bind=1" >> /etc/sysctl.conf && sysctl -p 

/etc/keepalived/keepalived.conf

 vrrp_script chk_haproxy { # Requires keepalived-1.1.13 script "killall -0 haproxy" # cheaper than pidof interval 2 # check every 2 seconds weight 2 # add 2 points of prio if OK } vrrp_instance VI_1 { interface eth0 state MASTER # SLAVE on backup virtual_router_id 51 priority 101 # 101 on master, 100 and 99 on backup virtual_ipaddress { 10.0.0.70 } track_script { chk_haproxy } } 

नोड कॉन्फ़िगरेशन

PXC स्थापित करने और परीक्षण करने के बारे में Habr पर पहले से ही एक लेख है: habrahabr.ru/post/152969 , जहां दोनों मुद्दों पर विस्तार से चर्चा की गई है, इसलिए मैं स्थापना को छोड़ देता हूं। लेकिन मैं कॉन्फ़िगरेशन का वर्णन करूंगा।

सबसे पहले, सभी नोड्स पर समय को सिंक्रनाइज़ करने के लिए मत भूलना। मैं इस बिंदु से चूक गया, और लंबे समय तक मैं समझ नहीं पाया कि मेरा एसएसटी कसकर लटका क्यों था - यह शुरू हुआ, प्रक्रियाओं में लटका दिया गया, लेकिन वास्तव में कुछ भी नहीं हुआ।

my.cnf on Node A (मेरे कॉन्फिग में यह नोड 105 है ):

 [mysqld_safe] wsrep_urls=gcomm://10.0.0.106:4567,gcomm://10.0.0.107:4567 # wsrep_urls=gcomm://10.0.0.106:4567,gcomm://10.0.0.107:4567,gcomm:// #   - ,    #   , ..     #   ,      [mysqld] port=33061 bind-address=10.0.0.105 datadir=/var/lib/mysql skip-name-resolve log_error=/var/log/mysql/error.log binlog_format=ROW wsrep_provider=/usr/lib/libgalera_smm.so wsrep_slave_threads=16 wsrep_cluster_name=cluster0 wsrep_node_name=node105 wsrep_sst_method=xtrabackup wsrep_sst_auth=backup:password innodb_locks_unsafe_for_binlog=1 innodb_autoinc_lock_mode=2 innodb_buffer_pool_size=8G innodb_log_file_size=128M innodb_log_buffer_size=4M innodb-file-per-table 

इसके अलावा, केवल अलग-अलग पैरामीटर हैं:

नोड बी (नोड106)

 [mysqld_safe] wsrep_urls=gcomm://10.0.0.105:4567 [mysqld] bind-address=10.0.0.106 wsrep_node_name=node106 wsrep_sst_donor=node105 

नोड सी (नोड 106)

 [mysqld_safe] wsrep_urls=gcomm://10.0.0.105:4567 [mysqld] bind-address=10.0.0.107 wsrep_node_name=node107 wsrep_sst_donor=node105 

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

यह इस कॉन्फ़िगरेशन पर है जिसे मैंने अब बंद कर दिया है, और धीरे-धीरे परियोजनाओं को क्लस्टर में स्थानांतरित करने जा रहा हूं। मेरी योजना है कि मैं आगे अपने अनुभव के बारे में लिखता रहूं।

समस्याग्रस्त मुद्दे

मैं यहां उन प्रश्नों की रूपरेखा तैयार करूंगा, जिनके उत्तर मुझे तुरंत नहीं मिले, लेकिन इसका उत्तर विशेष रूप से प्रौद्योगिकी को समझने और क्लस्टर के साथ सही ढंग से काम करने के लिए महत्वपूर्ण है।

क्लस्टर में उपलब्ध सभी में से एक नोड पर लिखने की सिफारिश क्यों की जाती है? आखिरकार, ऐसा लगता है कि यह मल्टी-मास्टर प्रतिकृति के विचार का खंडन करता है।

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

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

किसी नए को जोड़ते समय क्लस्टर में मौजूदा नोड्स के आईपी पते कैसे निर्दिष्ट करें?

इसके लिए 2 निर्देश हैं:

 [mysqld_safe] wsrep_urls [mysqld] wsrep_cluster_address 

पहला, अगर मुझे सही ढंग से समझ में आया, तो गलेरा द्वारा अपेक्षाकृत हाल ही में एक साथ कई नोड पते निर्दिष्ट करने की क्षमता के लिए जोड़ा गया था। अधिक बुनियादी अंतर नहीं हैं।

इन निर्देशों का अर्थ पहली बार में मेरे लिए विशेष भ्रम का कारण बना।
तथ्य यह है कि कई मैनुअल ने क्लस्टर के पहले नोड पर खाली wsrep_urls में gcomm: // value छोड़ने की सलाह दी।
यह गलत निकला। Gcomm की उपस्थिति : // का अर्थ है एक नए क्लस्टर का आरंभ। इसलिए, इसके कॉन्फ़िगरेशन में पहला नोड शुरू होने के तुरंत बाद, आपको इस मान को हटाने की आवश्यकता है। अन्यथा, इस नोड को पुनरारंभ करने के बाद, आपको दो अलग-अलग क्लस्टर मिलेंगे, जिनमें से एक में केवल पहला नोड होगा।

अपने लिए, मैंने क्लस्टर शुरू करने और फिर से शुरू करने पर कॉन्फ़िगरेशन ऑर्डर घटा दिया (पहले से ही ऊपर और अधिक विवरण में वर्णित है)
1. नोड A: gcomm के साथ चल रहा है : // B, gcomm: // C, gcomm: //
2. नोड ए: लाइन के अंत में gcomm: // निकालना
3. नोड्स बी, सी: जीकॉम के साथ शुरू : // ए

NB: आपको समूह संचार अनुरोधों के लिए पोर्ट संख्या निर्दिष्ट करनी होगी, डिफ़ॉल्ट रूप से यह 4567 है। यानी, सही प्रविष्टि है: gcomm: // A: 4567

क्या मैं एक एसएसटी विधि के रूप में एक गैर-अवरुद्ध xtrabackup के साथ दाता नोड को लिख सकता हूं?

एसएसटी के दौरान, दाता पर क्लॉस्टरचेक क्रमशः एचएप्रोसी या किसी अन्य एलबी के लिए HTTP 503 जारी करेगा जो स्थिति को निर्धारित करने के लिए इस उपयोगिता का उपयोग करता है, दाता नोड अनुपलब्ध माना जाएगा, साथ ही साथ वह नोड जिसे हस्तांतरण किया गया है। लेकिन इस व्यवहार को क्लस्टर्कचेक को संपादित करके बदला जा सकता है, जो अनिवार्य रूप से एक नियमित बैश स्क्रिप्ट है।
यह निम्नानुसार किया जाता है:

/ usr / bin / clustercheck

 #AVAILABLE_WHEN_DONOR=0 AVAILABLE_WHEN_DONOR=1 

NB: ध्यान दें कि यह केवल तभी किया जा सकता है जब आप सुनिश्चित हों कि xtrabackup का उपयोग SST के रूप में किया जाता है, न कि किसी अन्य विधि से। हमारे मामले में, जब हम दाता के रूप में लोड के बिना एक नोड का उपयोग करते हैं, तो ऐसे संपादन का कोई मतलब नहीं होता है।

उपयोगी लिंक

पर्कोना XtraDB क्लस्टर
Mysqlperfomanceblog.com पर XtraDB क्लस्टर
पर्कोना सामुदायिक मंच
Percona चर्चा Google समूह
गलरा विकी