मैं लोड-संतुलित MySQL क्लस्टर बनाने के लिए देख रहा हूं, लेकिन वास्तविक लोड-बैलेंसर के बिना, विफलता या जटिलता के किसी अन्य बिंदु को जोड़ने के लिए नहीं।
जो मैं सोच रहा था वह निम्नलिखित था:
MySQL के लिए एक मास्टर-मास्टर सेटअप है
प्रत्येक क्लाइंट पर, एक साधारण राउंड-रॉबिन प्रॉक्सी रखें जो सर्वरों के बीच अनुरोधों को घुमाएंगे।
क्या यह संभव है? या इसे प्राप्त करने के बेहतर तरीके हैं?
जवाबों:
कृपया वास्तव में किसी भी प्रकार की MySQL प्रॉक्सी उपयोग करने से पहले इस सवाल का मेरे अन्य जवाब पढ़ें। यदि आपके पास 2 मास्टर-मास्टर सर्वर हैं, जो एक सीएमएस लिख रहा है, और 10 httpd जो केवल इसे पढ़ता है, तो आप ठीक हो जाएंगे, लेकिन (जैसा कि दूसरे उत्तर में बताया गया है) हमेशा ऐसा नहीं होता है। आपको चेतावनी दी गई थी।
MySQL प्रॉक्सी एक सरल प्रोग्राम है जो आपके क्लाइंट और MySQL सर्वर (एस) के बीच बैठता है जो उनके संचार की निगरानी, विश्लेषण या रूपांतरण कर सकता है। इसका लचीलापन असीमित उपयोग की अनुमति देता है; आम लोगों में शामिल हैं: लोड संतुलन; विफलता; क्वेरी विश्लेषण; क्वेरी फ़िल्टरिंग और संशोधन; और बहुत सारे।
।
HAProxy एक मुफ़्त, बहुत तेज़ और विश्वसनीय समाधान है जो उच्च उपलब्धता, लोड संतुलन, और टीसीपी और HTTP- आधारित अनुप्रयोगों के लिए प्रॉक्सी की पेशकश कर रहा है
यदि आप इसे TCP मोड में चलाते हैं, तो यह Wackamole से भी बेहतर हो सकता है। अगर मुझे उनके बीच चयन करना होता, तो मैं HAProxy का उपयोग करता। इसके अलावा HAProxy में बहुत सारे बैकएंड हो सकते हैं, Waclamole में केवल 2 हो सकते हैं। ध्यान दें कि HAProxy "डंबल" है, यह बिना किसी को देखे बिना सॉकेट को जोड़ता है कि स्ट्रीम के अंदर क्या है - समर्पित MySQL प्रॉक्सी में निर्दिष्ट सर्वर के लिए विभिन्न अनुरोधों को इंगित करने का विकल्प हो सकता है ।
शायद ध्यान देने योग्य बात है, एक सच्चे मल्टी-मास्टर MySQL सेटअप के लिए MySQL के लिए गैलेरा प्रतिकृति। गैलेरा एक तुल्यकालिक प्रतिकृति प्रोटोकॉल है, इसलिए एप्लिकेशन किसी भी MySQL सर्वर से पढ़ और लिख सकते हैं। यहाँ एक त्वरित ट्यूटोरियल है: http://www.severalnines.com/clustercontrol-mysql-galera-tutorial
MySQL सर्वर के सामने लोड बैलेन्सर के लिए, या तो इस कार्यक्षमता का समर्थन करने वाले MySQL कनेक्टर का उपयोग करें (जैसे Java के लिए कनेक्टर / J, या php के लिए Mysqlnd)
यदि आपके पास कोई कनेक्टर नहीं है जो ऐसा कर सकता है, तो HA प्रॉक्सी की तरह कुछ का उपयोग करें। यह स्क्रिप्ट स्वचालित रूप से HA प्रॉक्सी को सेट करती है और अच्छे MySQL सर्वर की सूची को बनाए रखती है: https://github.com/severalnines/proxy
सादर,
विनय
www.severalnines.com
मास्टर-मास्टर प्रतिकृति उतनी अच्छी नहीं है जितना आप सोच सकते हैं, वही गोल-रॉबिन प्रॉक्सी और इसी तरह के 'आसान' समाधानों के लिए जाता है। यदि आप डेटा को बहुत तेजी से अलग करने के लिए टकराने का अपराध करते हैं (सर्वर के बीच देरी की तुलना में तेजी से, जो उत्पादन सर्वरों पर पूर्ण सेकंड तक हो सकता है *), दोनों डेटा स्वीकार करेंगे। यदि आपके पास एक नीलामी सर्वर है, तो आपने एक ही कार को दो बार बेचा । इसे किसने खरीदा? यह निर्भर करता है कि आप किस डीबी से पूछेंगे!
आवेदन के बारे में पता होना चाहिए कि वहाँ वास्तव में 2 डेटाबेस हैं और यह उनके दोनों आईपी पते को जानना है। यदि आप "बेचना" चाहते हैं, तो आपको फ़े होना चाहिए
DB_number = `auction_number` % `number_of_databases`( %के लिए है modulo)
... और इसे DB_number डेटाबेस में करें। यदि आपको एक कनेक्शन त्रुटि मिलती है, तो शायद इसे दूसरे के साथ करें (लेकिन नीलामी सर्वर के मामले में, मैं सिर्फ एक त्रुटि प्रदर्शित करूंगा)।
इसके अलावा, आईपी पते दोनों सर्वरों के बीच wamamole -d होना चाहिए । एक आपदा परिदृश्य पर, जहां एक डेटाबेस सर्वर पीक उपयोग समय में कुछ घंटों के लिए नीचे चला जाता है, आप पाएंगे कि एप्लिकेशन अनुपस्थित सर्वर से कनेक्ट करने और टाइमटाइम तक कहने के लिए, 3s लटकाए जाने का प्रयास करेगा। आपके प्रश्नों का लगभग आधा भाग 3s लंबे समय तक चलता है (और वे सभी अंततः एक ही डेटाबेस में जाते हैं - जो इसे आपदा से पहले तेजी से नहीं चलाता है)। यह आपके httpd को खुश नहीं करता है, क्योंकि इसमें संभवतः समवर्ती अनुरोध हैंडलर थ्रेड्स का एक सीमित कनेक्शन पूल है ...
* उत्पादन सर्वर पर प्रतिकृति विलंब पूरे एक सेकंड तक हो सकता है - मैंने इसे एक दूरस्थ कॉलोकेशन में और हमारे डेटासेंटर में परीक्षण किया है और 99% समय के लिए यह 0 है, लेकिन कभी-कभी mysql 1s दिखाता है। बड़े पैमाने पर ट्रैफ़िक के कारण, क्लाइंट एप्लिकेशन के दो अनुरोध करने, दो प्रश्नों, डालने और चयन करने के कारण मेरे पास कई टकराव थे। कुछ मामलों के लिए, पंक्ति अभी तक वहाँ नहीं थी , इसलिए हमने यूज़रआईडी का हैश उपयोग किया और इसने समस्या को ठीक कर दिया
मुझे आशा है कि आप मेरी गलतियों से सीखेंगे ;-)
एक लोड-संतुलित MySQL (या कुछ अन्य) डेटाबेस क्लस्टर बहुत व्यर्थ है। यदि आप एक से अधिक सर्वर पर लिख रहे हैं, तो आप परेशानी में पड़ जाएंगे, या आप सिंक्रोनस प्रतिकृति (जो MySQL वैसे भी समर्थन नहीं करता है) का उपयोग करते हैं, और यह प्रदर्शन को बुरी तरह से चोट पहुँचाता है क्योंकि इसे ताले को सिंक्रनाइज़ करने की आवश्यकता होती है।
मैं आपको लोड पढ़ने / लिखने को विभाजित करने की सलाह देता हूं, और mysql दासों के बीच रीड्स को संतुलित करता हूं, और लिखने के लिए या तो एक ही मास्टर होता है, या अपने मास्टर के लिए एक सक्रिय / निष्क्रिय विफलता जोड़ी का उपयोग करता है।
अनिवार्य रूप से, आप डेटाबेस में अधिक सर्वरों को दास के रूप में लिखकर स्केल नहीं कर सकते हैं, क्योंकि प्रत्येक को अभी भी आपके एप्लिकेशन का संपूर्ण राइट-लोड लिखना है।
लिखने के लिए आपको अपने डेटा को तार्किक रूप से कई सर्वरों में विभाजित करके, विभाजन या "शार्डिंग" आदि द्वारा विभाजित करने की आवश्यकता होती है। इसके लिए आमतौर पर आपके एप्लिकेशन में परिवर्तन के लिए nontrivial (परीक्षण करने में बहुत मुश्किल लगता है) की आवश्यकता होती है, इसलिए आप ऐसा तब तक नहीं करना चाहते जब तक आप वास्तव में ऐसा न कर लें। जरूरत है।
यदि आप वास्तव में चाहते हैं, तो आप निश्चित रूप से MySQL क्लस्टर का उपयोग कर सकते हैं, लेकिन यह अपनी विशेषताओं और कमियों के साथ एक पूरी तरह से अलग इंजन है - इसे स्थापित करने के लिए थोड़ा जटिल है, लेकिन कमोडिटी हार्डवेयर पर एचए लोड-संतुलित डेटाबेस प्रदान करता है। यह अभी भी सिंक्रोनस प्रतिकृति का उपयोग करने से लिखने के दंड से ग्रस्त है, लेकिन आपको लिखने की अनुमति देता है क्योंकि यह सर्वरों के विभाजन में बनाया गया है।
इस विषय पर एक और महान मार्गदर्शक मैंने पाया है ...
http://www.dancryer.com/2010/01/mysql-circular-replication
यह तीन पदों की श्रृंखला का एक भाग है:
MySQL लोड-बैलेंस्ड क्लस्टर गाइड - भाग 1 - स्वयं सर्वर सेट करना और MySQL प्रतिकृति को कॉन्फ़िगर करना।
MySQL लोड-बैलेंस्ड क्लस्टर गाइड - पार्ट 2 - आपके MySQL क्लस्टर नोड्स की स्थिति की निगरानी के लिए एक स्क्रिप्ट सेट करता है, जिसे हम अपने प्रॉक्सी को सेट करने के लिए अगले गाइड में उपयोग करेंगे।
MySQL लोड-बैलेंस्ड क्लस्टर गाइड - भाग 3 - निगरानी स्क्रिप्ट का उपयोग करके, HAProxy के साथ लोड बैलेंसर स्थापित करना
व्यक्तिगत रूप से, बेहतर तरीका एक लोड बैलेंसर का उपयोग करना होगा!
हां, यह विफलता का एक और बिंदु जोड़ देता है, लेकिन कोई भी दिनचर्या जो आप डालते हैं, या हर ग्राहक पर स्थापित करते हैं, एक मानक लोड बैलेंसर की तुलना में बहुत अधिक जटिलता जोड़ता है ...।
कनेक्टर / J में कई सर्वरों में लोडबल प्रश्नों की क्षमता है। यह मुख्य रूप से MySQL NDB क्लस्टर के लिए अभिप्रेत है जहां सभी SQL नोड्स में डेटा का एक सुसंगत दृश्य होगा लेकिन यदि आप यह सुनिश्चित कर सकते हैं कि दो मास्टर्स डेटाबेस इन दो मास्टर्स के बीच यथोचित सुसंगत होगा तो यह आपके एप्लिकेशन के लिए सुरक्षित हो सकता है।
कनेक्ट स्ट्रिंग कुछ इस तरह दिखाई देगी:
jdbc: mysql: loadbalance: // host-1, host-2, ... host-n / dbname? loadBalanceStrategy = "random" और loadBalanceBlacklistTimeoutout - 5000
बंटवारे लिखने से सर्वरों का भार नहीं होगा क्योंकि राइट्स को अभी भी दोहराया जाना चाहिए।
यदि आपका उपयोग केवल 2 सर्वर ड्रब के साथ दिल की धड़कन का उपयोग करते हैं और ड्रब प्रतिकृति को संभालते हैं। अगर पहला सर्वर फेल हो जाता है तो दूसरा सर्वर टेक ओवर करेगा। यदि आप उपयोग करने के लिए दूसरा सर्वर लगाना चाहते हैं, तो आप drbd पर gfs का उपयोग कर सकते हैं और फिर दूसरे सर्वर को केवल पढ़ने के लिए चला सकते हैं और इसे पढ़ने वाले सर्वर के रूप में उपयोग कर सकते हैं। जब फेलओवर होता है तो सर्वर को पढ़ने / लिखने के लिए बदलें।
पुन: wackamole - wackamole 2 सर्वरों तक सीमित नहीं है
मैं इसे कवर करने वाली एक ट्यूटोरियल श्रृंखला पर काम कर रहा हूं, लेकिन यह सेटअप करने के लिए वास्तव में सरल है।
इस सवाल का अधिक हालिया जवाब देने के लिए, MySQL के संस्करण 5.6 के साथ, इसने GTID (ग्लोबल ट्रांजेक्शन आइडेंटिफायर) को पेश किया, जिसका उद्देश्य एसिंक्रोनस प्रतिकृति को और अधिक मजबूत बनाना और MySQL को HA (उच्च उपलब्धता) की दौड़ में फिर से लाना है।
यह खंड वैश्विक लेन-देन पहचानकर्ताओं (GTID) का उपयोग करके लेनदेन-आधारित प्रतिकृति की व्याख्या करता है। जीटीआईडी का उपयोग करते समय, प्रत्येक लेनदेन को पहचाना और ट्रैक किया जा सकता है क्योंकि यह मूल सर्वर पर प्रतिबद्ध है और किसी भी दास द्वारा लागू किया जाता है; इसका मतलब यह है कि जब एक नया दास शुरू करना या किसी नए मास्टर को विफल करना, जो इन कार्यों को बहुत सरल करता है, तो जीटीआईडी का उपयोग करना आवश्यक नहीं है। क्योंकि जीटीआईडी-आधारित प्रतिकृति पूरी तरह से लेन-देन-आधारित है, इसलिए यह निर्धारित करना सरल है कि स्वामी और दास संगत हैं; जब तक एक मास्टर पर किए गए सभी लेनदेन भी एक दास पर प्रतिबद्ध होते हैं, तब तक दोनों के बीच स्थिरता की गारंटी होती है। आप GTIDs के साथ कथन-आधारित या पंक्ति-आधारित प्रतिकृति का उपयोग कर सकते हैं (धारा 16.2.1, "प्रतिकृति प्रारूप" देखें); हालांकि, सर्वोत्तम परिणामों के लिए,
संदर्भ: 16.1.3 वैश्विक लेनदेन पहचानकर्ताओं (MySQL प्रलेखन) के साथ प्रतिकृति
मैंने सोचा था कि लोडप्रभावात्मक प्रश्नों के लिए HAProxy का उपयोग एक SPOF (असफलता का एक बिंदु) पेश कर रहा है, और दिल की धड़कन को जोड़कर इस समाधान को बोझिल बना देता है।
एक और अधिक सरल समाधान जावा कनेक्टर JConnector के माध्यम से कनेक्ट करना है जिसका उद्देश्य सभी MySQL नोड्स के साथ एक jdbc url के माध्यम से शेष प्रश्नों को लोड करना है। यह मास्टर / दास या मास्टर / मास्टर सेटअप को संभाल सकता है ।
यह MySQL के साथ बॉक्स से बाहर एक HA क्लस्टर समाधान सेटअप करने के लिए संभव बनाता है।