रविवार, 1 मार्च 2026

क्या हर PXC Node पर XtraBackup इंस्टॉल करना ज़रूरी है?

Percona फोरम में नियमित रूप से उठने वाला एक प्रश्न: क्या Percona XtraDB Cluster (PXC) के हर नोड पर XtraBackup इंस्टॉल होना चाहिए? यह एक उचित प्रश्न है, विशेष रूप से मिश्रित वातावरण प्रबंधित करते समय या कुछ नोड्स पर सॉफ्टवेयर फुटप्रिंट को न्यूनतम करने की कोशिश करते समय। यहाँ वास्तविक मैकेनिक्स और टेस्टिंग द्वारा पुष्टि की गई बातें हैं।

छोटा उत्तर (लेकिन आगे पढ़ें)

यह इस बात पर निर्भर करता है कि आप उस नोड से क्या करवाना चाहते हैं। यहाँ बारीकी बहुत मायने रखती है, इसलिए Percona XtraDB Cluster (PXC) में State Snapshot Transfer (SST) कैसे काम करता है और किसी दिए गए नोड पर XtraBackup की मौजूदगी — या अनुपस्थिति — क्यों महत्वपूर्ण है, इसकी व्याख्या करना उचित है।

PXC में SST पर त्वरित पुनरावलोकन

जब एक नया नोड Percona XtraDB Cluster में जुड़ता है, या जब कोई मौजूदा नोड इतना लंबे समय तक डाउन रहता है कि Incremental State Transfer (IST) संभव नहीं रह जाता, तो क्लस्टर State Snapshot Transfer (SST) करता है। यह मूल रूप से डोनर नोड से जॉइनर नोड तक पूर्ण डेटा कॉपी है।

PXC कई SST विधियों का समर्थन करता है, जो my.cnf में कॉन्फ़िगर की जाती हैं:

[mysqld]
wsrep_sst_method = xtrabackup-v2

उपलब्ध SST विधियाँ शामिल हैं:

  • xtrabackup-v2 — PXC के लिए अनुशंसित विधि, Percona XtraBackup का उपयोग करके; SST करता है बिना डोनर को लंबे समय के लिए लॉक किए
  • clone — PXC 8.0.22+ में उपलब्ध, MySQL के बिल्ट-इन Clone Plugin का उपयोग करके; SST के लिए XtraBackup निर्भरता हटाता है
  • mysqldump — धीमी और ट्रांसफर के दौरान डोनर को लॉक करती है; प्रोडक्शन के लिए अनुशंसित नहीं
  • rsync — ट्रांसफर के दौरान डोनर को रीड-ओनली रहने की आवश्यकता, राइट्स को ब्लॉक करती है; लाइव क्लस्टर्स के लिए अनुशंसित नहीं

xtrabackup-v2 विधि ऐतिहासिक रूप से डिफ़ॉल्ट अप्रोच रही है और मौजूदा डिप्लॉयमेंट्स में व्यापक रूप से उपयोग की जाती है ठीक इसलिए क्योंकि यह ट्रांसफर के दौरान डोनर नोड को राइट्स के लिए उपलब्ध रखती है। अन्य पुरानी विधियाँ डोनर पर राइट्स को ब्लॉक कर सकती हैं, जो प्रोडक्शन क्लस्टर में आमतौर पर अस्वीकार्य है। ध्यान दें कि Percona PXC 8.0.22 और उसके बाद के नए इंस्टॉलेशन्स के लिए clone विधि की अनुशंसा बढ़ा रहा है, क्योंकि यह SST लेयर पर बाहरी टूल निर्भरता हटा देती है।

XtraBackup को कहाँ इंस्टॉल करना आवश्यक है?

जब xtrabackup-v2 का उपयोग करके SST ट्रिगर होता है, तो डोनर और जॉइनर दोनों को XtraBackup इंस्टॉल और पहुँच योग्य होना चाहिए। यहाँ कारण है कि दोनों पक्ष शामिल हैं:

``````html
  • donor XtraBackup चलाता है ताकि स्नैपशॉट डेटा को आउटबाउंड स्ट्रीम किया जा सके
  • joiner XtraBackup चलाता है — विशेष रूप से xbstream और xbcrypt उपयोगिताओं को — ताकि स्ट्रीम्ड डेटा को प्राप्त किया जा सके और लागू किया जा सके

यदि joiner नोड पर XtraBackup इंस्टॉल नहीं है और आप xtrabackup-v2 का उपयोग करके इसे क्लस्टर में जोड़ने का प्रयास करते हैं, तो SST विफल हो जाएगा। joiner पर एरर लॉग में आमतौर पर कुछ इस तरह का संदेश दिखाई देगा:

[ERROR] WSREP: Failed to read 'ready <addr>' from: wsrep_sst_xtrabackup-v2
...
wsrep_sst_xtrabackup-v2: line 522: xbstream: command not found
[ERROR] WSREP: SST failed: 2 (No such file or directory)

यह एक स्पष्ट और निर्विवाद विफलता मोड है। यदि xbstream joiner पर मौजूद नहीं है, तो SST पूरा नहीं होगा।

वे नोड्स जिन्हें कभी joiner बनना ही नहीं है?

तकनीकी रूप से, यदि कोई नोड हमेशा donor के रूप में कार्य करेगा और कभी क्लस्टर में शून्य से दोबारा शामिल होने की आवश्यकता नहीं पड़ेगी, तो आप यह तर्क दे सकते हैं कि उसे केवल donor क्षमता के लिए XtraBackup की आवश्यकता है। लेकिन व्यवहार में, कोई भी नोड joiner बन सकता है — क्रैश के बाद, नियोजित रखरखाव के बाद, या नेटवर्क पार्टिशन से रिकवर करने के बाद। कोई भी विश्वसनीय तरीका नहीं है जो गारंटी दे सके कि किसी नोड को कभी SST प्राप्त करने की आवश्यकता नहीं पड़ेगी।

यहाँ व्यावहारिक मार्गदर्शन सरल है: हर PXC नोड पर XtraBackup इंस्टॉल करें, बिना किसी अपवाद के। इसे इंस्टॉल करने का ओवरहेड नगण्य है। अनियोजित आउटेज के दौरान विफल SST की लागत नहीं है।

क्लोन प्लगइन विकल्प (PXC 8.0.22+)

PXC 8.0.22 से शुरू करके, Percona ने MySQL Clone Plugin को SST विधि के रूप में समर्थन जोड़ा है। यह जानना महत्वपूर्ण है क्योंकि यह SST उद्देश्यों के लिए XtraBackup निर्भरता को पूरी तरह से हटा देता है:

[mysqld]
wsrep_sst_method = clone

क्लोन विधि के साथ, Clone Plugin को सभी नोड्स पर लोड करना आवश्यक है:

INSTALL PLUGIN clone SONAME 'mysql_clone.so';
SHOW PLUGINS WHERE Name = 'clone';

+-------+--------+-------+----------------+---------+
| Name  | Status | Type  | Library        | License |
+-------+--------+-------+----------------+---------+
| clone | ACTIVE | CLONE | mysql_clone.so | GPL     |
+-------+--------+-------+----------------+---------+

क्लोन विधि XtraBackup के बिना SST निर्भरता के साथ मानकीकरण के लिए एक मजबूत विकल्प है। फिर भी, XtraBackup आपके बाहरी बैकअप रणनीति के लिए वास्तविक मूल्य रखता है, भले ही आप कौन सी SST विधि चुनें। SST एक क्लस्टर सिंक्रोनाइजेशन तंत्र है — यह बैकअप नहीं है, और इसे कभी बैकअप के रूप में व्यवहार नहीं करना चाहिए।

अपने वर्तमान SST कॉन्फ़िगरेशन की जाँच करना

आप अपने वर्तमान SST विधि और Galera-संबंधित सेटिंग्स को इस कमांड से सत्यापित कर सकते हैं:

SHOW VARIABLES LIKE 'wsrep_sst_method';

+------------------+---------------+
| Variable_name    | Value         |
+------------------+---------------+
| wsrep_sst_method | xtrabackup-v2 |
+------------------+---------------+

क्लस्टर स्थिति की जाँच करने और यह पुष्टि करने के लिए कि कौन सा नोड donor के रूप में कार्य कर रहा है:

SHOW STATUS LIKE 'wsrep_local_state_comment';

+---------------------------+--------+
| Variable_name             | Value  |
+---------------------------+--------+
| wsrep_local_state_comment | Synced |
+---------------------------+--------+

SHOW STATUS LIKE 'wsrep_connected';

+-----------------+-------+
| Variable_name   | Value |
+-----------------+-------+
| wsrep_connected | ON    |
+-----------------+-------+

SHOW STATUS LIKE 'wsrep_cluster_size';

+--------------------+-------+
| Variable_name      | Value |
+--------------------+-------+
| wsrep_cluster_size | 3     |
+--------------------+-------+

व्यावहारिक अवलोकन

PXC वातावरणों के साथ सीधे काम करने से कुछ उल्लेखनीय बातें:

``````html
  • XtraBackup का संस्करण आपके PXC संस्करण से मेल खाना चाहिए। XtraBackup 2.x को PXC 8.0 के साथ उपयोग करने से SST विफलताएँ होंगी। PXC 8.0 के साथ Percona XtraBackup 8.0 का उपयोग करें, और किसी भी अपग्रेड के बाद संस्करण संरेखण की पुष्टि करें।
  • भले ही आप clone SST विधि पर स्विच कर दें, XtraBackup को स्थापित रखें अनुसूचित बैकअप के लिए। आपकी बैकअप रणनीति और आपकी SST विधि अलग-अलग चिंताएँ हैं और इन्हें उसी तरह व्यवहार किया जाना चाहिए।
  • <wsrep_sst_donor चर आपको एक पसंदीदा दाता नोड निर्दिष्ट करने की अनुमति देता है, जो SST को आपके सबसे व्यस्त या सबसे विलंबता-संवेदनशील सदस्य से दूर निर्देशित करने के लिए उपयोगी है।
  • यदि आप PXC के साथ Percona Toolkit चला रहे हैं, तो अपने विशिष्ट PXC संस्करण में DDL replication कैसे काम करता है, इसकी जागरूकता रखें — Total Order Isolation (TOI) बनाम Rolling Schema Upgrade (RSU) व्यवहार अलग होता है और उत्पादन में स्कीमा परिवर्तन चलाने से पहले इसका विशेष रूप से अध्ययन करना उचित है।

सारांश

प्रश्न का सीधा उत्तर देने के लिए: यदि आप xtrabackup-v2 को अपनी SST विधि के रूप में उपयोग कर रहे हैं — जो कई मौजूदा PXC तैनाती में डिफ़ॉल्ट बना हुआ है — तो हाँ, हर क्लस्टर सदस्य पर XtraBackup स्थापित होना चाहिए। कोई भी नोड परिस्थितियों के आधार पर दाता या जॉइनर दोनों हो सकता है, और दोनों भूमिकाओं के लिए इस विधि का उपयोग करते समय XtraBackup की उपस्थिति आवश्यक है।

यदि आप PXC 8.0.22 या उसके बाद के संस्करण पर हैं और SST स्तर पर उस निर्भरता को समाप्त करना चाहते हैं, तो Clone Plugin विधि एक व्यवहार्य विकल्प है और नई तैनाती के लिए Percona की अनुशंसित पसंद बनती जा रही है। यदि आप ताज़ा शुरुआत कर रहे हैं, तो PXC 8.4 LTS वर्तमान दीर्घकालिक समर्थन रिलीज़ है और नई स्थापणाओं के लिए अनुशंसित लक्ष्य है। भले ही SST के लिए clone का उपयोग करें, XtraBackup आपके वास्तविक बैकअप कार्यों के लिए सही उपकरण बना रहता है।

XtraBackup को चुनिंदा नोड्स पर छोड़कर कुछ मेगाबाइट डिस्क स्थान बचाने की कोशिश न करें। उस निर्णय से अंततः होने वाली SST विफलता एक ऐसा समझौता नहीं है जो值得 करने लायक हो।

संसाधन

प्रस्तुतकर्ता पर कोई टिप्पणी नहीं:
लेबल: , , , , ,
सदस्यता लें टिप्पणियाँ (Atom)