मारियाडीबी और स्फिंक्स को सिंक्रनाइज़ करने के लिए खुद की बाइक

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

मैं शुरू करता हूं कि हमारी खोज कैसे व्यवस्थित हुई और हमने यह सब क्यों शुरू किया।

हमारी खोज पूरी तरह से मानक योजना के अनुसार आयोजित की गई थी।

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

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

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

यह सब बहुत अच्छा काम किया, लेकिन समस्याएं थीं।

1. दस्तावेज़ के निर्माण के बीच औसत देरी (हमारे पास यह फिर से शुरू या रिक्ति है) और सूचकांक में इसका प्रवेश हमारे डेटाबेस में उनकी संख्या के लिए सीधे आनुपातिक था।
2. चूंकि हमने विशेषता अपडेट वितरित करने के लिए वितरित इंडेक्स का उपयोग किया था, इसलिए हमें कोई गारंटी नहीं थी कि ये अपडेट इंडेक्स की सभी प्रतियों पर लागू किए गए थे।
3. सूचकांक के पुनर्निर्माण के दौरान होने वाले "तत्काल" परिवर्तन तब खो गए थे जब RELOAD INDEX कमांड को निष्पादित किया गया था (केवल इसलिए कि वे अभी तक नवनिर्मित इंडेक्स में नहीं थे), और केवल अगले रीइंडेक्सिंग के बाद इंडेक्स में मिला।
4. खोज के साथ सर्वर पर अनुक्रमित को अपडेट करने की स्क्रिप्ट को एक-दूसरे से स्वतंत्र रूप से निष्पादित किया गया था, उनके बीच कोई सिंक्रनाइज़ेशन नहीं था। इस वजह से, विभिन्न सर्वरों पर सूचकांक को अपडेट करने में देरी कई मिनटों तक हो सकती है।
5. यदि खोज से संबंधित किसी चीज़ का परीक्षण करना आवश्यक था, तो प्रत्येक परिवर्तन के बाद सूचकांक को फिर से बनाना आवश्यक था।

इन समस्याओं में से प्रत्येक अलग से खोज के बुनियादी ढांचे के कार्डिनल रीक्रिएशन के लायक नहीं थी, लेकिन साथ में ले जाने के कारण उन्होंने जीवन को काफी खराब कर दिया।

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

हमने MySQL प्रतिकृति प्रोटोकॉल का उपयोग करके इस तरह के डेटा ट्रांसफर चैनल का कनेक्शन बनाने का फैसला किया, और इंडेक्स का पुनर्निर्माण करते समय परिवर्तनों को सहेजने के लिए MySQL binlog जगह है। इस समाधान ने हमें एप्लिकेशन कोड से स्फिंक्स को लिखने से छुटकारा पाने की अनुमति दी। और जब से हमने पहले ही एक वैश्विक लेनदेन आईडी के साथ पंक्ति-आधारित प्रतिकृति का उपयोग किया था, तब तक डेटाबेस प्रतिकृतियों के बीच स्विच करना काफी सरलता से किया जा सकता था।

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

हमने एक सेवा बनाई जो मारबीडीबी में परिवर्तन के लिए सदस्यता लेती है और स्फिंक्स में सूचकांक को अपडेट करती है। उनकी जिम्मेदारियां इस प्रकार हैं:

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

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

 MySQL [(none)]> describe sync_state; +-----------------+--------+ | Field | Type | +-----------------+--------+ | id | bigint | | dummy_field | field | | binlog_position | uint | | binlog_name | string | | gtid | string | | flavor | string | +-----------------+--------+ 

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

डेटाबेस में किसी विशेष परिवर्तन से कौन से दस्तावेज़ प्रभावित होते हैं, यह निर्धारित करके प्रोसेसिंग प्रतिकृति घटनाओं की शुरुआत होती है। ऐसा करने के लिए, हमारी सेवा के कॉन्फ़िगरेशन में, हमने रुचि के तालिकाओं में पंक्ति परिवर्तन की घटनाओं के लिए रूटिंग की तरह कुछ किया, अर्थात्, यह निर्धारित करने के लिए नियमों का एक सेट कि डेटाबेस में परिवर्तन कैसे अनुक्रमित किया जाना चाहिए।

 [[ingest]] table = "vacancy" id_field = "id" index = "vacancy" [ingest.column_map] user_id = ["user_id"] edited_at = ["date_edited"] profession = ["profession"] latitude = ["latitude_deg", "latitude_rad"] longitude = ["longitude_deg", "longitude_rad"] [[ingest]] table = "vacancy_language" id_field = "vacancy_id" index = "vacancy" [ingest.column_map] language_id = ["languages"] level = ["languages"] [[ingest]] table = "vacancy_metro_station" id_field = "vacancy_id" index = "vacancy" [ingest.column_map] metro_station_id = ["metro"] 

उदाहरण के लिए, नियमों के इस सेट के साथ, vacancy , vacancy_language और vacancy_metro_station परिवर्तन vacancy सूचकांक में होना चाहिए। दस्तावेज़ संख्या को vacancy तालिका के लिए id फ़ील्ड में, और अन्य दो तालिकाओं के लिए vacancy_id id फ़ील्ड में लिया जा सकता है। column_map फ़ील्ड विभिन्न डेटाबेस तालिकाओं के क्षेत्रों पर सूचकांक क्षेत्रों की निर्भरता की एक तालिका है।

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

हमने कई अनावश्यक सूचकांक अपडेट से बचने के लिए ऐसा करने का फैसला किया, क्योंकि कई मामलों में दस्तावेज़ में एक एकल तार्किक परिवर्तन कई SQL प्रश्नों की मदद से होता है जो विभिन्न तालिकाओं को प्रभावित करते हैं, और कभी-कभी पूरी तरह से अलग लेनदेन में निष्पादित होते हैं।

मैं एक सरल उदाहरण दूंगा। मान लीजिए कि किसी उपयोगकर्ता ने एक रिक्ति संपादित की है। परिवर्तनों को सहेजने के लिए ज़िम्मेदार कोड अक्सर सादगी के लिए लिखा जाता है।

 BEGIN; UPDATE vacancy SET edited_at = NOW() WHERE id = 123; DELETE FROM vacancy_language WHERE vacancy_id = 123; INSERT INTO vacancy_language (vacancy_id, language_id, level) VALUES (123, 1, "fluent"), (123, 2, "technical"); DELETE FROM vacancy_metro_station WHERE vacancy_id = 123; INSERT INTO vacancy_metro_station (vacancy_id, metro_station_id) VALUES (123, 55); ... COMMIT; 

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

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

उसी समय, इस दृष्टिकोण ने हमें केवल अनुक्रमणिका की विशेषताओं को अपडेट करने की अनुमति दी, यदि पाठ फ़ील्ड में कोई बदलाव नहीं हुए, साथ ही स्फिंक्स में परिवर्तन भेजना भी।

इसलिए, अब हम यह पता लगा सकते हैं कि सूचकांक में किन दस्तावेजों को अद्यतन करने की आवश्यकता है।

कई मामलों में, बिनोल से डेटा इंडेक्स को अपडेट करने के लिए अनुरोध करने के लिए पर्याप्त नहीं है, इसलिए हमें उसी सर्वर से लापता डेटा मिलता है जहां से हम बिनलॉग पढ़ते हैं। इसके लिए, हमारी सेवा के कॉन्फ़िगरेशन में डेटा प्राप्त करने के लिए एक अनुरोध टेम्पलेट है।

 [data_source.vacancy] #               #   -      id     parts = 4 query = """ SELECT vacancy.id AS `:id`, vacancy.profession AS `profession_text:field`, GROUP_CONCAT(DISTINCT vacancy_language.language_id) AS `languages:attr_multi`, GROUP_CONCAT(DISTINCT vacancy_metro_station.metro_station_id) AS `metro:attr_multi` FROM vacancy LEFT JOIN vacancy_language ON vacancy_language.vacancy_id = vacancy.id LEFT JOIN vacancy_metro_station ON vacancy_metro_station.vacancy_id = vacancy.id GROUP BY vacancy.id """ 

इस टेम्पलेट में, सभी क्षेत्रों को विशेष उपनामों के साथ चिह्नित किया गया है: [___]:___ ।
इसका उपयोग लापता डेटा प्राप्त करने और सूचकांक के निर्माण के अनुरोध के निर्माण में किया जाता है (बाद में इस पर अधिक)।

हम इस प्रकार का अनुरोध करते हैं:

 SELECT vacancy.id AS `id`, vacancy.profession AS `profession_text`, GROUP_CONCAT(DISTINCT vacancy_language.language_id) AS `languages`, GROUP_CONCAT(DISTINCT vacancy_metro_station.metro_station_id) AS `metro` FROM vacancy LEFT JOIN vacancy_language ON vacancy_language.vacancy_id = vacancy.id LEFT JOIN vacancy_metro_station ON vacancy_metro_station.vacancy_id = vacancy.id WHERE vacancy.id IN (< id ,   >) GROUP BY vacancy.id 

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

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

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

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

सूचकांक के पुनर्निर्माण की प्रक्रिया कई चरणों में होती है।

1. हम अनुक्रमणिका के लिए एक विन्यास उत्पन्न करते हैं

   
   

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

   
   

2. MariaDB की वर्तमान स्थिति को सहेजें

   
   

   इस स्थिति से, हम खोज के साथ सभी सर्वरों पर नया सूचकांक उपलब्ध होने के बाद, बिनलॉग पढ़ना शुरू कर देंगे।

   
   

3. हम अनुक्रमणक शुरू करते हैं

   
   

   indexer --config tmp.vacancy.indexer.0.conf --all प्रपत्र indexer --config tmp.vacancy.indexer.0.conf --all कमांड indexer --config tmp.vacancy.indexer.0.conf --all करते हैं और उनके पूरा होने की प्रतीक्षा करते हैं। इसके अलावा, यदि सूचकांक भागों में विभाजित है, तो हम समानांतर में सभी भागों का निर्माण शुरू करते हैं।

   
   

4. हम सर्वर पर इंडेक्स फाइल लोड करते हैं

   
   

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

   
   

    [index_uploader] executable = "rsync" arguments = [ "--files-from=-", "--log-file=<<.DataDir>>/rsync.<<.Host>>.log", "--no-relative", "--times", "--delay-updates", ".", "rsync://<<.Host>>/index/vacancy/", ] 

   
   

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

   
   

5. हम सिंक्रनाइज़ेशन को रोकते हैं

   
   

   हम बिनलॉग पढ़ना बंद कर देते हैं, परिवर्तनों के संचय के लिए जिम्मेदार गोरोइन को रोकते हैं।

   
   

6. पुराने इंडेक्स को नए के साथ बदलें

   
   

   खोज के साथ प्रत्येक सर्वर के लिए, हम अनुक्रमिक प्रश्न बनाते हैं RELOAD INDEX vacancy_plain , TRUNCATE INDEX vacancy_plain , ATTACH INDEX vacancy_plain TO vacancy । यदि सूचकांक को भागों में विभाजित किया जाता है, तो हम प्रत्येक भाग के लिए इन प्रश्नों को अनुक्रम में निष्पादित करते हैं। उसी समय, यदि हम उत्पादन के माहौल में हैं, तो किसी भी सर्वर पर इन प्रश्नों को निष्पादित करने से पहले, हम इसे बैलेंसर के माध्यम से लोड हटा देते हैं (ताकि कोई TRUNCATE और ATTACH बीच सूचकांकों का चयन न कर सके), और जैसे ही अंतिम ATTACH अनुरोध पूरा हो गया है, हम इस सर्वर पर लोड लौटाते हैं।

   
   

7. सहेजे गए स्थान से सिंक्रनाइज़ेशन फिर से शुरू करना

   
   

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

   
   

मारियाडीबी सर्वर से सूचकांक के अंतराल के ग्राफ का एक उदाहरण यहां दिया गया है।

यहां आप देख सकते हैं कि हालांकि पुनर्निर्माण के बाद सूचकांक की स्थिति समय में वापस आती है, यह बहुत संक्षेप में होता है।

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

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

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

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

ऐसा करने के लिए, हमने अपनी सेवा में एक समापन बिंदु बनाया, जो बस यही करता है, अर्थात यह तब तक प्रतीक्षा करता है जब तक कि सभी परिवर्तन निर्दिष्ट लेनदेन संख्या पर लागू नहीं होते हैं। ऐसा करने के लिए, डेटाबेस में आवश्यक परिवर्तन करने के तुरंत बाद, हम MariaDB @@gtid_current_pos से अनुरोध @@gtid_current_pos और इसे अपनी सेवा के अंतिम बिंदु पर स्थानांतरित करते हैं। यदि हमने इस समय तक इस स्थिति में सभी लेनदेन लागू कर दिए हैं, तो सेवा तुरंत जवाब देती है कि हम जारी रख सकते हैं। यदि नहीं, तो परिवर्तन लागू करने के लिए जिम्मेदार गोरोइन में, हम इस GTID के लिए एक सदस्यता बनाते हैं, और जैसे ही यह (या इसके बाद कोई भी) लागू किया जाता है, हम ग्राहक को ऑटोटेस्ट जारी रखने की भी अनुमति देते हैं।

PHP कोड में, यह कुछ इस तरह दिखता है:

 <?php declare(strict_types=1); use GuzzleHttp\ClientInterface; use GuzzleHttp\RequestOptions; use PDO; class RiverClient { private const REQUEST_METHOD = 'post'; /** * @var ClientInterface */ private $httpClient; public function __construct(ClientInterface $httpClient) { $this->httpClient = $httpClient; } public function waitForSync(PDO $mysqlConnection, PDO $sphinxConnection, string $riverAddr): void { $masterGTID = $mysqlConnection->query('SELECT @@gtid_current_pos')->fetchColumn(); $this->httpClient->request( self::REQUEST_METHOD, "http://{$riverAddr}/wait", [RequestOptions::FORM_PARAMS => ['gtid' => $masterGTID]] ); } } 

परिणाम

नतीजतन, हम MariaDB और स्फिंक्स को अपडेट करने के बीच देरी को कम करने में सक्षम थे।

हमें यह भी भरोसा हो गया है कि सभी अपडेट हमारे Sphinx सर्वर पर समय पर पहुंचते हैं।

इसके अलावा, खोज परीक्षण (मैनुअल और स्वचालित दोनों) अधिक सुखद बन गए हैं।

दुर्भाग्य से, यह हमें मुफ्त में नहीं दिया गया था: सादे सूचकांक की तुलना में रियलटाइम इंडेक्स का प्रदर्शन थोड़ा खराब रहा।

सादे सूचकांक के लिए समय के आधार पर खोज क्वेरी के प्रसंस्करण समय का वितरण नीचे दिखाया गया है।

और यहाँ रियलटाइम इंडेक्स के लिए एक ही चार्ट है।

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

एक निष्कर्ष के बजाय

यह कहना है कि इस लेख में वर्णित सेवा का कोड, हमने सार्वजनिक डोमेन में पोस्ट किया है । दुर्भाग्य से, अभी तक कोई विस्तृत दस्तावेज नहीं है, लेकिन यदि आप चाहें, तो आप docker-compose माध्यम से इस सेवा का उपयोग करने का एक उदाहरण चला सकते docker-compose ।

संदर्भ

1. वीडियो और रिपोर्ट स्लाइड
2. हाईरोड ++ पर एंड्री स्मिरनोव और व्याचेस्लाव क्रायुकोव द्वारा वीडियो रिपोर्ट
3. गो- mysql पुस्तकालय
4. सेवा कोड उपयोग उदाहरण के साथ