MySQL और MariaDB की दुनिया

MySQL प्रतिकृति मार्गदर्शिका: सेटअप, प्रकार, और उच्च उपलब्धता के लिए समस्या निवारण

अनुप्रयोग / अन्य
目次

1. MySQL Replication क्या है? अवलोकन और उपयोग के मामले

MySQL Replication एक सुविधा है जो डेटाबेस की एक प्रति को वास्तविक समय में दूसरे सर्वर पर सिंक्रोनाइज़ करती है। यह डेटाबेस की अतिरिक्तता और प्रदर्शन को बढ़ाता है। नीचे, हम विस्तार से समझाते हैं कि MySQL Replication कहाँ उपयोग किया जाता है और यह कैसे काम करता है।

MySQL Replication का अवलोकन

MySQL Replication में एक मास्टर सर्वर और एक या अधिक स्लेव सर्वर शामिल होते हैं, जो डेटाबेस सामग्री को कई सर्वरों के बीच साझा करते हैं। विशेष रूप से, मास्टर सर्वर अपडेट को बाइनरी लॉग में रिकॉर्ड करता है, और स्लेव सर्वर उन अपडेट को पढ़ता और लागू करता है ताकि सिंक में रहे। इससे सेवाएँ जारी रह सकती हैं भले ही मास्टर सर्वर विफल हो जाए, स्लेव सर्वर पर स्विच करके।

MySQL Replication के उपयोग के मामले

MySQL Replication निम्नलिखित परिदृश्यों में व्यापक रूप से उपयोग किया जाता है:

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

प्रतिकृति के प्रकार

MySQL Replication में डेटा सिंक्रोनाइज़ेशन के तरीके के आधार पर निम्नलिखित प्रकार हैं:

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

अगले अनुभाग में, हम MySQL Replication के बुनियादी अवधारणाओं की व्याख्या करेंगे, जिसमें बाइनरी लॉग और GTID शामिल हैं।

2. MySQL Replication की बुनियादी अवधारणाएँ

MySQL Replication को समझने के लिए, बाइनरी लॉग और GTID (Global Transaction ID) की भूमिका जानना आवश्यक है, जो दोनों ही सटीक डेटा प्रतिकृति सुनिश्चित करते हैं।

मास्टर और स्लेव की भूमिकाएँ

MySQL Replication में, मास्टर सर्वर और स्लेव सर्वर की अलग-अलग भूमिकाएँ होती हैं। मास्टर अपडेट को बाइनरी लॉग में रिकॉर्ड करता है और उन्हें स्लेव्स को वितरित करता है। स्लेव सर्वर इन लॉग्स को लागू करके अपने डेटा को अपडेट करता है, मास्टर के समान स्थिति बनाए रखते हुए।

बाइनरी लॉग और रिले लॉग

MySQL Replication दो प्रमुख लॉग्स पर निर्भर करता है:

  1. बाइनरी लॉग
  • बाइनरी लॉग मास्टर सर्वर पर डेटा परिवर्तनों (INSERT, UPDATE, DELETE, आदि) को रिकॉर्ड करता है। इससे स्लेव मास्टर के समान स्थिति बनाए रख सकता है।
  1. रिले लॉग
  • रिले लॉग स्लेव सर्वर पर संग्रहीत होता है, जिसमें मास्टर से प्राप्त बाइनरी लॉग शामिल होता है। स्लेव का SQL थ्रेड इस रिले लॉग को क्रमिक रूप से निष्पादित करता है ताकि परिवर्तन लागू हों।

GTID (Global Transaction ID) क्या है?

GTID प्रत्येक लेनदेन को एक अद्वितीय ID सौंपता है, जो कई स्लेव्स के बीच स्थिरता सुनिश्चित करता है। GTID के साथ, बाइनरी लॉग स्थिति ट्रैकिंग की आवश्यकता नहीं होती, और केवल अनुप्रयुक्त लेनदेन स्वचालित रूप से लागू होते हैं, जिससे प्रबंधन सरल हो जाता है।

GTID के लाभ

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

GTID को सक्षम करने के लिए, दोनों मास्टर और स्लेव सर्वरों पर gtid_mode=ON और enforce_gtid_consistency=ON सेट करें। इससे GTID-आधारित प्रतिकृति सक्रिय हो जाती है।

अगले अनुभाग में, हम MySQL Replication के चरणबद्ध सेटअप को कवर करेंगे।

3. MySQL Replication सेटअप करने के चरण

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

मास्टर सर्वर कॉन्फ़िगरेशन

सबसे पहले, मास्टर सर्वर कॉन्फ़िगरेशन फ़ाइल (आमतौर पर my.cnf या my.ini) को संपादित करें ताकि बाइनरी लॉगिंग सक्षम हो और सर्वर ID सौंपा जाए।

  1. कॉन्फ़िगरेशन फ़ाइल संपादित करें
  • [mysqld] सेक्शन में निम्न सेटिंग्स जोड़ें, और एक अद्वितीय सर्वर आईडी सेट करें (उदाहरण : 1)।
    [mysqld]
server-id=1
log-bin=mysql-bin
  • server-id प्रत्येक सर्वर के लिए अद्वितीय होना चाहिए। log-bin बाइनरी लॉगिंग को सक्षम करता है।
  1. एक रेप्लिकेशन यूज़र बनाएं
  • मास्टर सर्वर पर एक रेप्लिकेशन यूज़र बनाएं और आवश्यक विशेषाधिकार प्रदान करें।
    CREATE USER 'repl'@'%' IDENTIFIED BY 'password';
GRANT REPLICATION SLAVE ON *.* TO 'repl'@'%';
FLUSH PRIVILEGES;
  • इस यूज़र की आवश्यकता स्लेव को मास्टर के डेटा तक पहुँचने के लिए होती है।
  1. मास्टर स्टेटस जांचें
  • वर्तमान बाइनरी लॉग फ़ाइल और पोजीशन जांचें, जो स्लेव कॉन्फ़िगरेशन के लिए आवश्यक होगी।
    SHOW MASTER STATUS;
  • दिखाए गए File और Position मानों का उपयोग स्लेव को कॉन्फ़िगर करते समय किया जाएगा।

स्लेव सर्वर कॉन्फ़िगरेशन

अगले चरण में, स्लेव सर्वर की कॉन्फ़िगरेशन फ़ाइल को संपादित करके एक अद्वितीय सर्वर आईडी सेट करें और मास्टर जानकारी निर्दिष्ट करें।

  1. कॉन्फ़िगरेशन फ़ाइल संपादित करें
  • स्लेव सर्वर को एक अद्वितीय server-id (उदाहरण : 2) असाइन करें। सर्वर आईडी मास्टर की आईडी से अलग होनी चाहिए।
    [mysqld]
server-id=2
  • अक्सर read_only=ON को सक्षम करना भी सामान्य है, ताकि स्लेव पर अनजाने में लिखने से बचा जा सके।
  1. स्लेव पर मास्टर जानकारी कॉन्फ़िगर करें
  • स्लेव सर्वर पर निम्न कमांड चलाएँ, जिसमें मास्टर होस्ट, यूज़र, बाइनरी लॉग फ़ाइल और लॉग पोजीशन निर्दिष्ट हों।
    CHANGE MASTER TO
    MASTER_HOST='master_host',
    MASTER_USER='repl',
    MASTER_PASSWORD='password',
    MASTER_LOG_FILE='mysql-bin.000001',
    MASTER_LOG_POS=123;
  • MASTER_LOG_FILE और MASTER_LOG_POS मानों का उपयोग करें, जो मास्टर के SHOW MASTER STATUS आउटपुट से प्राप्त हुए हैं।
  1. रेप्लिकेशन शुरू करें
  • स्लेव सर्वर पर निम्न कमांड चलाकर रेप्लिकेशन शुरू करें।
    START SLAVE;

रेप्लिकेशन स्टेटस जांचें

जाँचें कि मास्टर और स्लेव के बीच रेप्लिकेशन सही ढंग से काम कर रहा है या नहीं।

  • मास्टर स्टेटस जांचें
    SHOW MASTER STATUS;
  • स्लेव स्टेटस जांचें
    SHOW SLAVE STATUSG;
  • यदि दोनों Slave_IO_Running और Slave_SQL_Running का मान Yes दिखाता है, तो रेप्लिकेशन सामान्य रूप से चल रहा है।

अगले सेक्शन में, हम MySQL रेप्लिकेशन के उन्नत कॉन्फ़िगरेशन विकल्पों का अन्वेषण करेंगे, जिसमें असिंक्रोनस और सेमी‑सिंक्रोनस रेप्लिकेशन के बीच अंतर और GTID‑आधारित सेटअप शामिल हैं।

4. रेप्लिकेशन प्रकार और अनुप्रयोग

MySQL रेप्लिकेशन दो मुख्य प्रकारों में आता है, जो सिंक्रोनाइज़ेशन विधि पर निर्भर करते हैं: असिंक्रोनस रेप्लिकेशन और सेमी‑सिंक्रोनस रेप्लिकेशन। अंतर को समझना और प्रत्येक का कब उपयोग करना है, यह प्रदर्शन और विश्वसनीयता को अनुकूलित करने में मदद करता है। यह सेक्शन GTID (ग्लोबल ट्रांज़ैक्शन आइडेंटिफ़ायर) के उपयोग के लाभों को भी कवर करता है।

असिंक्रोनस और सेमी‑सिंक्रोनस रेप्लिकेशन के बीच अंतर

1. असिंक्रोनस रेप्लिकेशन

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

2. सेमी‑सिंक्रोनस रेप्लिकेशन

सेमी‑सिंक्रोनस रेप्लिकेशन में, मास्टर सर्वर कम से कम एक स्लेव द्वारा डेटा प्राप्त होने तक क्लाइंट को प्रतिक्रिया देने से पहले इंतज़ार करता है। यह डेटा स्थिरता को बेहतर बनाता है, लेकिन ट्रांज़ैक्शन प्रतिक्रिया समय बढ़ा देता है क्योंकि मास्टर को पुष्टि का इंतज़ार करना पड़ता है। सेमी‑सिंक्रोनस रेप्लिकेशन उन वातावरणों के लिए आदर्श है जहाँ डेटा स्थिरता और विश्वसनीयता को प्राथमिकता दी जाती है।

GTID के साथ रेप्लिकेशन

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

GTID के लाभ

  • सरल प्रबंधन – प्रत्येक ट्रांज़ैक्शन का एक वैश्विक पहचानकर्ता होने से स्लेव को सिंक करना आसान हो जाता है।
  • ऑटोमैटिक फेलओवर – फेलओवर के दौरान GTID‑आधारित स्लेव स्वचालित रूप से सही स्थिति पर पुनः शुरू हो सकता है।
  • सुसंगतता – सभी सर्वर एक ही GTID क्रम का पालन करते हैं, जिससे डेटा असंगतियों की संभावना कम होती है।

  • **लचीला टॉपोलॉजी – मल्टीमास्टर या सर्कुलर रेप्लिकेशन सेटअप में GTID का उपयोग आसान होता है।

  • डेटा संग में सुधार : GTID स्लेव को स्वचालित रूप से अनलागू लेन‑देन पहचानने की अनुमति देता है, जिससे संगति सुनिश्चित होती है।

  • प्रबंधन को सरल बनाया : GTID बाइनरी लॉग स्थितियों को मैन्युअल रूप से निर्दिष्ट करने की आवश्यकता को समाप्त करता है, जिससे फेलओवर और रिकवरी संचालन आसान हो जाता है।

GTID प्रतिकृति सेटअप

GTID को सक्षम करने के लिए, मास्टर और स्लेव कॉन्फ़िगरेशन फ़ाइलों में निम्नलिखित विकल्प जोड़ें।

मास्टर सर्वर कॉन्फ़िगरेशन

[mysqld]
server-id=1
log-bin=mysql-bin
gtid_mode=ON
enforce_gtid_consistency=ON

स्लेव सर्वर कॉन्फ़िगरेशन

[mysqld]
server-id=2
gtid_mode=ON
enforce_gtid_consistency=ON
read_only=ON

एक बार GTID सक्षम हो जाने पर, स्लेव पर CHANGE MASTER TO कमांड के साथ प्रतिकृति सेट करने से GTID‑आधारित प्रतिकृति स्वचालित रूप से संभाली जाएगी।

अगले भाग में, हम MySQL प्रतिकृति रखरखाव और निगरानी प्रथाओं की व्याख्या करेंगे।

5. प्रतिकृति रखरखाव और निगरानी

MySQL प्रतिकृति को प्रभावी ढंग से चलाने के लिए नियमित रखरखाव और निगरानी आवश्यक है। यह भाग प्रतिकृति स्थिति की जाँच कैसे करें और सामान्य त्रुटियों को कैसे संभालें, यह समझाता है।

प्रतिकृति स्थिति कैसे जांचें

मास्टर और स्लेव सर्वरों के बीच समन्वयन की निगरानी के लिए निम्नलिखित कमांड का उपयोग करें।

मास्टर स्थिति जांचें

मास्टर सर्वर पर, वर्तमान बाइनरी लॉग फ़ाइल और स्थिति देखने के लिए SHOW MASTER STATUS चलाएँ। यह स्लेव को भेजे जाने वाले नवीनतम अपडेट दिखाता है।

SHOW MASTER STATUS;

मुख्य फ़ील्ड शामिल हैं:

  • File : वर्तमान बाइनरी लॉग फ़ाइल का नाम
  • Position : बाइनरी लॉग के भीतर वर्तमान स्थिति
  • Binlog_Do_DB और Binlog_Ignore_DB : प्रतिकृति में शामिल या बाहर रखे गए डेटाबेस

स्लेव स्थिति जांचें

स्लेव सर्वर पर, प्रतिकृति स्वास्थ्य जांचने के लिए SHOW SLAVE STATUS चलाएँ।

SHOW SLAVE STATUSG;

महत्वपूर्ण फ़ील्ड शामिल हैं:

  • Slave_IO_Running और Slave_SQL_Running : यदि प्रतिकृति सामान्य रूप से कार्य कर रही है तो दोनों Yes होने चाहिए।
  • Seconds_Behind_Master : यह दर्शाता है कि स्लेव कितनी सेकंड पीछे है। आदर्श रूप में, यह 0 होना चाहिए।

प्रतिकृति समस्या निवारण

प्रतिकृति में सामान्य समस्याओं मेंनेक्शन त्रुटियाँ और डेटा असंगतियाँ शामिल हैं। नीचे सामान्य त्रुटि मामलों और उनके समाधान दिए गए हैं।

1. कनेक्शन त्रुटियाँ

यदि Slave_IO_Running No है, तो स्लेव मास्टर से कनेक नहीं हो पा रहा है। संभावित समाधान हैं:

  • मास्टर होस्ट/IP सत्यापित करें : सुनिश्चित करें कि सही पता सेट किया गया है।
  • फ़ायरवॉल सेटिंग्स : पुष्टि करें कि पोर्ट 3306 खुला और सुलभ है।

2. डेटा असंगति

यदि Last_Error में त्रुटियाँ दिखाई देती हैं, तो मास्टर और स्लेव के डेटा में असंगति हो सकती है। समाधान के लिए:

STOP SLAVE;
# Fix the data manually
START SLAVE;

गंभीर असंगतियों के लिए, मास्टर से पूर्ण बैकअप पुनर्स्थापित करके पुनः समकालिक करें।

3. प्रतिकृति विलंब

प्रतिकृति विलंब स्लेव पर हार्डवेयर सीमाओं या नेटवर्क समस्याओं के कारण हो सकता है। हार्डवेयर अपग्रेड या क्वेरी अनुकूलन से प्रदर्शन में सुधार हो सकता है।

अगला भाग सामान्य प्रतिकृति समस्याओं और उनके विस्तृत समाधान को समझाता है।

6. सामान्य प्रतिकृति समस्याएँ और समाधान

MySQL प्रतिकृति के दौरान विभिन्न समस्याएँ उत्पन्न हो सकती हैं। यह भाग सामान्य समस्याओं और उनके समाधान का विवरण देता है।

1. Slave_IO_Running बंद है

समस्या: यदि Slave_IO_Running No है, तो स्लेव मास्टर से कनेक्ट नहीं हो पा रहा है।

कारण और समाधान:

  • नेटवर्क समस्याएँ : फ़ायरवॉल और मास्टर से कनेक्टिविटी जांचें।
  • गलत मास्टर होस्ट/IP : CHANGE MASTER TO कॉन्फ़िगरेशन सत्यापित करें।
  • उपयोगकर्ता विशेषाधिकार : सुनिश्चित करें कि प्रतिकृति उपयोगकर्ता के पास GRANT REPLICATION SLAVE के साथ सही अनुमतियाँ हैं।

2. स्लेव डेटा असंगति

समस्या: डेटा मास्टर और स्लेव के बीच भिन्न है।

कारण और समाधान:

  • मैन्युअल सुधार : स्लेव को रोकें असंगत डेटा को ठीक करें, फिर प्रतिकृति पुनः शुरू करें। STOP SLAVE; # Fix data START SLAVE;
  • पूर्ण पुनःसमक्रमण : गंभीर असंगतियों के लिए, मास्टर से बैकअप पुनः आयात करें।

3. प्रतिकृति विलंब

समस्या: Seconds_Behind_Master 0 से अधिक है, जिसका अर्थ है स्लेव पीछे है।

कारण और समाधान:

  • हार्डवेयर सीमाएँ : स्लेव सर्वर की विशिष्टताओं को अपग्रेड करें।
  • क्वेरी अनुकूलन : इंडेक्स और क्वेरीज़ को सुधारें ताकि स्लेव पर प्रोसेसिंग समय कम हो।

4. प्रतिकृति उपयोगकर्ता विशेषाधिकार त्रुटियाँ

समस्या: Last_Error में त्रुटियाँ अपर्याप्त विशेषाधिकार दर्शाती हैं।

समाधान:

  • सही विशेषाधिकार प्रदान करें : उचित प्रतिकृति अधिकार सुनिश्चित करें। GRANT REPLICATION SLAVE ON *.* TO 'repl'@'slave_ip'; FLUSH PRIVILEGES;

5. बाइनरी लॉग वृद्धि

समस्या: मास्टर के बाइनरी लॉग अत्यधिक बढ़ते हैं, जिससे डिस्क स्पेस खपत होती है।

समाधान:

  • लॉग रोटेशन : पुराने लॉग को स्वचालित रूप से हटाने के लिए expire_logs_days का उपयोग करें। SET GLOBAL expire_logs_days = 7; # 7 दिनों से पुराने लॉग हटाएँ

इन सामान्य समस्य को समझकर और तैयार रहकर, प्रशासक स्थिर प्रतिकृति संचालन बनाए रख सकते हैं।

7. निष्कर्ष

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

मुख्य बिंदु

  1. सही प्रतिकृति प्रकार चुनें
  • असिंक्रोनस प्रतिकृति गति और लोड बैलेंसिंग प्रदान करती है, जबकि सेमी-सिंक्रोनस प्रतिकृति अधिक विश्वसनीयता देती है। सिस्टम आवश्यकताओं के आधार पर चुनें।
  1. GTID का उपयोग करें
  • GTID प्रतिकृति को सरल बनाता है क्योंकि बाइनरी लॉग पोजीशन निर्दिष्ट करने की आवश्यकता नहीं रहती, जिससे यह बड़े या महत्वपूर्ण वातावरण में उपयोगी बनता है।
  1. स्थिति को नियमित रूप से मॉनिटर करें
  • SHOW MASTER STATUS और SHOW SLAVE STATUS का बार-बार उपयोग असामान्यताओं का शीघ्र पता लगाएँ और जोखिम कम करें।
  1. मास्टर समस्या निवारण कौशल
  • कनेक्शन त्रुटियों, असंगतियों और लैग जैसी प्रतिकृति-विशिष्ट समस्याओं को संभालने में परिचित रहें।
  1. बाइनरी लॉग प्रबंधन करें
  • expire_logs_days को कॉन्फ़िगर करके और नियमित रूप से लॉग रोटेट करके डिस्क उपयोग समस्याओं को रोकें।

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

हमें आशा कि यह गाइड आपको My प्रतिकृति को प्रभावी ढंग से समझने और लागू करने में मदद करेगा, जिससे सुगम और स्थिर संचालन सुनिश्चित हो सके।