मारियाडीबी मैक्सस्केल 2.4 में नया क्या है?

MaxScale 2.4 को 21 दिसंबर, 2019 को जारी किया गया था, और ClusterControl 1.7.6 इस संस्करण की निगरानी और प्रबंधन का समर्थन करता है। हालांकि, परिनियोजन के लिए, ClusterControl केवल संस्करण 2.3 तक का समर्थन करता है। किसी को मैन्युअल रूप से इंस्टेंस को मैन्युअल रूप से अपग्रेड करना होगा, और सौभाग्य से, अपग्रेड चरण बहुत सरल हैं। बस मारियाडीबी मैक्सस्केल डाउनलोड पेज से नवीनतम संस्करण डाउनलोड करें और पैकेज इंस्टॉलेशन कमांड निष्पादित करें।

निम्न आदेश दिखाते हैं कि CentOS 7 बॉक्स पर मौजूदा MaxScale 2.3 से MaxScale 2.4 में कैसे अपग्रेड किया जाए:

$ wget https://dlm.mariadb.com/1067184/MaxScale/2.4.10/centos/7/x86_64/maxscale-2.4.10-1.centos.7.x86_64.rpm
$ systemctl stop maxscale
$ yum localinstall -y maxscale-2.4.10-1.centos.7.x86_64.rpm
$ systemctl start maxscale
$ maxscale --version
MaxScale 2.4.10

इस ब्लॉग पोस्ट में, हम इस संस्करण के कुछ उल्लेखनीय सुधारों और नई विशेषताओं पर प्रकाश डालने जा रहे हैं और यह कैसे कार्रवाई में दिखता है। MariaDB MaxScale 2.4 में बदलावों की पूरी सूची के लिए, इसका चैंज देखें।

इंटरैक्टिव मोड कमांड इतिहास

यह मूल रूप से एक छोटा सा सुधार है जिसका MaxScale प्रशासन और निगरानी कार्य कुशलता पर बड़ा प्रभाव पड़ता है। MaxCtrl के इंटरेक्टिव मोड का अब अपना कमांड इतिहास है। कमांड इतिहास आसानी से आपको ऊपर या नीचे तीर कुंजी दबाकर निष्पादित कमांड को दोहराने की अनुमति देता है। हालाँकि, Ctrl+R कार्यक्षमता (आपके द्वारा प्रदान किए गए वर्णों से मेल खाने वाली अंतिम कमांड को याद करें) अभी भी नहीं है।

पिछले संस्करणों में, किसी को यह सुनिश्चित करने के लिए मानक शेल मोड का उपयोग करना पड़ता है कि कमांड .bash_history फ़ाइल द्वारा कैप्चर किए गए हैं।

गैलेरामोन के लिए GTID मॉनिटरिंग

यह उन लोगों के लिए एक अच्छा एन्हांसमेंट है जो एसिंक्रोनस प्रतिकृति के माध्यम से भौगोलिक अतिरेक के साथ गैलेरा क्लस्टर पर चल रहे हैं, जिसे क्लस्टर-टू-क्लस्टर प्रतिकृति के रूप में भी जाना जाता है, या मारियाडीबी प्रतिकृति पर मारियाडीबी गैलेरा क्लस्टर प्रतिकृति।

MaxScale 2.3 और पुराने में, यह ऐसा दिखता है यदि आपने MariaDB क्लस्टर्स के बीच मास्टर-स्लेव प्रतिकृति को सक्षम किया है:

MaxScale 2.4 के लिए, यह अब इस तरह दिख रहा है (Galera1's पर ध्यान दें) पंक्ति):

MaxScale से सभी नोड्स के लिए प्रतिकृति स्थिति देखना अब आसान हो गया है, इसके बिना अलग-अलग नोड्स पर बार-बार जाँच करने की आवश्यकता।

स्मार्ट राउटर

यह मैक्सस्केल 2.4 में नई प्रमुख विशेषताओं में से एक है, जहां मैक्सस्केल अब यह जानने के लिए पर्याप्त स्मार्ट है कि क्वेरी को संसाधित करने के लिए कौन सा बैकएंड मारियाडीबी बैकएंड सर्वर सबसे अच्छा है। स्मार्टराउटर क्लस्टर के लिए क्वेरी के प्रदर्शन, या निष्पादन समय का ट्रैक रखता है। माप को कुंजी के रूप में क्वेरी के कैननिकल के साथ संग्रहित किया जाता है। एक क्वेरी का कैननिकल SQL है जिसमें सभी उपयोगकर्ता-परिभाषित स्थिरांक को प्रश्न चिह्नों से बदल दिया जाता है, उदाहरण के लिए:

UPDATE `money_in` SET `accountholdername` = ? , `modifiedon` = ? , `status` = ? , `modifiedby` = ? WHERE `id` = ? 

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

माना कि हमारे पास दो साइटें हैं - सिडनी और सिंगापुर जैसा कि निम्नलिखित चित्र में दिखाया गया है:

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

• पढ़ें-लिखें विभाजन:3306
• राउंड रॉबिन:3307
• स्मार्ट राउटर:3308

हमारी SmarRouter सेवा और श्रोता परिभाषाएँ हैं:

[SmartQuery]
type=service
router=smartrouter
servers=DB_1,DB_2,DB_5
master=DB_1
user=maxscale
password=******

[SmartQuery-Listener]
type = listener
service = SmartQuery
protocol = mariadbclient
port = 3308

MaxScale को पुनरारंभ करें और सिंगापुर और सिडनी में स्थित दोनों MaxScale नोड्स को केवल-पढ़ने के लिए क्वेरी भेजना प्रारंभ करें। यदि क्वेरी को राउंड-रॉबिन राउटर (पोर्ट 3307) द्वारा संसाधित किया जाता है, तो हम देखेंगे कि क्वेरी राउंड-रॉबिन एल्गोरिथम के आधार पर रूट की जा रही है:

(app)$ mysql -usbtest -p -h maxscale_sydney -P3307 -e 'SELECT COUNT(id),@@hostname FROM sbtest.sbtest1'
+-----------+--------------------+
| count(id) | @@hostname         |
+-----------+--------------------+
|   1000000 | mariadb_singapore2 |
+-----------+--------------------+

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

पोर्ट 3308 पर स्मार्टराउटर सुनने के साथ, हम देखेंगे कि क्वेरी सिडनी में निकटतम दास को भेजी जा रही है:

(app)$ mysql -usbtest -p -h maxscale_sydney -P3308 -e 'SELECT COUNT(id),@@hostname FROM sbtest.sbtest1'
+-----------+-----------------+
| count(id) | @@hostname      |
+-----------+-----------------+
|   1000000 | mariadb_sydney1 |
+-----------+-----------------+

और अगर यही क्वेरी हमारी सिंगापुर साइट में निष्पादित की जाती है, तो इसे सिंगापुर में स्थित मारियाडीबी स्लेव को भेज दिया जाएगा:

(app)$ mysql -usbtest -p -h maxscale_singapore -P3308 -e 'SELECT COUNT(id),@@hostname FROM sbtest.sbtest1'
+-----------+--------------------+
| count(id) | @@hostname         |
+-----------+--------------------+
|   1000000 | mariadb_singapore2 |
+-----------+--------------------+

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

इसका अर्थ है, विहित क्वेरी (सामान्यीकृत क्वेरी) का ट्रैक रखने और उसके प्रदर्शन को मापने के लिए, आप शायद देखेंगे कि पहली क्वेरी इसके पहले निष्पादन में विफल हो जाती है, उदाहरण के लिए:

(app)$ mysql -usbtest -p -h maxscale_sydney -P3308 -e 'SELECT COUNT(id),@@hostname FROM sbtest.sbtest1'
ERROR 2013 (HY000) at line 1: Lost connection to MySQL server during query

मारियाडीबी सिडनी में सामान्य लॉग से, हम बता सकते हैं कि मैक्सस्केल से "खोया कनेक्शन" त्रुटि के बावजूद, पहली क्वेरी (आईडी 74) को सफलतापूर्वक निष्पादित किया गया था (कनेक्ट, क्वेरी और छोड़ें):

  74 Connect  [email protected] as anonymous on 
  74 Query    SELECT COUNT(id),@@hostname FROM sbtest.sbtest1
  74 Quit

जबकि समान अनुवर्ती क्वेरी को सही ढंग से संसाधित किया गया था और सही प्रतिक्रिया के साथ लौटाया गया था:

(app)$ mysql -usbtest -p -h maxscale_sydney -P3308 -e 'SELECT COUNT(id),@@hostname FROM sbtest.sbtest1'
+-----------+------------------------+
| count(id) | @@hostname             |
+-----------+------------------------+
|   1000000 | mariadb_sydney.cluster |
+-----------+------------------------+

मारियाडीबी सिडनी (आईडी 75) में सामान्य लॉग को फिर से देखते हुए, वही प्रोसेसिंग इवेंट पहली क्वेरी की तरह ही हुआ:

  75 Connect  [email protected] as anonymous on 
  75 Query    SELECT COUNT(id),@@hostname FROM sbtest.sbtest1
  75 Quit

इस अवलोकन से, हम यह निष्कर्ष निकाल सकते हैं कि कभी-कभी, मैक्सस्केल को प्रदर्शन को मापने और बाद की समान क्वेरी के लिए स्मार्ट बनने के लिए पहली क्वेरी को विफल करना पड़ता है। क्लाइंट के पास लौटने से पहले या लेन-देन का एक बार फिर से प्रयास करने से पहले आपका एप्लिकेशन इस "पहली त्रुटि" को ठीक से संभालने में सक्षम होना चाहिए।

सर्वर के लिए UNIX सॉकेट

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

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

[DB_2]
type=server
protocol=mariadbbackend
#address=54.255.133.39
socket=/var/lib/mysql/mysql.sock

उपरोक्त परिवर्तनों को लागू करने से पहले, हमें लोकलहोस्ट से एक MaxScale axscale उपयोगकर्ता बनाना होगा। मास्टर सर्वर पर:

MariaDB> CREATE USER 'maxscale'@'localhost' IDENTIFIED BY 'maxscalep4ss';
MariaDB> GRANT SELECT ON mysql.user TO 'maxscale'@'localhost';
MariaDB> GRANT SELECT ON mysql.db TO 'maxscale'@'localhost';
MariaDB> GRANT SELECT ON mysql.tables_priv TO 'maxscale'@'localhost';
MariaDB> GRANT SHOW DATABASES ON *.* TO 'maxscale'@'localhost';

फिर से शुरू करने के बाद, MaxScale वास्तविक पते के बजाय UNIX सॉकेट पथ दिखाएगा, और सर्वर सूची इस तरह दिखाई जाएगी:

जैसा कि आप देख सकते हैं, सॉकेट कनेक्शन के माध्यम से राज्य और जीटीआईडी ​​​​जानकारी सही ढंग से पुनर्प्राप्त की जाती है। ध्यान दें कि यह DB_2 अभी भी दूरस्थ कनेक्शन के लिए पोर्ट 3306 को सुन रहा है। यह दिखाता है कि मैक्सस्केल निगरानी के लिए इस सर्वर से कनेक्ट करने के लिए सॉकेट का उपयोग करता है।

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

सर्वर ड्रेनिंग

MaxScale 2.4 में, बैकएंड सर्वर को ड्रेन किया जा सकता है, जिसका अर्थ है कि मौजूदा कनेक्शन का उपयोग जारी रखा जा सकता है, लेकिन सर्वर से कोई नया कनेक्शन नहीं बनाया जाएगा। ड्रेन फीचर के साथ, हम एप्लिकेशन पक्ष से उपयोगकर्ता अनुभव को प्रभावित किए बिना एक सुंदर रखरखाव गतिविधि कर सकते हैं। ध्यान दें कि सर्वर को खत्म करने में अधिक समय लग सकता है, जो चल रही क्वेरी पर निर्भर करता है, जिन्हें इनायत से बंद करने की आवश्यकता होती है।

सर्वर को खाली करने के लिए, निम्न कमांड का उपयोग करें:

आफ्टर-इफेक्ट निम्नलिखित राज्यों में से एक हो सकता है:

• ड्रेनिंग - सर्वर ड्रेन किया जा रहा है।
• ड्रेन - सर्वर ड्रेन हो गया है। सर्वर खत्म हो रहा था और अब सर्वर से कनेक्शन की संख्या घटकर 0 हो गई है।
• रखरखाव - सर्वर रखरखाव के अधीन है।

सर्वर के समाप्त हो जाने के बाद, MaxScale के दृष्टिकोण से MariaDB सर्वर की स्थिति "रखरखाव" है:

जब कोई सर्वर रखरखाव मोड में होता है, तो उससे कोई कनेक्शन नहीं बनाया जाएगा और मौजूदा कनेक्शन बंद कर दिए जाएंगे।

निष्कर्ष

MaxScale 2.4 पिछले संस्करण की तुलना में बहुत सारे सुधार और परिवर्तन लाता है और यह MariaDB सर्वर और इसके सभी घटकों को संभालने के लिए सबसे अच्छा डेटाबेस प्रॉक्सी है।