पर्कोना XtraDB क्लस्टर। स्थापना और परीक्षण

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

लेकिन गैलेरा क्लस्टर नामक एक वैकल्पिक समाधान है, जिस पर पेरकोना एक्स्ट्राबर्ड क्लस्टर आधारित है, जो कि उबंटू के संबंध में स्थापना, कॉन्फ़िगरेशन और परीक्षण के बारे में बताएगा।

NDBcluster बेहतर क्यों है?

पहला: कम प्रतिबंध (NDBcluster प्रतिबंधों की सूची: dev.mysql.com/doc/refman/5.5/en/mysql-cluster-limitations.html , XtraDB क्लस्टर प्रतिबंधों की सूची: www.percona.com/loc/percona-xtradb -cluster / limitation.html )।
मुझे केवल InnoDB में कुछ MyISAM तालिकाओं को फिर से करना पड़ा।
दूसरी बात: पेरकोना कोड इंजन के कई MySQL पैच।
तीसरा: दो-एकल कॉन्फ़िगरेशन में काम करने की क्षमता (मैं तुरंत एक आरक्षण कर दूंगा कि यह केवल परीक्षण के लिए उपयुक्त है)।
और अंत में, MySQL कांटे अब चलन में हैं :)

MySQL के एक कांटे पर खराब होने वाले गैलेरा क्लस्टर से बेहतर क्या है?

Xtrabackup उपयोगिता की उपस्थिति, जो आपको मक्खी पर बैकअप बनाने की अनुमति देती है। यह उपयोगी है क्योंकि जब आप क्लस्टर में एक नया नोड कनेक्ट करते हैं, तो आपको डेटाबेस से इसे निकालने के लिए किसी भी काम करने वाले नोड्स को रोकने की आवश्यकता नहीं है।

स्थापना

उबंटू के तहत स्थापना, हमेशा की तरह, प्राथमिक है:

gpg --keyserver hkp://keys.gnupg.net --recv-keys 1C4CBDCDCD2EFD2A gpg -a --export CD2EFD2A | sudo apt-key add - sudo apt-get update sudo apt-get install percona-xtradb-cluster-server-5.5 

कभी-कभी वह बेकार की निर्भरता पर कसम खाता है। फिर पहले निर्भरता स्थापित करना और फिर स्वयं सर्वर को स्थापित करना पर्याप्त है।

सबसे पहले, सेटिंग्स में कुछ भी बदले बिना, आपको mysql कंसोल पर जाना होगा (पहले लॉन्च किए गए नोड पर पर्याप्त) और बैकअप के लिए उपयोगकर्ता जोड़ें:

 grant RELOAD, LOCK TABLES, REPLICATION CLIENT, FILE on *.* to backup@localhost identified by 'password'; 

फिर आपको एक छोटे से काम की आवश्यकता है। तथ्य यह है कि उबंट में, श के साथ एक सिम्कलिन डैश की ओर जाता है, और क्लस्टर स्टार्ट स्क्रिप्ट को बैश के लिए डिज़ाइन किया गया है। यदि कोई मतभेद नहीं हैं, तो आप इस प्रणाली को हल कर सकते हैं:

 dpkg-reconfigure dash 

उत्तर नं।

चूंकि क्लस्टर शुरू करने के बाद डेटाबेस पूरी तरह से समान हो जाएगा, इसलिए सभी नोड्स पर सिस्टम उपयोगकर्ता का पासवर्ड पहले जैसा हो जाएगा। इसलिए, आपको सर्वर से /etc/mysql/debian.cnf फ़ाइल को कॉपी करना होगा जो पहले दूसरों के लिए लॉन्च की जाएगी।

मेरे विन्यास इस तरह दिखते हैं:

 [mysqld_safe] wsrep_urls=gcomm://192.168.1.1:3400,gcomm://192.168.1.2:3400,gcomm:// [mysqld] port=3306 socket=/var/run/mysqld/mysqld.sock datadir=/var/lib/mysql basedir=/usr user=mysql log_error=error.log binlog_format=ROW wsrep_provider=/usr/lib/libgalera_smm.so wsrep_sst_receive_address=192.168.1.1:3500 wsrep_node_incoming_address=192.168.1.1 wsrep_slave_threads=2 wsrep_cluster_name=cluster0 wsrep_provider_options="gmcast.listen_addr=tcp://192.168.1.1:3400;" wsrep_sst_method=xtrabackup wsrep_sst_auth=backup:password wsrep_node_name=node0 innodb_locks_unsafe_for_binlog=1 innodb_autoinc_lock_mode=2 innodb_buffer_pool_size=5000M innodb_log_file_size=256M innodb_log_buffer_size=4M [client] port=3306 socket=/var/run/mysqld/mysqld.sock 

Libgalera_smm.so के स्थान की जाँच करें।
Wsrep_slave_threads पैरामीटर का मान कोर * 4 की संख्या के रूप में सेट करने की अनुशंसा की जाती है।
Wsrep_sst_auth में, बैकअप के लिए उपयोगकर्ता नाम और पासवर्ड निर्दिष्ट हैं।
innodb_buffer_pool_size, innodb_log_file_size, innodb_log_buffer_size - प्रदर्शन को प्रभावित करते हैं, और प्रयोगात्मक रूप से चुने जाते हैं। मेरे मामले में, प्रत्येक नोड में 8 g RAM की लागत होती है।

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

मेरे सेटअप में, पोर्ट 3400 का उपयोग सिंक्रनाइज़ेशन के लिए किया जाता है, पोर्ट 3500 का उपयोग डंप को भरने के लिए किया जाता है, पोर्ट 3306 (मानक) का उपयोग क्लाइंट को जोड़ने के लिए किया जाता है।

आप एक ही मशीन पर कई नोड चला सकते हैं, जिससे उन्हें अलग-अलग पोर्ट दिए जा सकते हैं। यदि आप ऐसा करने का निर्णय लेते हैं, तो आपको / etc / mysql में कई कॉन्फ़िगरेशन फ़ाइलें बनाने और सर्वर को इसके लिए उदाहरण के लिए शुरू करने की आवश्यकता है:

 /usr/bin/mysqld_safe --defaults-file=/etc/mysql/my0.cnf 

ध्यान दें कि xtrabackup केवल मानक सॉकेट /var/run/mysqld/mysqld.sock का उपयोग करके कनेक्ट कर सकता है (कॉन्फ़िगरेशन से मापदंडों को अनदेखा करता है)। तो इस मामले में आपको इसका उपयोग नहीं करना है: wsrep_sst_method = rsync

खैर, निष्कर्ष में, डेमॉन को पुनः आरंभ करें:

 sudo service mysql restart 

अगर कुछ गलत हुआ, तो /var/lib/mysql/error.log देखें।
आमतौर पर आपको लॉग में लॉग के आकार में परिवर्तन के कारण / var / lib / mysql / ib_logfile * को हटाने की आवश्यकता होती है।

कभी-कभी पूरे / var / lib / mysql / (यदि डेटाबेस में कोई मूल्य नहीं है) को मिटाना और डिफ़ॉल्ट डेटाबेस को फिर से बनाना आसान है:

 mysql_install_db 

कुछ अन्य संभावित त्रुटियां जिन्हें मैंने लेख के अंत में उद्धृत किया है।

नोड्स की संख्या

निर्माता कम से कम तीन की सिफारिश करता है, लेकिन एनडीबी से मतभेद हैं: शुरू में, सभी नोड एक ही रैंक के हैं और समान कार्यक्षमता है। कुछ भी आपको 2 नोड बनाने से रोकता है।

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

मेरे मामले में तीन नोड्स वाला विकल्प फिट नहीं था, क्योंकि मेरे पास केवल 2 सर्वर हैं जो कि कॉलोकोक्शन पर हैं, और कार्यालय चैनल पर कहीं एक तीसरे को जोड़ने से प्रदर्शन बहुत खराब हो जाएगा, क्योंकि क्लस्टर ऑपरेशन की गति इसकी सबसे धीमी नोड द्वारा निर्धारित की जाती है।

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

 garbd -a gcomm://192.168.1.1:3400 -g cluster0 

परीक्षण

मैंने परीक्षण पैकेज से मानक एसक्यूएल-बेंच उपयोगिता का परीक्षण किया, पहले नोड्स अलग से, और फिर क्लस्टर। सॉफ्टवेयर एक ही समय में नहीं बदला - पेरकोना-ऑक्सट्रैब-क्लस्टर।

स्थापित करें और परीक्षण पैकेज चलाएँ:

 apt-get install percona-server-test-5.5 libdbd-mysql-perl cd /usr/share/sql-bench/sql-bench/ perl run-all-tests --server=mysql --user=root --password=<password> 

पहले SSD के साथ दो समान तेज़ मशीनों पर परीक्षण किया गया।
मैंने पहले रन के परिणामों को फेंक दिया, क्योंकि वे बाद वाले लोगों की तुलना में बहुत बेहतर थे (हम शुद्ध एसएसडी को लिखेंगे)।

यह 1 नोड है:

 alter-table: Total time: 17 wallclock secs ( 0.04 usr 0.00 sys + 0.00 cusr 0.00 csys = 0.04 CPU) ATIS: Total time: 7 wallclock secs ( 2.48 usr 0.16 sys + 0.00 cusr 0.00 csys = 2.64 CPU) big-tables: Total time: 10 wallclock secs ( 1.87 usr 0.34 sys + 0.00 cusr 0.00 csys = 2.21 CPU) connect: Total time: 64 wallclock secs (19.80 usr 5.68 sys + 0.00 cusr 0.00 csys = 25.48 CPU) create: Total time: 548 wallclock secs ( 3.35 usr 1.66 sys + 0.00 cusr 0.00 csys = 5.01 CPU) insert: Total time: 531 wallclock secs (155.04 usr 19.15 sys + 0.00 cusr 0.00 csys = 174.19 CPU) select: Total time: 168 wallclock secs (17.93 usr 1.90 sys + 0.00 cusr 0.00 csys = 19.83 CPU) transactions: Test skipped because the database doesn't support transactions wisconsin: Total time: 5 wallclock secs ( 1.31 usr 0.18 sys + 0.00 cusr 0.00 csys = 1.49 CPU) 

यह एक क्लस्टर है:

 alter-table: Total time: 21 wallclock secs ( 0.04 usr 0.05 sys + 0.00 cusr 0.00 csys = 0.09 CPU) ATIS: Total time: 21 wallclock secs ( 2.76 usr 0.30 sys + 0.00 cusr 0.00 csys = 3.06 CPU) big-tables: Total time: 17 wallclock secs ( 1.98 usr 0.40 sys + 0.00 cusr 0.00 csys = 2.38 CPU) connect: Total time: 67 wallclock secs (21.13 usr 5.59 sys + 0.00 cusr 0.00 csys = 26.72 CPU) create: Total time: 597 wallclock secs ( 3.55 usr 1.55 sys + 0.00 cusr 0.00 csys = 5.10 CPU) insert: Total time: 1710 wallclock secs (164.66 usr 35.25 sys + 0.00 cusr 0.00 csys = 199.91 CPU) select: Total time: 187 wallclock secs (19.49 usr 2.44 sys + 0.00 cusr 0.00 csys = 21.93 CPU) transactions: Test skipped because the database doesn't support transactions wisconsin: Total time: 47 wallclock secs ( 1.62 usr 0.88 sys + 0.00 cusr 0.00 csys = 2.50 CPU) 

विस्कॉन्सिन परीक्षण में 3-ऑपरेशन ड्रॉप, और एक गंभीर (अगर महाकाव्य नहीं) ड्रॉप, जहां, सिद्धांत रूप में, पढ़ना और लिखना वैकल्पिक होना चाहिए।
मुझे नहीं पता कि लेन-देन की कसम क्यों खाते हैं वास्तव में, वे काम करते हैं।

एक धारणा थी कि सब कुछ नेटवर्क की गति पर निर्भर करता है, इसलिए मैंने इसे हार्ड ड्राइव के साथ मशीनों (अब समान नहीं) पर परीक्षण किया।

पहला नोड अलग है:

 alter-table: Total time: 55 wallclock secs ( 0.04 usr 0.02 sys + 0.00 cusr 0.00 csys = 0.06 CPU) ATIS: Total time: 10 wallclock secs ( 2.40 usr 0.14 sys + 0.00 cusr 0.00 csys = 2.54 CPU) big-tables: Total time: 7 wallclock secs ( 1.23 usr 0.15 sys + 0.00 cusr 0.00 csys = 1.38 CPU) connect: Total time: 53 wallclock secs (16.31 usr 7.65 sys + 0.00 cusr 0.00 csys = 23.96 CPU) create: Total time: 3215 wallclock secs ( 2.58 usr 0.83 sys + 0.00 cusr 0.00 csys = 3.41 CPU) insert: Total time: 541 wallclock secs (142.41 usr 22.53 sys + 0.00 cusr 0.00 csys = 164.94 CPU) select: Total time: 154 wallclock secs (12.66 usr 1.34 sys + 0.00 cusr 0.00 csys = 14.00 CPU) transactions: Test skipped because the database doesn't support transactions wisconsin: Total time: 4 wallclock secs ( 1.15 usr 0.29 sys + 0.00 cusr 0.00 csys = 1.44 CPU) 

दूसरा नोट अलग है:

 alter-table: Total time: 59 wallclock secs ( 0.03 usr 0.03 sys + 0.00 cusr 0.00 csys = 0.06 CPU) ATIS: Total time: 11 wallclock secs ( 2.35 usr 0.23 sys + 0.00 cusr 0.00 csys = 2.58 CPU) big-tables: Total time: 11 wallclock secs ( 1.92 usr 0.30 sys + 0.00 cusr 0.00 csys = 2.22 CPU) connect: Total time: 64 wallclock secs (19.67 usr 5.84 sys + 0.00 cusr 0.00 csys = 25.51 CPU) create: Total time: 4592 wallclock secs ( 3.90 usr 1.39 sys + 0.00 cusr 0.00 csys = 5.29 CPU) insert: Total time: 581 wallclock secs (148.16 usr 19.80 sys + 0.00 cusr 0.00 csys = 167.96 CPU) select: Total time: 168 wallclock secs (18.45 usr 2.07 sys + 0.00 cusr 0.00 csys = 20.52 CPU) transactions: Test skipped because the database doesn't support transactions wisconsin: Total time: 5 wallclock secs ( 1.18 usr 0.25 sys + 0.00 cusr 0.00 csys = 1.43 CPU) 

समूह

 alter-table: Total time: 110 wallclock secs ( 0.04 usr 0.02 sys + 0.00 cusr 0.00 csys = 0.06 CPU) ATIS: Total time: 496 wallclock secs ( 1.61 usr 0.17 sys + 0.00 cusr 0.00 csys = 1.78 CPU) big-tables: Total time: 116 wallclock secs ( 1.02 usr 0.16 sys + 0.00 cusr 0.00 csys = 1.18 CPU) connect: Total time: 34 wallclock secs (10.98 usr 2.49 sys + 0.00 cusr 0.00 csys = 13.47 CPU) create: Total time: 4638 wallclock secs ( 2.42 usr 0.91 sys + 0.00 cusr 0.00 csys = 3.33 CPU) insert: Estimated total time: 43470.8 wallclock secs (106.50 usr 15.34 sys + 0.00 cusr 0.00 csys = 121.84 CPU) select: Total time: 631 wallclock secs (11.02 usr 1.02 sys + 0.00 cusr 0.00 csys = 12.04 CPU) transactions: Test skipped because the database doesn't support transactions wisconsin: Total time: 1576 wallclock secs ( 1.37 usr 0.44 sys + 0.00 cusr 0.00 csys = 1.81 CPU) 

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

वास्तविक उत्पादन में इसका उपयोग करने के लिए - हर कोई अपने लिए चुनता है। मेरे लिए, प्रदर्शन में इस तरह की एक सापेक्ष कमी छोटे निरपेक्ष संख्याओं के कारण राजनीतिक नहीं है।

संभावित समस्याओं और उन्हें हल करने के तरीके

1।

 WSREP: Process completed with error: wsrep_sst_xtrabackup 'donor' '192.168.1.1:6000/xtrabackup_sst' 'backup:password' '/var/lib/mysql2/' '/etc/mysql/my2.cnf' '9bdd7773-0cb4-11e2-0800-8e876ebc6b70' '0' '0': 22 (Invalid argument) 

xtrabackup डेटाबेस से कनेक्ट नहीं हो सका। क्या आप वाकई एक ही मशीन पर कई नोड्स बनाने की कोशिश नहीं कर रहे हैं? विवरण देखें innobackup.backup.log में।

2।

 121002 15:19:54 mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql0 /usr/bin/mysqld_safe: 172: [: gcomm://: unexpected operator 

बैश के बजाय, एक और दुभाषिया का उपयोग किया जाता है। या तो mysqld_safe में पहली पंक्ति को बदलें, या सिमिलिंक संपादित करें।

3. यदि MyISAM टेबल बनाई गई हैं, लेकिन एक डंप से आबाद नहीं है, तो ऐसा होना चाहिए: केवल InnoDB समर्थित है।

4. यदि सभी कमांड डेटा लिखते या पढ़ते हैं, तो MySQL क्लाइंट एक "अज्ञात कमांड" जारी करता है: यह नोड्स के बीच संबंध टूटने पर स्प्लिट-ब्रेन के खिलाफ सुरक्षा है।