👖 😮 👨‍👦‍👦 एक MySQL डेटाबेस से एक एप्लिकेशन को libslave प्रतिकृति क्लाइंट का उपयोग करके वितरित करना 🍖 🦎 🚯

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

Mail.Ru लक्ष्य, साथ ही साथ किसी भी विज्ञापन प्रणाली के लिए, निम्न कारणों से परिवर्तनों की त्वरित ट्रैकिंग महत्वपूर्ण है:
• अभियान का प्रदर्शन जल्दी से बंद करने की क्षमता अगर विज्ञापनदाता ने इसे इंटरफ़ेस में बंद कर दिया या यदि वह पैसे से बाहर भाग गया, जिसका अर्थ है कि हम इसे मुफ्त में नहीं दिखाएंगे;
• विज्ञापनदाता के लिए सुविधा: वह इंटरफ़ेस में बैनर की कीमत को बदल सकता है, और कुछ सेकंड के बाद उसके बैनर एक नई कीमत पर दिखाई देने लगेंगे;
• बदलती परिस्थितियों के लिए त्वरित प्रतिक्रिया: CTR में परिवर्तन, गणितीय मॉडल के प्रशिक्षण के लिए नए डेटा का आगमन। यह सब आपको विज्ञापन प्रदर्शन रणनीति को समायोजित करने की अनुमति देता है, बाहरी कारकों के प्रति संवेदनशील रूप से प्रतिक्रिया करता है।

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

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

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

यह लेख इस बारे में होगा कि हम अपने उद्देश्यों के लिए लिब्स्लेव का उपयोग कैसे करते हैं। मैं संक्षेप में आपको बताऊंगा कि MySQL डेटा प्रतिकृति कैसे काम करती है (मुझे लगता है कि हर कोई इसे अच्छी तरह से कल्पना करता है, लेकिन फिर भी), लिबस्लेव खुद कैसे काम करता है, इसका उपयोग कैसे करें, मैं बेंचमार्क के परिणाम और मौजूदा कार्यान्वयन के कुछ तुलनात्मक विश्लेषण प्रस्तुत करूंगा।

प्रतिकृति डिवाइस

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

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

प्रतिकृति के दो तरीके हैं - STATEMENT और ROW। पहले मोड में, विज़ार्ड प्रारंभिक प्रश्नों को लिखता है जो उसने डेटा (UPDATE / INSERT / DELETE / ALTER TABLE / ...) को संशोधित करने के लिए किया था। गुलाम पर, इन सभी अनुरोधों को उसी तरह से निष्पादित किया जाता है जैसे वे मास्टर पर निष्पादित होंगे।

ROW मोड में, MySQL संस्करण 5.1 के साथ उपलब्ध है, बिनलॉग के लिए अनुरोध नहीं लिखे गए हैं, लेकिन इन अनुरोधों द्वारा पहले से ही संशोधित डेटा (हालांकि, अनुरोध जो डेटा योजनाओं को बदलते हैं (DDL) अभी भी लिखे गए हैं जैसा कि वे हैं)। ROW मोड में एक घटना है:
• डेटा की एक पंक्ति - INSERT और DELETE कमांड के लिए। तदनुसार, INSERT के लिए, सम्मिलित पंक्ति लिखी गई है, DELETE के लिए, हटा दी गई पंक्ति
• दो लाइनें - पहले और बाद में - अद्यतन के लिए।

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

वैसे, आपके सबसे महत्वपूर्ण मास्टर सर्वर पर ROW प्रतिकृति को सक्षम करने के लिए आवश्यक नहीं है। मास्टर सर्वर सामान्य स्थिति प्रतिकृति (भंडार, बैकअप) के अनुसार कई दासों को खिला सकता है, और इनमें से कुछ दास आरओडब्ल्यू लॉग लिख सकते हैं, और वे पहले से ही डेमॉन डेटा के लिए उन्हें एक्सेस कर रहे हैं।

यह हमारे लिए कैसे काम करता है?

डेटाबेस से डेटा प्राप्त करना दो चरणों में होता है:
डेमॉन शुरू में 1. प्रारंभिक डेटा लोड हो रहा है
2. अद्यतन प्राप्त करें

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

डेटा को चुना जाना चाहिए ताकि वे मेमोरी में सुसंगत हों। ऐसा करने के लिए, आप एक लेनदेन में सभी तालिकाओं से डेटा का चयन कर सकते हैं। लेकिन उसके बाद, हमें libslave अपडेट पढ़ना शुरू करना होगा और यह तय करना होगा कि हम किस स्थिति से पढ़ेंगे। चयनों के बाद वर्तमान स्थिति लेना असंभव है, क्योंकि चयनों के दौरान डेटाबेस में नए डेटा को लिखा जा सकता है जो चयनों में प्रवेश नहीं करते थे, लेकिन बिनलॉग स्थिति को स्थानांतरित कर दिया गया था। चयनों की शुरुआत से पहले एक स्थिति लेना भी असंभव है, क्योंकि जिस समय से हम वर्तमान स्थिति को सीलेक-टियोन की शुरुआत में लेते हैं, नया डेटा आ सकता है। फिर से, BEGIN कमांड के साथ लेन-देन शुरू करना, और फिर वर्तमान बिनलॉग स्थिति प्राप्त करना, काम नहीं करेगा - उनके बीच कोई सिंक्रनाइज़ेशन नहीं है, और यदि एक क्लाइंट ने BEGIN बनाया है, तो अन्य ग्राहक इस समय डेटा लिख सकते हैं, और बिनलॉग स्थिति, क्रमशः स्थानांतरित कर सकते हैं। ।

ये सभी विचार हमें इस विचार की ओर ले जाते हैं कि पठन की स्थिरता सुनिश्चित करना आंशिक रूप से दानव का कार्य होगा। हमारी मेमोरी में डेटा को व्यवस्थित किया जाता है ताकि अगर कोई असंगत वस्तु हमारे पास आए (इस अर्थ में कि हम इसकी असंगतता का पता लगा सकें - उदाहरण के लिए, इसमें आवश्यक कनेक्शन का अभाव है), तो यह बस दानव की स्मृति से मिट जाएगा; हालाँकि, यदि बाद में यह लगातार आता है, तो इसे मेमोरी में डाला जाएगा। अगर वह दो बार लगातार आता है, तो उसकी याद में उसकी आखिरी स्थिति बनी रहेगी। यदि यह मेमोरी में सुसंगत था, और यह गैर-सुसंगत है, तो हम एक गैर-सुसंगत स्थिति लागू नहीं करेंगे, और दानव की मेमोरी में ऑब्जेक्ट नहीं बदलेगा।

इन सभी के आधार पर, हमारे दृष्टिकोण से सही, बूटस्ट्रैप मॉडल इस तरह दिखता है:
1. हमें पी 1 मास्टर पर वर्तमान बिनलॉग स्थिति मिलती है - हम समय पर एक मनमाना बिंदु पर ऐसा करते हैं।
2. हम सभी चयन करते हैं।
3. पी 2 मास्टर पर नए वर्तमान बिनलॉग स्थिति प्राप्त करें।
4. libslave का उपयोग करके, हमने p1 और P2 के बीच की सभी घटनाओं को पढ़ा। उसी समय, चयन के दौरान बनाई गई दोनों नई वस्तुएं और पुराने पुराने जो पहले से ही मौजूद हैं, स्मृति में आ सकते हैं।
5. उसके बाद, डेमन के पास डेटा की एक सुसंगत प्रति है, डेमन काम करने के लिए तैयार है - हम अनुरोधों का जवाब दे सकते हैं और स्थिति पी 2 से शुरू होने वाले लिब्स्लेव का उपयोग करके अपडेट प्राप्त कर सकते हैं।

मैं इस बात पर जोर देता हूं कि चूंकि डेटा की स्थिरता डेमॉन में बनी हुई है, इसलिए हमें एक लेनदेन में चरण 2 में चयन करने की आवश्यकता नहीं है। उदाहरण के लिए, घटनाओं का ऐसा जटिल क्रम:
1. वर्तमान बिनलॉग स्थिति प्राप्त करें।
2. हमने अभियान तालिका पढ़ना शुरू किया, जिसमें अभियान अभियान 1 है।
3. मौजूदा अभियान 1 अभियान में राज्य 1 में एक नया बैनर बैनर 1 बनाया गया था।
4. एक नया अभियान 2 अभियान बनाया गया जो चयन के परिणाम में नहीं आता है।
5. एक नया बैनर 2 बैनर बनाया गया है, जो अभियान 2 अभियान से जुड़ा है।
6. बैनर 1 राज्य 2 में परिवर्तित हुआ।
7. हमने अभियान तालिका पढ़ना, बैनर तालिका पढ़ने के लिए स्विच किया, और राज्य 2 में बैनर 1 और बैनर 2 इस पढ़ने में मिल जाएगा।
8. बैनर तालिका पढ़ें।
9. अभियान 2 अभियान में एक नया बैनर 3 बैनर बनाया गया है।
10. नई बिनलॉग की नई वर्तमान स्थिति प्राप्त की।

और अब देखते हैं कि दानव में क्या होता है:
1. दानव सभी अभियानों का चयन करता है और उन्हें मेमोरी में संग्रहीत करता है (शायद कुछ मानदंडों की जांच करके - शायद हमें स्मृति में सभी अभियानों की आवश्यकता नहीं है)।
2. दानव बैनर चयन के लिए बंद कर दिया। वह राज्य 2 में बैनर 1 को तुरंत पढ़ेंगे और इसे याद रखेंगे, इसे पहले से पढ़े गए अभियान 1 अभियान से जोड़ेंगे।
3. वह बैनर 2 पढ़ेगा और उसे फेंक देगा, क्योंकि उसकी याद में उसके लिए कोई अभियान 2 अभियान नहीं है - वह चयन परिणामों में नहीं आया।
4. चयन समाप्त हो गया है। हम स्थिति p1 से स्थिति P2 में परिवर्तन पढ़ने के लिए आगे बढ़ते हैं।
5. हम राज्य में बैनर 1 बैनर के निर्माण से मिलते हैं। मैं आपको याद दिला दूं कि यह पहले से ही डेमॉन की याद में अपने अंतिम 2 राज्य में है, लेकिन, हालांकि, हम इस अपडेट को लागू करेंगे और बैनर को राज्य 1 में डालेंगे - यह डरावना नहीं है, क्योंकि डेटा जब हम स्थिति P2 में पढ़ते हैं, तब ही काम के लिए उपयोग किया जाएगा, और इस स्थिति से पहले हम इस बैनर में फिर से बदलाव प्राप्त करेंगे।
6. नए अभियान 2 अभियान का निर्माण पढ़ें - इसे याद रखें।
7. हमने इसके साथ लगे बैनर 2 बैनर के निर्माण को पढ़ा - अब हम इसे याद रखेंगे, क्योंकि इसके लिए एक संबंधित अभियान है, और डेटा सुसंगत है।
8. हम बैनर 1 से राज्य 2 के अनुवाद को पढ़ते हैं - लागू किया जाता है, अब और यहां यह सुसंगत है।
9. हमने अभियान 2 अभियान में बैनर 3 के निर्माण को पढ़ा - स्मृति में डाला गया।
10. हम स्थिति पी 2 तक पहुंच गए, बंद कर दिया - सभी डेटा लगातार लोड किया जाता है, हम इसे उपयोगकर्ता को दे सकते हैं और अपडेट को सामान्य मोड में आगे पढ़ सकते हैं।

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

कोड कुछ इस तरह दिखता है:

slave::MasterInfo sMasterInfo; //      Slave sSlave(sMasterInfo); //      //     const slave::Slave::binlog_pos_t sInitialBinlogPos = sSlave.getLastBinlog(); select(); //     //      —     const slave::Slave::binlog_pos_t sCurBinlogPos = sSlave.getLastBinlog(); //           init_slave(); //     ,  Slave::init  Slave::createDatabaseStructure sMasterInfo.master_log_name = sInitialBinlogPos.first; sMasterInfo.master_log_pos = sInitialBinlogPos.second; sSlave.setMasterInfo(sMasterInfo); sSlave.get_remote_binlog(CheckBinlogPos(sSlave, sCurBinlogPos));

CheckBinlogPos functor पठन डेटा को बनलॉग से पूरा करने का कारण बनेगा जब वह स्थिति sCurBinlogos पर पहुँचता है। इसके बाद, उपयोग के लिए डेटा की प्रारंभिक तैयारी होती है और अंतिम स्थिति से दास से डेटा की रीडिंग किसी भी कार्यात्मक के बिना शुरू होती है।

लिब्स्लेव डिवाइस

आइए एक नज़र डालते हैं कि libslave क्या है। मेरा वर्णन सबसे लोकप्रिय कार्यान्वयन पर आधारित है । नीचे मैं कई कांटे और पूरी तरह से अलग कार्यान्वयन की तुलना करूंगा।

लिब्स्लेव एक C ++ लाइब्रेरी है जिसका उपयोग MySQL से अपडेट प्राप्त करने के लिए आपके एप्लिकेशन में किया जा सकता है। Libslave MySQL सर्वर के साथ कोड स्तर पर जुड़ा नहीं है; इसे एकत्र किया जाता है और केवल ग्राहक के साथ जोड़ा जाता है - libmysqlclient। पुस्तकालय का संस्करण 5.1.23 से 5.5.34 तक जादूगरों पर परीक्षण किया गया था (बिल्कुल नहीं! केवल वे जो हाथ आए थे)।

काम करने के लिए, हमें ROW मोड में बिनलॉग की सक्षम रिकॉर्डिंग के साथ एक MySQL सर्वर की आवश्यकता होती है। ऐसा करने के लिए, यह विन्यास में निम्नलिखित पंक्तियाँ होनी चाहिए:

 [mysqld] log-bin = mysqld-bin server-id = 1 binlog-format = ROW

जिस यूजर के तहत लिब्स्लेव जाएगा, उसे रिप्लेसमेंट स्लेव और रिप्लाई क्लीएंट एक्सेस राइट्स की जरूरत होगी, साथ ही उन टेबल पर सेलेक्ट करें जिन्हें वह प्रोसेस करेगा (वे जो बिनॉगल्स में होंगे, लेकिन जिसे वह छोड़ देगा, सिलेक्ट की जरूरत नहीं है)। तालिका स्कीमा प्राप्त करने के लिए सही अधिकार की आवश्यकता होती है।

Libslave में एक बिल्ट-इन माइक्रो-क्लासिक नैनोमाइसकल :: सर्वर पर नियमित एसक्यूएल प्रश्नों को निष्पादित करने के लिए कनेक्शन है। जीवन में, हम इसे केवल लिब्स्लेव के हिस्से के रूप में नहीं, बल्कि सामान्य रूप से MySQL के लिए एक ग्राहक के रूप में उपयोग करते हैं (मैं mysqlpp, mysql-कनेक्टर, और अन्य चीजों का उपयोग नहीं करना चाहता था)।

मुख्य वर्ग को दास कहा जाता है। काम शुरू करने से पहले, हम तालिकाओं से घटनाओं के लिए कस्टम कॉलबैक सेट करते हैं, जिसका हम पालन करेंगे। रिकॉर्डसेट संरचना में घटना के बारे में जानकारी कॉलबैक को प्रेषित की जाती है: इसका प्रकार (लिखें / अद्यतन / हटाएं) और डेटा (सम्मिलित / अद्यतन / हटाए गए रिकॉर्ड, अपडेट के मामले में - इसकी पिछली स्थिति)।

जब लाइब्रेरी को विज़ार्ड पैरामीटर के साथ प्रारंभ किया जाता है, तो निम्न जांच होती है:
1. सर्वर से कनेक्ट करने की क्षमता की जांच करें।
2. हम सेलेक्ट वर्सन () करते हैं - हमें विश्वास है कि संस्करण 5.1.23 से कम नहीं है।
3. हम 'वर्ल्ड बायलॉज' की तरह ग्लोएबल वार्सलाइज करते हैं - हम यह सुनिश्चित करते हैं कि बिनलॉग्स का प्रारूप ROW है।
4. उपयोगकर्ता द्वारा परिभाषित फ़ंक्शन के माध्यम से पढ़े गए अंतिम संदेश की सहेजी गई स्थिति पढ़ें। यदि उपयोगकर्ता-परिभाषित फ़ंक्शन ने कुछ भी नहीं लौटाया (खाली बिनलॉग नाम, शून्य स्थिति), तो हम SHOW MASTER STATUS अनुरोध के माध्यम से विज़ार्ड में बिनलॉग की वर्तमान स्थिति को पढ़ते हैं।
5. हम तालिकाओं के लिए आधार संरचना पढ़ते हैं, जिसका हम अनुसरण करेंगे।
6. slave_id जेनरेट करें ताकि यह किसी भी SHOW SLAVE HOSTS अनुरोध से मेल न खाए।
7. simple_command (COM_REGISTER_SLAVE) निष्पादित करके विज़ार्ड पर दास को पंजीकृत करें।
8. simple_command कमांड (COM_BINLOG_DUMP) का उपयोग करके डंप स्थानांतरण का अनुरोध करें।
9. हम आने वाले पैकेटों को संसाधित करने का चक्र शुरू करते हैं - उनके पार्सिंग, आवश्यक कॉलबैक कॉल करना, त्रुटि से निपटने।

अलग से, यह पांचवें बिंदु के बारे में ध्यान देने योग्य है - डेटाबेस संरचना को पढ़ना। एक सच्चे MySQL-दास के मामले में, हम हमेशा सही डिवाइस लेबल को जानते हैं, क्योंकि हमने कुछ प्रकार के SQL डंप के साथ शुरुआत की और सभी डीडीएल-स्टेटमेंट का पालन करते हुए उपयुक्त बिनलॉग स्थिति से तालिकाओं को पढ़ना जारी रखा। लिब्स्लेव, सामान्य मामले में, बिनलॉग की स्थिति से शुरू होता है जो उपयोगकर्ता इसे प्रदान करेगा (उदाहरण के लिए, जिस पर हमने पिछली बार, या विज़ार्ड की वर्तमान स्थिति से बचाया था)। सामान्य स्थिति में, उसे डेटाबेस संरचना के बारे में पहले से जानकारी नहीं होती है, इसलिए, वह क्वेरी परिणामों के SHOW FULL COLUMNS F आउटपुट से पार्स करके तालिका स्कीमा प्राप्त करती है। और यह वहाँ से है कि जानकारी दी जाती है कि किन क्षेत्रों में, किस प्रकार और किस क्रम में बिनलॉग से पार्स करना है। इसके साथ इस तरह की समस्या हो सकती है: हमें तालिकाओं का विवरण मिलता है, और हम पिछले वाले से बिनॉगल्स पढ़ना शुरू कर सकते हैं जब तालिका अभी भी अलग दिखती थी। इस मामले में, libslave सबसे अधिक संभावना है कि डेटा संगत नहीं है त्रुटि के साथ विफल हो जाएगा। आपको विज़ार्ड की वर्तमान स्थिति से पढ़ना शुरू करना होगा।

Libslave ऑपरेशन के दौरान तालिकाओं के विवरण को बदलना डरावना नहीं है। यह अलर्ट टेबल और क्रिएट टेबल प्रश्नों को पहचानता है, और उन्हें प्राप्त करने के तुरंत बाद, टेबल संरचनाओं को फिर से पढ़ता है। बेशक, यहां समस्याएं संभव हैं। मान लीजिए कि हमने इन घटनाओं के बीच कुछ डेटा लिखते हुए, जल्दी से एक टेबल की संरचना को दो बार बदल दिया। यदि लिब्स्लेव को पहले परिवर्तन का केवल दूसरा पूरा होने पर ही रिकॉर्ड मिलता है, तो SHOW FULL COLUMNS FROM के माध्यम से इसे तुरंत डेटाबेस की दूसरी स्थिति प्राप्त होगी। फिर तालिका को अपडेट करने की घटना, जो पहले विवरण के अनुरूप होगी, के पास प्रतिकृति को रोकने का मौका है। हालाँकि, व्यवहार में यह बहुत कम ही होता है (हमें पहले कभी नहीं हुआ था), और इस मामले में खरोंच से डेमॉन को पुनरारंभ करके इसका इलाज किया जाता है।

Libslave के साथ, आप लेन-देन की सीमाओं को ट्रैक कर सकते हैं। इस तथ्य के बावजूद कि जब तक कोई लेनदेन पूरा नहीं हो जाता है, तब तक इसकी कोई भी प्रविष्टि बिनलॉग में नहीं आती है, फिर भी लेन-देन में अंतर करना महत्वपूर्ण हो सकता है: यदि आपके पास अलग-अलग तालिकाओं में कोई दो संबंधित परिवर्तन हैं, तो आप केवल एक का उपयोग नहीं करना चाहते हैं दूसरा अपडेट होने तक अपडेट किया जाता है। BEGIN ईवेंट बिनलॉग में नहीं आते हैं - लेन-देन की शुरुआत में, तुरंत बदल गई लाइनें COMMIT के साथ समाप्त होती हैं। यानी लेन-देन BEGIN / COMMIT द्वारा ट्रैक नहीं किए जाते हैं, लेकिन दो लगातार COMMIT द्वारा किए जाते हैं।

यदि गुरु गायब हो गया है

Get_remote_binlog फ़ंक्शन द्वारा कहे जाने वाले मुख्य लिब्स्लेव लूप को एक उपयोगकर्ता फ़ंक्टर एक पैरामीटर के रूप में प्राप्त होता है, जिसे प्रत्येक नए पैकेज को पढ़ने से पहले जांचा जाता है। यदि फ़नकार सही लौटाता है, तो लूप समाप्त हो जाएगा।

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

नेटवर्क की विफलता के मामले में, कनेक्शन 60 सेकंड के टाइमआउट के साथ कॉन्फ़िगर किया गया है। यदि 60 सेकंड में एक भी नया डेटा पैकेट नहीं आया है (जो कि कोई अद्यतन नहीं होने पर स्थिति हो सकती है), तो डेटाबेस को फिर से जोड़ दिया जाएगा और संदेश प्रवाह अंतिम पढ़ने की स्थिति से पढ़ा जाना जारी रहेगा।

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

आंकड़े
लाइब्रेरी में एक अमूर्त वर्ग है ExtStateIface , जिसमें से विभिन्न जानकारी libslave से स्थानांतरित की जाती है: पुन: संख्या की संख्या, अंतिम घटना का समय, डेटाबेस से कनेक्शन की स्थिति। वर्तमान बिनलॉग स्थिति को किसी भी स्थिर भंडारण में सहेजने और लोड करने के लिए एक ही वर्ग जिम्मेदार है। इस वर्ग DefaultExtState का एक डिफ़ॉल्ट कार्यान्वयन है, एक म्यूटेक्स के माध्यम से काम करना ( चूंकि आंकड़े एक धागे में दास द्वारा निर्धारित किए जा सकते हैं, और कोई और इसे पढ़ सकता है)। दुखद समाचार यह है कि इस वर्ग का सही कार्यान्वयन लिब्स्लेव के सही ढंग से काम करने के लिए आवश्यक है, अर्थात यह केवल एक आँकड़ों की वस्तु नहीं है - यह एक ऐसी वस्तु है जो पुस्तकालय के संचालन को नियंत्रित कर सकती है।

मानक

मशीनों के दो सेटों पर बेंचमार्क किए गए।

पहला सेट एक मशीन थी जिस पर डेटाबेस स्थापित किया गया था, और उस पर परीक्षण किया गया था। विन्यास:
• CPU: Intel® Core (TM) i7-4770K CPU @ 3.50GHz
• मेम: 32 जीबी 1666 मेगाहर्ट्ज
• एमबी: आसुस Z87M-PLUS
• HDD: SSD OCZ-VERTEX3
• OS Gentoo लिनक्स, कर्नेल 3.12.13-gentoo x86_64
डेटाबेस सेटिंग्स डिफ़ॉल्ट थीं। ईमानदारी से, मुझे नहीं लगता है कि वे विज़ार्ड के लिए बहुत महत्व रखते हैं, जो वास्तव में नेटवर्क पर फ़ाइल "केवल" डालते हैं।

दूसरा सेट दो कारों का था। डेटाबेस के साथ पहली कार:
• CPU: 2 x Intel® Xeon® CPU E5620 @ 2.40GHz
• मेम: 7 x 8192 एमबी TS1GKR72V3N 800 मेगाहर्ट्ज (1.2ns), 1 x 8192 एमबी किंग्स्टन 9965434-063.A00LF 800 MHz (1.2ns), 4 x खाली
• MB: ETegro Technologies ETRS370G3
• HDD: 14 x 300 GB HUS156030VLS600, 2 x 250 GB WDC WD2500BEVT-0
• PCI: LSI लॉजिक / सिम्बायोस लॉजिक SAS2116 PCI-Express फ्यूजन-MPT SAS-2 [उल्का], इंटेल कॉर्पोरेशन 82801JI (ICH10 परिवार) SATA AHCI कंट्रोलर
• OS CentOS रिलीज़ 6.5 (अंतिम) कर्नेल 2.6.32-220.13.1.el6.x86_64

टेस्ट मशीन:
• CPU: 2 x Intel® Xeon® CPU E5-2620 0 @ 2.00GHz
• मेम: 15 x 8192 एमबी माइक्रोन 36KSF1G72PZ-1G4M1 1333 मेगाहर्ट्ज (0.8ns), 1 x 8192 एमबी माइक्रोन 36KSF1G72PZ-1G6M1 1333 मेगाहर्ट्ज (0.8ns)
• एमबी: ईटीग्रो टेक्नोलॉजीज ETRS125G4
• HDD: 2 x 2000 GB Hitachi HUA72302, 2 x 250 GB ST250DM000-1BD14
• PCI: इंटेल कॉर्पोरेशन C602 चिपसेट 4-पोर्ट SATA स्टोरेज कंट्रोल यूनिट, Intel Corporation C600 / X79 सीरीज़ चिपसेट 6-पोर्ट SATA AHCI कंट्रोलर
• OS CentOS रिलीज़ 6.5 (अंतिम) कर्नेल 2.6.32-358.23.2.el6.x86_64

मशीनों के बीच नेटवर्क 1 जीबी / एस।

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

परीक्षण के लिए दो तालिकाएँ बनाई गईं - छोटी और बड़ी:

 CREATE TABLE short_table ( id int NOT NULL auto_increment, field1 int NOT NULL, field2 int NOT NULL, PRIMARY KEY (id) ); CREATE TABLE long_table ( id int NOT NULL auto_increment, field1 timestamp NOT NULL DEFAULT 0, field2 timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, field3 enum('a','b','c') NOT NULL DEFAULT 'a', field4 enum('a','b','c') NOT NULL DEFAULT 'a', field5 varchar(255) NOT NULL, field6 int NOT NULL, field7 int NOT NULL, field8 text NOT NULL, field9 set('a','b','c') NOT NULL DEFAULT 'a', field10 int unsigned NOT NULL DEFAULT 2, field11 double NOT NULL DEFAULT 1.0, field12 double NOT NULL DEFAULT 0.0, field13 int NOT NULL, field14 int NOT NULL, field15 int NOT NULL, field16 text NOT NULL, field17 varchar(255) NOT NULL, field18 varchar(255) NOT NULL, field19 enum('a','b','c') NOT NULL DEFAULT 'a', field20 int NOT NULL DEFAULT 10, field21 double NOT NULL, field22 double NOT NULL DEFAULT 1.0, field23 double NOT NULL DEFAULT 1.0, field24 double NOT NULL DEFAULT 1.0, field25 text NOT NULL DEFAULT "", PRIMARY KEY (id) );

प्रत्येक तालिका में एक मिलियन रिकॉर्ड थे। डेटा सम्मिलित करते समय, एक पाठ फ़ील्ड एक छोटी रेखा से भर जाती थी। अन्य सभी लाइनें व्यावहारिक रूप से खाली थीं, फ़ील्ड डिफ़ॉल्ट मानों से भरे हुए थे। यानी इस सम्मिलन विधि ने हमें पूर्णरूपेण बिनलॉग प्राप्त करने की अनुमति दी, लेकिन अधिकांश स्ट्रिंग फ़ील्ड खाली थे:
INSERT INTO short_table (field1, field2) मान (1, 2);
INSERT INTO long_table (field5, field25) मान ("शॉर्ट_स्ट्रिंग", "एक और_शॉर्ट_स्ट्रिंग");

इन तालिकाओं में से प्रत्येक को पहले डेटाबेस में डाला गया था, जिसके बाद इसे पूरी तरह से प्रश्नों के साथ अपडेट किया गया था:
UPDATE शॉर्ट_टेबल SET फ़ील्ड 1 = 12;
UPDATE long_table SET field6 = 12;

इस प्रकार, INSERT प्रकार के बिनलॉग का एक सेट और UPDATE प्रकार के बिनलॉग का एक सेट प्राप्त करना संभव था (जो कि दो बार बड़े होते हैं, क्योंकि वे होते हैं, परिवर्तित रेखा के अलावा, इसकी पिछली स्थिति)। प्रत्येक ऑपरेशन से पहले, बिनलॉग स्थिति को याद किया गया था, अर्थात, उन्हें इस तरह से 4 बिनलॉग अंतराल प्राप्त हुए थे:
लघु तालिका सम्मिलित (5429180 - 18977180 => 13548000)
लघु तालिका अद्यतन (18977180 - 45766831 => 26789651)
एक लंबी तालिका के आवेषण (45768421 - 183563421 => 137795000)
लंबी तालिका के अद्यतन (183563421 - 461563664 => 278000243)।

परीक्षण gcc-4.8.2 संकलक द्वारा झंडे के साथ संकलित किया गया था -O2 -fomit-फ़्रेम-पॉइंटर -funroll-loops। प्रत्येक परीक्षण तीन बार चलाया गया था, तीसरे परीक्षण के परिणाम के रूप में लिया गया था।

और अब कुछ टेबल और ग्राफ। लेकिन पहले, संकेतन:
• "कोई कॉलबैक नहीं" का अर्थ है कि हमने लिब्स्लेव को टेबल पर किसी भी कॉलबैक को लटकाए बिना बिनलॉग के एक विशिष्ट सेट को पढ़ने के लिए कहा, अर्थात, कोई रिकॉर्डसेट रिकॉर्ड नहीं बनाया गया था।
• "बेंचमार्क कॉलबैक के साथ" का मतलब है कि कॉलबैक को प्रति सेकंड प्रदर्शन को मापने के लिए मापा गया था, जो कुल परीक्षण निष्पादन समय (ग्राफ़ बनाने के लिए आवश्यक) पर प्रभाव को कम करने की कोशिश कर रहा है। उन्होंने और कुछ नहीं किया - लिबस्लेव पर सभी काम केवल रिकॉर्ड को पार्स करने के लिए थे, रिकॉर्डसेट ऑब्जेक्ट (ओं) को बनाएं और उन्हें संदर्भ द्वारा उपयोगकर्ता-निर्धारित फ़ंक्शन में पास करें।
• "लॉकफ्री-मल्लोक के साथ" का अर्थ है कि परीक्षण में आवंटनकर्ता का उपयोग किया गया था ।

"टाइम 1" और "टाइम 2" - क्रमशः मशीनों 1 और 2 के सेट के लिए परीक्षण निष्पादन का समय।

कसौटी	समय 1 सेकंड	समय 2, सेकंड।
कॉलबैक के बिना एक छोटी तालिका में सम्मिलित होता है	००.०,२९९	००.१,५९५
बेंचमार्क शंकु के साथ एक छोटी तालिका में सम्मिलित करता है	०२.४,०९२	०३.८,९५८
कॉलबैक के बिना एक छोटी तालिका में अद्यतन	००.०,५००	००.२,३३६
बेंचमार्क-शंकु के साथ एक छोटी सी मेज पर अद्यतन	०४.८,४९९	०७.४,८९२
कॉलबैक के बिना एक बड़ी तालिका में सम्मिलित होता है	००.२६२७	०१.१,८४२
बेंचमार्क कॉलबैक के साथ एक बड़ी तालिका में सम्मिलित होता है	20.2901	33.9604
लॉकफ़्री-मॉलोक के साथ बेंचमार्क-शंकु के साथ एक बड़ी तालिका में सम्मिलित होता है	19.0906	34.5743
कॉलबैक के बिना एक बड़ी तालिका में अद्यतन	००.६,२२५	०२.३,८६०
बेंचमार्क कॉलबैक के साथ एक बड़ी तालिका में अपडेट	40.4330	70.7851
लॉकफ़्री-मॉलोक के साथ बेंचमार्क कॉलबैक के साथ एक बड़ी तालिका में अपडेट	37.9637	68.3616
कॉलबैक के बिना दोनों तालिकाओं को सम्मिलित करता है और अद्यतन करता है	००.९,४९९	०३.९,१७९
शॉर्ट के लिए बेंचमार्क कॉलबैक के साथ दोनों तालिकाओं को सम्मिलित करता है और अपडेट करता है	०८.०,४४५	14.8126
एक लंबे समय के लिए बेंचमार्क कॉलबैक के साथ दोनों तालिकाओं को सम्मिलित करता है और अद्यतन करता है	62.8213	100.9520
दोनों पर बेंचमार्क कॉलबैक के साथ दोनों तालिकाओं को सम्मिलित करता है और अद्यतन करता है	67.8092	118.3860
लॉकफ़्री-मॉलोक के साथ बेंचमार्क कॉलबैक के साथ दोनों तालिकाओं को सम्मिलित करता है और अपडेट करता है	64.5951	113.3920

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

मैंने इस बेंचमार्क में DELETE ईवेंट प्रोसेसिंग स्पीड की जांच नहीं की, लेकिन मुझे संदेह है कि यह INSERT स्पीड के समान है, क्योंकि लॉग में एक ही लंबाई का एक संदेश सम्मिलित होता है।

विविध कार्यान्वयन

फिलहाल, मैं केवल libslave के दो कार्यान्वयन जानता हूं। उनमें से एक पहले से ही उल्लेख किया गया है , बेगुन कंपनी ने इसे एक समय में खोला था, और इस बारे में बहुत कुछ लिखा गया है (उदाहरण के लिए, ओपननेट पर)। यह कार्यान्वयन FreeBSD पोर्ट में उपयोग किया जाता है।

Mail.Ru Group रनर फोर्क का उपयोग करता है, जिसे मैं कभी-कभी फाइल करता हूं। इसमें परिवर्तन का एक हिस्सा धावक कांटा को भी बनाया गया था। अप्रमाणित लोगों से: अप्रयुक्त कोड को काटकर, शीर्षकों को शामिल करने को कम करना, अधिक परीक्षण (BIGINT के लिए परीक्षण, लंबे SETs के लिए), प्रत्येक बिनलॉग के प्रारूप संस्करण की जांच करना, mysql-5.5 का समर्थन करना, प्रकार दशमलव (डबल के रूप में रिटर्न - बेशक, इसका उपयोग बिलिंग में नहीं किया जाता है) और जहां संतुलन का पर्याप्त मोटा विचार है), बिट फ़ील्ड्स के लिए समर्थन ( कांटा से उधार लिया गया, जो अब लगभग उसी राज्य में है)।

दूसरा कार्यान्वयन जो मुझे पता है कि पूर्वोक्त पियानोवादक और डिमारिक का है । यह वास्तुकला और प्रदर्शन के संदर्भ में क्या है, मुझे अभी तक पता नहीं लगाना है।

कोड उदाहरण

पुस्तकालय में ही कोड के उदाहरण हैं, लेकिन मैं कुछ टिप्पणियां दूंगा।

Type.h फ़ाइल: टाइपसेफ्स के माध्यम से, MySQL प्रकार और C ++ प्रकार के बीच मैपिंग दिखाता है। आप देख सकते हैं कि सभी स्ट्रिंग प्रकार, जिनमें BLOB शामिल हैं, केवल std :: string हैं, और सभी पूर्णांक प्रकार अहस्ताक्षरित हैं। यानी भले ही केवल int (अहस्ताक्षरित) तालिका परिभाषा में लिखा गया हो, पुस्तकालय uint32_t प्रकार वापस कर देगा।

एक ही फ़ाइल में DATE और DATETIME प्रकारों के अनुवाद के लिए दो सुविधाजनक कार्य हैं, जो कि libslave द्वारा नियमित time_t में प्रदान किए जाते हैं। ऐतिहासिक कारणों से ये दो कार्य बाहरी हैं (लिबासलेव के अंदर नहीं कहा जाता है): शुरू में लिब्स्लेव ने इन तारीखों के लिए अजीब एन्कोडेड संख्या लौटा दी, और मैंने इसे नहीं बदला।

Recordet.h फ़ाइल में RecordSet संरचना की एक परिभाषा है, जो एक एकल द्विपाद प्रविष्टि है। इसमें संदेश का प्रकार, उसका समय, डेटाबेस का नाम और वह तालिका जिसमें वह है, साथ ही दो पंक्तियाँ हैं - नया और पिछला (अपडेट के लिए)।

स्ट्रिंग स्ट्रिंग नाम से वस्तु को बढ़ावा देने वाली वस्तु :: कोई भी, के लिए एक साहचर्य सरणी है, जिसमें प्रकारों में वर्णित प्रकार शामिल होंगे। यह फ़ील्ड के अनुरूप है।

मुख्य स्लेव ऑब्जेक्ट Slave.h फ़ाइल में वर्णित है।

प्रतिकृति पढ़ना शुरू करने के लिए सबसे सरल कोड है:

 void callback(const slave::RecordSet& event) { switch (event.type_event) { case slave::RecordSet::Update: std::cout << "UPDATE"; break; case slave::RecordSet::Delete: std::cout << "DELETE"; break; case slave::RecordSet::Write: std::cout << "INSERT"; break; default: break; } } slave::MasterInfo masterinfo; masterinfo.host = host; masterinfo.port = port; masterinfo.user = user; masterinfo.password = password; slave::Slave slave(masterinfo); slave.setCallback(«database», «table», callback); slave.init(); slave.createDatabaseStructure(); slave.get_remote_binlog();

Test_client टेस्ट क्लाइंट के साथ नमूना सत्र
स्पष्टता के लिए, एक सत्र के एक छोटे से उदाहरण पर विचार करें: उपयोगकर्ता, डेटाबेस, तालिका बनाना, इसे डेटा के साथ भरना, और test_client का संबंधित आउटपुट। यह है, libslave स्रोत कोड में निहित रेडी-मेड प्रतिकृति क्लाइंट का एक उदाहरण।
Test_client कॉल इस तरह दिखता है:
Usage: ./test_client -h -u -p -d dev.mysql.com/doc/internals/en/event-data-for-specific-event-types.html Usage: ./test_client -h -u -p -d dev.mysql.com/doc/internals/en/event-data-for-specific-event-types.html

एक MySQL डेटाबेस से एक एप्लिकेशन को libslave प्रतिकृति क्लाइंट का उपयोग करके वितरित करना