ProxySQL 2.0 में नया क्या है?

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

कैशिंग क्वेरी के लिए ClusterControl और ProxySQL का उपयोग कैसे करें
ClusterControl और ProxySQL के साथ SQL फ़ायरवॉल कैसे बनाएँ
ProxySQL क्लस्टर कैसे परिनियोजित करें
उच्च उपलब्धता के लिए ProxySQL के साथ MySQL प्रतिकृति वातावरण को आसानी से कैसे परिनियोजित करें

हमारे पास ProxySQL को कवर करने वाला एक ट्यूटोरियल भी है जो यह दर्शाता है कि इसे MySQL और MariaDB सेटअप में कैसे उपयोग किया जा सकता है।

हाल ही में ProxySQL 2.0.3 जारी किया गया है, जो 2.0 श्रृंखला के लिए एक पैच रिलीज़ है। बग्स को ठीक किया जा रहा है और ऐसा लगता है कि 2.0 लाइन को वह कर्षण मिलना शुरू हो गया है जिसके वह हकदार हैं। इस ब्लॉग पोस्ट में हम ProxySQL 2.0 में पेश किए गए प्रमुख परिवर्तनों पर चर्चा करना चाहेंगे।

जीटीआईडी का उपयोग करके कारण पढ़ता है

हर कोई जिसे प्रतिकृति अंतराल से निपटना पड़ा और प्रतिकृति अंतराल से प्रभावित पढ़ने-लिखने के परिदृश्यों से जूझना पड़ा, निश्चित रूप से इस सुविधा से बहुत खुश होंगे। अब तक, MySQL प्रतिकृति वातावरण में, कारण पढ़ने को सुनिश्चित करने का एकमात्र तरीका मास्टर से पढ़ना था (और इससे कोई फर्क नहीं पड़ता कि आप एसिंक्रोनस या सेमीसिंक्रोनस प्रतिकृति का उपयोग करते हैं)। एक अन्य विकल्प गैलेरा के लिए जाना था, जिसमें कारण पढ़ने को लागू करने का विकल्प था, जैसे, हमेशा (पहले यह wsrep-कारण-पढ़ता था और अब यह wsrep-sync-wait है)। हाल ही में (8.0.14 में) MySQL समूह प्रतिकृति को समान सुविधा मिली। नियमित प्रतिकृति, हालांकि, अपने आप में, इस मुद्दे से निपट नहीं सकती है। सौभाग्य से, ProxySQL यहां है और यह हमें प्रति-क्वेरी नियम के आधार पर परिभाषित करने का विकल्प लाता है कि कौन सा होस्टग्रुप पढ़ता है कि कौन सा मिलान उस क्वेरी नियम के अनुरूप होना चाहिए। कार्यान्वयन ProxySQL बिनलॉग रीडर के साथ आता है और यह MySQL 5.7 और नए के लिए ROW बिनलॉग प्रारूप के साथ काम कर सकता है। MariaDB में आवश्यक कार्यक्षमता की कमी के कारण केवल Oracle MySQL समर्थित है। इस सुविधा और इसके तकनीकी विवरण को ProxySQL आधिकारिक ब्लॉग पर समझाया गया है।

फ्रंटएंड कनेक्शन के लिए एसएसएल

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

गैलेरा क्लस्टर के लिए मूल समर्थन

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

MySQL प्रतिकृति और MySQL समूह प्रतिकृति के साथ, ProxySQL में एक तालिका बनाई गई है:

mysql> show create table mysql_galera_hostgroups\G
*************************** 1. row ***************************
       table: mysql_galera_hostgroups
Create Table: CREATE TABLE mysql_galera_hostgroups (
    writer_hostgroup INT CHECK (writer_hostgroup>=0) NOT NULL PRIMARY KEY,
    backup_writer_hostgroup INT CHECK (backup_writer_hostgroup>=0 AND backup_writer_hostgroup<>writer_hostgroup) NOT NULL,
    reader_hostgroup INT NOT NULL CHECK (reader_hostgroup<>writer_hostgroup AND backup_writer_hostgroup<>reader_hostgroup AND reader_hostgroup>0),
    offline_hostgroup INT NOT NULL CHECK (offline_hostgroup<>writer_hostgroup AND offline_hostgroup<>reader_hostgroup AND backup_writer_hostgroup<>offline_hostgroup AND offline_hostgroup>=0),
    active INT CHECK (active IN (0,1)) NOT NULL DEFAULT 1,
    max_writers INT NOT NULL CHECK (max_writers >= 0) DEFAULT 1,
    writer_is_also_reader INT CHECK (writer_is_also_reader IN (0,1,2)) NOT NULL DEFAULT 0,
    max_transactions_behind INT CHECK (max_transactions_behind>=0) NOT NULL DEFAULT 0,
    comment VARCHAR,
    UNIQUE (reader_hostgroup),
    UNIQUE (offline_hostgroup),
    UNIQUE (backup_writer_hostgroup))
1 row in set (0.00 sec)

कॉन्फ़िगर करने के लिए कई सेटिंग्स हैं और हम एक-एक करके उन पर जाएंगे। सबसे पहले, चार होस्टग्रुप हैं:

Writer_hostgroup - इसमें 'max_writers' सेटिंग तक के सभी लेखक (read_only=0 के साथ) शामिल होंगे। डिफ़ॉल्ट रूप से यह केवल एक लेखक है
बैकअप_राइटर_होस्टग्रुप - इसमें शेष लेखक (read_only=0) शामिल हैं जो 'max_writers' को राइटर_होस्टग्रुप में जोड़ने के बाद बचे हैं
Reader_hostgroup - इसमें पाठक शामिल हैं (read_only=1), इसमें 'writer_is_also_reader' सेटिंग के अनुसार बैकअप लेखक भी हो सकते हैं
Offline_hostgroup - इसमें ऐसे नोड होते हैं जिन्हें प्रयोग करने योग्य नहीं माना जाता था (या तो ऑफ़लाइन या ऐसी स्थिति में जो उन्हें ट्रैफ़िक को संभालना असंभव बनाता है)

फिर हमारे पास शेष सेटिंग्स हैं:

सक्रिय - mysql_galera_hostgroups में प्रविष्टि सक्रिय है या नहीं
Max_writers - लेखक_होस्टग्रुप में अधिकतम कितने नोड रखे जा सकते हैं
Writer_is_also_reader - यदि 0 पर सेट किया जाता है, तो लेखक (read_only=0) को रीडर_होस्टग्रुप में नहीं रखा जाएगा। अगर 1 पर सेट किया जाता है, तो राइटर (read_only=0) को रीडर_होस्टग्रुप में डाल दिया जाएगा। यदि 2 पर सेट किया जाता है, तो बैकअप_राइटर_होस्टग्रुप से नोड्स को रीडर_होस्टग्रुप में डाल दिया जाएगा। यह थोड़ा जटिल है इसलिए हम इस ब्लॉग पोस्ट में बाद में एक उदाहरण पेश करेंगे
Max_transactions_behind - wsrep_local_recv_queue पर आधारित, अधिकतम स्वीकार्य कतार। यदि नोड पर कतार max_transactions_behind से अधिक हो जाती है तो दिए गए नोड को SHUNNED के रूप में चिह्नित किया जाएगा और यह ट्रैफ़िक के लिए उपलब्ध नहीं होगा

मुख्य आश्चर्य पाठकों को संभालना हो सकता है, जो कि ProxySQL में शामिल स्क्रिप्ट के काम करने के तरीके से अलग है। सबसे पहले, आपको जो ध्यान रखना है, वह यह है कि ProxySQL यह तय करने के लिए read_only=1 का उपयोग करता है कि नोड एक पाठक है या नहीं। यह प्रतिकृति सेटअप में सामान्य है, गैलेरा में उतना सामान्य नहीं है। इसलिए, सबसे अधिक संभावना है, आप रीडर_होस्टग्रुप में पाठकों को कैसे जोड़ा जाना चाहिए, इसे कॉन्फ़िगर करने के लिए 'राइटर_इस_भी_रीडर' सेटिंग का उपयोग करना चाहेंगे। आइए तीन गैलेरा नोड्स पर विचार करें, उन सभी में read_only=0 है। हमारे पास max_writers=1 भी है क्योंकि हम सभी राइट्स को एक नोड की ओर निर्देशित करना चाहते हैं। हमने mysql_galera_hostgroups को निम्नानुसार कॉन्फ़िगर किया है:

SELECT * FROM mysql_galera_hostgroups\G
*************************** 1. row ***************************
       writer_hostgroup: 10
backup_writer_hostgroup: 30
       reader_hostgroup: 20
      offline_hostgroup: 40
                 active: 1
            max_writers: 1
  writer_is_also_reader: 0
max_transactions_behind: 0
                comment: NULL
1 row in set (0.00 sec)

आइए सभी विकल्पों पर गौर करें:

लेखक_इस_भी_रीडर=0

mysql> SELECT hostgroup_id, hostname FROM runtime_mysql_servers;
+--------------+------------+
| hostgroup_id | hostname   |
+--------------+------------+
| 10           | 10.0.0.103 |
| 30           | 10.0.0.101 |
| 30           | 10.0.0.102 |
+--------------+------------+
3 rows in set (0.00 sec)

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

लेखक_इस_भी_रीडर=1

mysql> SELECT hostgroup_id, hostname FROM runtime_mysql_servers;
+--------------+------------+
| hostgroup_id | hostname   |
+--------------+------------+
| 10           | 10.0.0.103 |
| 20           | 10.0.0.101 |
| 20           | 10.0.0.102 |
| 20           | 10.0.0.103 |
| 30           | 10.0.0.101 |
| 30           | 10.0.0.102 |
+--------------+------------+
6 rows in set (0.00 sec)

यहां हम चाहते हैं कि हमारे लेखक पाठक के रूप में कार्य करें इसलिए उन सभी (सक्रिय और बैकअप) को रीडर_होस्टग्रुप में डाल दिया जाएगा।

लेखक_इस_भी_रीडर=2

mysql> SELECT hostgroup_id, hostname FROM runtime_mysql_servers;
+--------------+------------+
| hostgroup_id | hostname   |
+--------------+------------+
| 10           | 10.0.0.103 |
| 20           | 10.0.0.101 |
| 20           | 10.0.0.102 |
| 30           | 10.0.0.101 |
| 30           | 10.0.0.102 |
+--------------+------------+
5 rows in set (0.00 sec)

यह उन लोगों के लिए एक सेटिंग है जो नहीं चाहते कि उनका सक्रिय लेखक पठन को संभाले। इस मामले में केवल बैकअप_राइटर_होस्टग्रुप के नोड्स को पढ़ने के लिए उपयोग किया जाएगा। कृपया यह भी ध्यान रखें कि यदि आप max_writers को किसी अन्य मान पर सेट करेंगे तो पाठकों की संख्या बदल जाएगी। यदि हम इसे 3 पर सेट करते हैं, तो कोई बैकअप लेखक नहीं होगा (सभी नोड्स लेखक होस्टग्रुप में समाप्त हो जाएंगे), इस प्रकार, फिर से, रीडर होस्टग्रुप में कोई नोड नहीं होगा।

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

अन्य परिवर्तन

हमने जो ऊपर वर्णित किया है वह ProxySQL 2.0 में सबसे उल्लेखनीय सुधार हैं। चैंज के अनुसार कई अन्य हैं। उल्लेखनीय है कि क्वेरी कैश (उदाहरण के लिए, PROXYSQL FLUSH QUERY CACHE का जोड़) में सुधार और प्रतिकृति सेटअप में मास्टर और स्लेव को निर्धारित करने के लिए ProxySQL को super_read_only पर भरोसा करने की अनुमति देता है।

हम आशा करते हैं कि ProxySQL 2.0 में परिवर्तनों का यह संक्षिप्त अवलोकन आपको यह निर्धारित करने में मदद करेगा कि आपको ProxySQL के किस संस्करण का उपयोग करना चाहिए। कृपया ध्यान रखें कि 1.4 शाखा, भले ही इसमें कोई नई सुविधाएँ न हों, फिर भी इसे बनाए रखा जाता है।

ProxySQL 2.0 में नया क्या है?

जीटीआईडी ​​का उपयोग करके कारण पढ़ता है

फ्रंटएंड कनेक्शन के लिए एसएसएल

गैलेरा क्लस्टर के लिए मूल समर्थन

अन्य परिवर्तन

जीटीआईडी का उपयोग करके कारण पढ़ता है