MySQL साठी ऑर्केस्ट्रेटर: आपण त्याशिवाय दोष-सहिष्णु प्रकल्प का तयार करू शकत नाही

कोणताही मोठा प्रकल्प दोन सर्व्हरने सुरू होतो. सुरुवातीला एक डीबी सर्व्हर होता, नंतर वाचन मोजण्यासाठी गुलाम जोडले गेले. आणि मग - थांबा! एक मालक आहे, पण गुलाम पुष्कळ आहेत; जर गुलामांपैकी एक सोडला तर सर्वकाही ठीक होईल, परंतु जर मास्टर सोडला तर ते वाईट होईल: डाउनटाइम, प्रशासक सर्व्हर वाढवण्याचा प्रयत्न करीत आहेत. काय करायचं? एक मास्टर राखून ठेवा. माझा सहकारी पावेलने याबद्दल आधीच लिहिले आहे एक लेख, मी त्याची पुनरावृत्ती करणार नाही. त्याऐवजी, मी तुम्हाला सांगेन की तुम्हाला MySQL साठी ऑर्केस्ट्रेटरची गरज का आहे!

चला मुख्य प्रश्नापासून सुरुवात करूया: "मास्टर निघून गेल्यावर आम्ही कोड नवीन मशीनवर कसा स्विच करू?"

• मला व्हीआयपी (व्हर्च्युअल आयपी) असलेली योजना सर्वात जास्त आवडते, आम्ही त्याबद्दल खाली बोलू. हे सर्वात सोपा आणि सर्वात स्पष्ट आहे, जरी त्याची स्पष्ट मर्यादा आहे: आम्ही आरक्षित करू जो मास्टर नवीन मशीनसह L2 विभागामध्ये असणे आवश्यक आहे, म्हणजेच, आम्ही दुसऱ्या DC बद्दल विसरू शकतो. आणि, सौहार्दपूर्ण मार्गाने, जर तुम्ही नियम पाळलात की मोठा L2 वाईट आहे, कारण L2 फक्त प्रति रॅक आहे आणि L3 रॅकमध्ये आहे आणि अशा योजनेत आणखी निर्बंध आहेत.
• तुम्ही कोडमध्ये DNS नाव लिहू शकता आणि ते /etc/hosts द्वारे सोडवू शकता. प्रत्यक्षात कोणताही ठराव होणार नाही. योजनेचा फायदा: पहिल्या पद्धतीची कोणतीही मर्यादा वैशिष्ट्य नाही, म्हणजेच क्रॉस-डीसी आयोजित करणे शक्य आहे. पण मग स्पष्ट प्रश्न उद्भवतो: आम्ही /etc/hosts ला Puppet-Ansible द्वारे किती लवकर बदल करू शकतो?
• तुम्ही दुसरी पद्धत थोडी बदलू शकता: सर्व वेब सर्व्हरवर कॅशिंग DNS स्थापित करा, ज्याद्वारे कोड मास्टर डेटाबेसवर जाईल. DNS मध्ये या एंट्रीसाठी तुम्ही TTL 60 सेट करू शकता. असे दिसते की योग्यरित्या अंमलात आणल्यास, पद्धत चांगली आहे.
• सेवा शोध असलेली योजना, कन्सुल आणि इ.चा वापर सूचित करते.
• सह एक मनोरंजक पर्याय प्रॉक्सीएसक्यूएल. तुम्हाला सर्व ट्रॅफिक ProxySQL द्वारे MySQL कडे जावे लागेल; ProxySQL स्वतः कोण आहे हे ठरवू शकते. तसे, आपण हे उत्पादन वापरण्याच्या पर्यायांपैकी एकाबद्दल वाचू शकता माझ्या लेख.

ऑर्केस्ट्रेटरच्या लेखकाने, गिथबमध्ये काम करत, प्रथम व्हीआयपीसह पहिली योजना लागू केली आणि नंतर ती कन्सुलसह योजनेत रूपांतरित केली.

ठराविक पायाभूत लेआउट:

मी ताबडतोब स्पष्ट परिस्थितींचे वर्णन करेन ज्या लक्षात घेणे आवश्यक आहे:

• VIP पत्ता कोणत्याही सर्व्हरवरील कॉन्फिगरेशनमध्ये नोंदणीकृत नसावा. चला एका परिस्थितीची कल्पना करूया: मास्टर रीबूट झाला, आणि तो लोड होत असताना, ऑर्केस्ट्रेटर फेलओव्हर मोडमध्ये गेला आणि दासांपैकी एकाला मास्टर बनवले; मग जुना मास्टर उठला आणि आता व्हीआयपी दोन गाड्यांवर आहे. हे वाईट आहे.
• ऑर्केस्ट्रेटरसाठी, तुम्हाला जुन्या मास्टर आणि नवीन मास्टरला कॉल करण्यासाठी स्क्रिप्ट लिहावी लागेल. जुन्या मास्टरवर तुम्हाला ifdown चालवावे लागेल आणि नवीन मास्टरवर - ifup vip. या स्क्रिप्टमध्ये हे देखील समाविष्ट करणे चांगले होईल की फेलओव्हर झाल्यास, कोणत्याही स्प्लिटब्रेन टाळण्यासाठी जुन्या मास्टरच्या स्विचवरील पोर्ट फक्त बंद केले जाते.
• ऑर्केस्ट्रेटरने प्रथम VIP काढून टाकण्यासाठी आणि/किंवा स्विचवरील पोर्ट विझवण्यासाठी तुमच्या स्क्रिप्टला कॉल केल्यानंतर, आणि नंतर नवीन मास्टरवर VIP वाढवणारी स्क्रिप्ट कॉल केल्यानंतर, नवीन VIP आता आहे हे सर्वांना सांगण्यासाठी arping कमांड वापरण्यास विसरू नका. येथे
• सर्व गुलामांकडे फक्त वाचनीय = 1 असणे आवश्यक आहे आणि तुम्ही गुलामाला मालकाकडे प्रमोट करताच, ते फक्त read_only=0 असावे.
• हे विसरू नका की आम्ही यासाठी निवडलेला कोणताही गुलाम मास्टर बनू शकतो (ऑर्केस्ट्रेटरकडे संपूर्ण प्राधान्य यंत्रणा आहे ज्यासाठी प्रथम स्थानावर नवीन मालकासाठी उमेदवार म्हणून कोणता गुलाम विचारात घ्यावा, कोणता दुसऱ्या स्थानावर आणि कोणता गुलाम असावा. कोणत्याही परिस्थितीत मास्टरची निवड केली जाऊ नये). गुलाम मालक झाला तर गुलामाचा भार त्याच्यावर राहील आणि धन्याचा भार जोडला जाईल, हे लक्षात घेतले पाहिजे.

आपल्याकडे ऑर्केस्ट्रेटर नसल्यास आपल्याला ऑर्केस्ट्रेटरची आवश्यकता का आहे?

• ऑर्केस्ट्रेटरकडे अतिशय वापरकर्ता-अनुकूल ग्राफिकल इंटरफेस आहे जो संपूर्ण टोपोलॉजी प्रदर्शित करतो (खाली स्क्रीनशॉट पहा).
• ऑर्केस्ट्रेटर ट्रॅक करू शकतो की कोणते गुलाम मागे आहेत आणि कुठे प्रतिकृती सामान्यपणे खंडित झाली आहे (आमच्याकडे एसएमएस पाठवण्यासाठी ऑर्केस्ट्रेटरशी स्क्रिप्ट संलग्न आहेत).
• ऑर्केस्ट्रेटर तुम्हाला सांगतो की कोणत्या गुलामांमध्ये GTID त्रुटी आहे.

ऑर्केस्ट्रेटर इंटरफेस:

GTID त्रुटी म्हणजे काय?

ऑर्केस्ट्रेटरला काम करण्यासाठी दोन मुख्य आवश्यकता आहेत:

• MySQL क्लस्टरमधील सर्व मशीनवर स्यूडो GTID सक्षम करणे आवश्यक आहे; आम्ही GTID सक्षम केले आहे.
• सर्वत्र एक प्रकारचे बिनलॉग असणे आवश्यक आहे, तुम्ही स्टेटमेंट वापरू शकता. आमच्याकडे एक कॉन्फिगरेशन होते ज्यामध्ये मास्टर आणि बहुतेक गुलामांची पंक्ती होती आणि दोन ऐतिहासिकदृष्ट्या मिश्रित मोडमध्ये राहिले. परिणामी, ऑर्केस्ट्रेटरला या गुलामांना नवीन मालकाशी जोडायचे नव्हते.

लक्षात ठेवा की प्रॉडक्शन स्लेव्हमध्ये सर्वात महत्वाची गोष्ट म्हणजे मास्टरशी सुसंगतता! तुमचा मालक आणि गुलाम या दोघांवर तुम्ही ग्लोबल ट्रान्झॅक्शन आयडी (GTID) सक्षम केला असल्यास, तुम्ही या मशीनवर डेटा बदलांच्या समान विनंत्या प्रत्यक्षात केल्या आहेत की नाही हे शोधण्यासाठी gtid_subset फंक्शन वापरू शकता. आपण याबद्दल अधिक वाचू शकता येथे.

अशा प्रकारे, ऑर्केस्ट्रेटर तुम्हाला जीटीआयडी त्रुटीद्वारे दाखवतो की गुलामावर असे व्यवहार आहेत जे मास्टरवर नाहीत. असे का होत आहे?

• Read_only=1 स्लेव्हवर सक्षम नाही, कोणीतरी कनेक्ट केला आहे आणि डेटा बदलण्याची विनंती पूर्ण केली आहे.
• Super_read_only=1 स्लेव्हवर सक्षम नाही, नंतर प्रशासकाने, सर्व्हरला गोंधळात टाकून, तेथे जाऊन विनंती कार्यान्वित केली.
• तुम्ही मागील दोन्ही मुद्दे विचारात घेतल्यास, आणखी एक युक्ती आहे: MySQL मध्ये, बिनलॉग फ्लश करण्याची विनंती देखील बिनलॉगकडे जाते, म्हणून पहिल्या फ्लशवर, मास्टर आणि सर्व गुलामांवर एक GTID त्रुटी दिसून येईल. हे कसे टाळायचे? पेरोना-5.7.25-28 ने binlog_skip_flush_commands=1 सेटिंग सादर केली, जे binlogs वर फ्लश लिहिण्यास प्रतिबंधित करते. mysql.com वेबसाइटवर एक स्थापित आहे किडा.

मी वरील सर्व गोष्टींचा सारांश देतो. तुम्हाला अद्याप फेलओव्हर मोडमध्ये ऑर्केस्ट्रेटर वापरायचा नसेल, तर ते निरीक्षण मोडमध्ये ठेवा. मग तुमच्या डोळ्यांसमोर नेहमी MySQL मशीन्सच्या परस्परसंवादाचा नकाशा असेल आणि प्रत्येक मशीनवर कोणत्या प्रकारची प्रतिकृती आहे, गुलाम मागे आहेत की नाही आणि सर्वात महत्त्वाचे म्हणजे ते मास्टरशी किती सुसंगत आहेत याची दृश्य माहिती असेल!

स्पष्ट प्रश्न आहे: "ऑर्केस्ट्रेटरने कसे कार्य करावे?" त्याने सध्याच्या गुलामांमधून नवीन मास्टर निवडणे आवश्यक आहे, आणि नंतर सर्व गुलामांना पुन्हा जोडणे आवश्यक आहे (यासाठी जीटीआयडी आवश्यक आहे; जर तुम्ही binlog_name आणि binlog_pos सह जुनी यंत्रणा वापरत असाल, तर गुलामाला सध्याच्या मालकाकडून नवीनवर स्विच करणे आवश्यक आहे. फक्त अशक्य आहे!). आमच्याकडे ऑर्केस्ट्रेटर असण्याआधी, मला एकदा हे सर्व हाताने करावे लागले. बग्गी अॅडाप्टेक कंट्रोलरमुळे जुना मास्टर लटकला होता; त्यात सुमारे 10 गुलाम होते. मला मास्टरकडून एका गुलामाकडे व्हीआयपी हस्तांतरित करणे आणि इतर सर्व गुलामांना पुन्हा जोडणे आवश्यक आहे. मला किती कन्सोल उघडावे लागले, मी एकाच वेळी किती आज्ञा दिल्या... मला पहाटे 3 वाजेपर्यंत थांबावे लागले, दोन वगळता सर्व गुलामांवरील भार काढून टाका, दोन मास्टरमधून पहिले मशीन बनवा, लगेच दुसरे मशीन संलग्न करा त्यावर, म्हणून इतर सर्व गुलामांना नवीन मालकाशी जोडा आणि भार परत करा. एकूणच, भयानक...

ऑर्केस्ट्रेटर फेलओव्हर मोडमध्ये जातो तेव्हा कसे कार्य करते? हे अशा परिस्थितीच्या उदाहरणाद्वारे अगदी सहजपणे स्पष्ट केले जाते जेथे आपण मास्टरला आपल्यापेक्षा अधिक शक्तिशाली, अधिक आधुनिक मशीन बनवू इच्छितो.

आकृती प्रक्रियेच्या मध्यभागी दर्शवते. या बिंदूपर्यंत आधीच काय केले गेले आहे? आम्‍ही म्‍हटले की आम्‍हाला काही गुलाम नवीन मास्‍टर बनवायचे आहे, ऑर्केस्ट्रेटरने इतर सर्व गुलामांना सहज जोडण्‍यास सुरुवात केली, नवीन मास्‍टर ट्रान्झिट मशीन म्‍हणून काम करत आहे. या योजनेसह, कोणत्याही त्रुटी उद्भवत नाहीत, सर्व गुलाम काम करतात, ऑर्केस्ट्रेटर जुन्या मास्टरकडून व्हीआयपी काढून टाकतो, ते नवीनकडे हस्तांतरित करतो, फक्त read_only=0 बनवतो आणि जुन्या मास्टरबद्दल विसरतो. सर्व! आमच्या सेवेचा डाउनटाइम व्हीआयपी हस्तांतरण वेळ आहे, जो 2-3 सेकंद आहे.

आजसाठी एवढेच, सर्वांचे आभार. ऑर्केस्ट्रेटरबद्दल लवकरच दुसरा लेख येईल. "गॅरेज" या प्रसिद्ध सोव्हिएत चित्रपटात, एका पात्राने म्हटले, "मी त्याच्याबरोबर शोध घेणार नाही!" तर, ऑर्केस्ट्रेटर, मी तुमच्यासोबत जाईन!

स्त्रोत: www.habr.com