डॉकर पर MySQL गैलेरा क्लस्टर के लिए ProxySQL 2.0 को कैसे चलाएं और कॉन्फ़िगर करें

ProxySQL एक बुद्धिमान और उच्च प्रदर्शन वाला SQL प्रॉक्सी है जो MySQL, MariaDB और ClickHouse को सपोर्ट करता है। हाल ही में, ProxySQL 2.0 GA बन गया है और यह GTID कंसिस्टेंट रीड्स, फ्रंटएंड SSL, गैलेरा और MySQL ग्रुप रेप्लिकेशन नेटिव सपोर्ट जैसी नई रोमांचक सुविधाओं के साथ आता है।

ProxySQL को Docker कंटेनर के रूप में चलाना अपेक्षाकृत आसान है। हमने पहले लिखा है कि कैसे ProxySQL को Kubernetes पर एक सहायक कंटेनर के रूप में या Kubernetes सेवा के रूप में चलाया जाए, जो ProxySQL 1.x पर आधारित है। इस ब्लॉग पोस्ट में, हम नए संस्करण ProxySQL 2.x का उपयोग करने जा रहे हैं जो गैलेरा क्लस्टर कॉन्फ़िगरेशन के लिए एक अलग दृष्टिकोण का उपयोग करता है।

ProxySQL 2.x डॉकर इमेज

हमने एक नया ProxySQL 2.0 डॉकर इमेज कंटेनर जारी किया है और यह डॉकर हब में उपलब्ध है। रीडमे विशेष रूप से गैलेरा और माईएसक्यूएल प्रतिकृति, प्री और पोस्ट v2.x के लिए कई कॉन्फ़िगरेशन उदाहरण प्रदान करता है। कॉन्फ़िगरेशन लाइनों को टेक्स्ट फ़ाइल में परिभाषित किया जा सकता है और ProxySQL सेवा में लोड करने के लिए कंटेनर के पथ में /etc/proxysql.cnf पर मैप किया जा सकता है।

छवि "नवीनतम" टैग अभी भी 1.x की ओर इशारा करता है जब तक कि ProxySQL 2.0 आधिकारिक तौर पर GA नहीं बन जाता (हमने अभी तक ProxySQL टीम से कोई आधिकारिक रिलीज़ ब्लॉग/लेख नहीं देखा है)। जिसका अर्थ है, जब भी आप Manynines के नवीनतम टैग का उपयोग करके ProxySQL छवि स्थापित करते हैं, तब भी आपको इसके साथ संस्करण 1.x प्राप्त होगा। ध्यान दें कि नए उदाहरण कॉन्फ़िगरेशन भी ProxySQL वेब आँकड़े (1.4.4 में पेश किए गए लेकिन अभी भी बीटा में) को सक्षम करते हैं - एक साधारण डैशबोर्ड जो ProxySQL के समग्र कॉन्फ़िगरेशन और स्थिति को सारांशित करता है।

ProxySQL 2.x गैलेरा क्लस्टर के लिए समर्थन

आइए गैलेरा क्लस्टर देशी समर्थन के बारे में अधिक विस्तार से बात करते हैं। नई mysql_galera_hostgroups तालिका में निम्नलिखित फ़ील्ड शामिल हैं:

writer_hostgroup : होस्टग्रुप की आईडी जिसमें वे सभी सदस्य शामिल होंगे जो लेखक हैं (read_only=0).
बैकअप_राइटर_होस्टग्रुप : यदि क्लस्टर बहु-लेखक मोड में चल रहा है (अर्थात read_only=0 के साथ कई नोड हैं) और max_writers को नोड्स की कुल संख्या से छोटी संख्या पर सेट किया गया है, तो अतिरिक्त नोड्स को इस बैकअप लेखक होस्टग्रुप में ले जाया जाता है।
reader_hostgroup : होस्टग्रुप की आईडी जिसमें वे सभी सदस्य होंगे जो पाठक हैं (यानी नोड्स जिनमें read_only=1 है)
ऑफ़लाइन_होस्टग्रुप : जब ProxySQL मॉनिटरिंग एक होस्ट को ऑफ़लाइन होने का निर्धारण करती है, तो होस्ट को ऑफ़लाइन_होस्टग्रुप में ले जाया जाएगा।
सक्रिय : एक बूलियन मान (0 या 1) एक होस्टग्रुप को सक्रिय करने के लिए
अधिकतम लेखक : लेखक होस्टग्रुप में स्वीकार्य नोड्स की अधिकतम संख्या को नियंत्रित करता है, जैसा कि पहले उल्लेख किया गया है, अतिरिक्त नोड्स को बैकअप_राइटर_होस्टग्रुप में ले जाया जाएगा।
writer_is_also_reader : जब 1, लेखक_होस्टग्रुप में एक नोड भी रीडर_होस्टग्रुप में रखा जाएगा ताकि इसे पढ़ने के लिए इस्तेमाल किया जा सके। जब 2 पर सेट किया जाता है, तो बैकअप_राइटर_होस्टग्रुप के नोड्स को राइटर_होस्टग्रुप में नोड के बजाय रीडर_होस्टग्रुप में रखा जाएगा।
max_transactions_behind : बासी पठन को रोकने के लिए नोड को SHUNNED करने से पहले क्लस्टर में एक नोड द्वारा कतारबद्ध किए जा सकने वाले राइटसेट की अधिकतम संख्या निर्धारित करता है (यह wsrep_local_recv_queue Galera चर को क्वेरी करके निर्धारित किया जाता है)।
टिप्पणी : टेक्स्ट फ़ील्ड जिसका उपयोग उपयोगकर्ता द्वारा परिभाषित किसी भी उद्देश्य के लिए किया जा सकता है

यहाँ तालिका प्रारूप में mysql_galera_hostgroups के लिए एक उदाहरण कॉन्फ़िगरेशन दिया गया है:

Admin> select * from mysql_galera_hostgroups\G
*************************** 1. row ***************************
       writer_hostgroup: 10
backup_writer_hostgroup: 20
       reader_hostgroup: 30
      offline_hostgroup: 9999
                 active: 1
            max_writers: 1
  writer_is_also_reader: 2
max_transactions_behind: 20
                comment:

ProxySQL निम्न MySQL स्थिति/चर की निगरानी करके गैलेरा स्वास्थ्य जांच करता है:

केवल पढ़ने के लिए - अगर चालू है, तो ProxySQL परिभाषित होस्ट को रीडर_होस्टग्रुप में समूहित करेगा जब तक कि लेखक_इस_भी_रीडर 1 न हो।
wsrep_desync - अगर चालू है, तो ProxySQL नोड को अनुपलब्ध के रूप में चिह्नित करेगा, इसे ऑफ़लाइन_होस्टग्रुप में ले जाया जाएगा।
wsrep_reject_queries - यदि यह चर चालू है, तो ProxySQL नोड को अनुपलब्ध के रूप में चिह्नित करेगा, इसे ऑफ़लाइन_होस्टग्रुप (कुछ रखरखाव स्थितियों में उपयोगी) पर ले जाएगा।
wsrep_sst_donor_rejects_queries - यदि यह चर चालू है, तो ProxySQL नोड को अनुपलब्ध के रूप में चिह्नित करेगा जबकि गैलेरा नोड SST दाता के रूप में कार्य कर रहा है, इसे ऑफ़लाइन_होस्टग्रुप में ले जाया जाएगा।
wsrep_local_state - यदि यह स्थिति 4 (4 का अर्थ सिंक किया गया) के अलावा अन्य लौटाती है, तो ProxySQL नोड को अनुपलब्ध के रूप में चिह्नित करेगा और इसे ऑफ़लाइन_होस्टग्रुप में स्थानांतरित कर देगा।
wsrep_local_recv_queue - अगर यह स्थिति max_transactions_behind से अधिक है, तो नोड को छोड़ दिया जाएगा।
wsrep_cluster_status - यदि यह स्थिति प्राथमिक के अलावा अन्य लौटाती है, तो ProxySQL नोड को अनुपलब्ध के रूप में चिह्नित करेगा और इसे ऑफ़लाइन_होस्टग्रुप में स्थानांतरित कर देगा।

यह कहने के बाद, इन नए मापदंडों को mysql_galera_hostgroups में mysql_query_rules के साथ मिलाकर, ProxySQL 2.x में अधिक गैलेरा उपयोग के मामलों में फिट होने की लचीलापन है। उदाहरण के लिए, किसी के पास एकल-लेखक, बहु-लेखक और बहु-पाठक होस्टग्रुप हो सकते हैं, जिन्हें क्वेरी नियम के गंतव्य होस्टग्रुप के रूप में परिभाषित किया गया है, जिसमें लेखकों की संख्या को सीमित करने और पुराने पठन व्यवहार पर बेहतर नियंत्रण रखने की क्षमता है।

इसकी तुलना ProxySQL 1.x से करें, जहां उपयोगकर्ता को बैकएंड स्वास्थ्य जांच करने और डेटाबेस सर्वर स्थिति को अपडेट करने के लिए बाहरी स्क्रिप्ट को कॉल करने के लिए शेड्यूलर को स्पष्ट रूप से परिभाषित करना था। इसके लिए स्क्रिप्ट में कुछ अनुकूलन की आवश्यकता है (उपयोगकर्ता को ProxySQL व्यवस्थापक उपयोगकर्ता/पासवर्ड/पोर्ट को अपडेट करना होगा) साथ ही यह ProxySQL व्यवस्थापक इंटरफ़ेस से कनेक्ट करने के लिए एक अतिरिक्त टूल (MySQL क्लाइंट) पर निर्भर करता है।

ProxySQL 1.x:

. के लिए तालिका प्रारूप में गैलेरा स्वास्थ्य जांच स्क्रिप्ट अनुसूचक का एक उदाहरण विन्यास यहां दिया गया है

Admin> select * from scheduler\G
*************************** 1. row ***************************
         id: 1
     active: 1
interval_ms: 2000
   filename: /usr/share/proxysql/tools/proxysql_galera_checker.sh
       arg1: 10
       arg2: 20
       arg3: 1
       arg4: 1
       arg5: /var/lib/proxysql/proxysql_galera_checker.log
    comment:

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

ProxySQL 2.x में, max_writers और writer_is_also_reader चर यह निर्धारित कर सकते हैं कि ProxySQL गतिशील रूप से बैकएंड MySQL सर्वर को कैसे समूहित करता है और सीधे कनेक्शन वितरण और क्वेरी रूटिंग को प्रभावित करेगा। उदाहरण के लिए, निम्नलिखित MySQL बैकएंड सर्वरों पर विचार करें:

Admin> select hostgroup_id, hostname, status, weight from mysql_servers;
+--------------+--------------+--------+--------+
| hostgroup_id | hostname     | status | weight |
+--------------+--------------+--------+--------+
| 10           | DB1          | ONLINE | 1      |
| 10           | DB2          | ONLINE | 1      |
| 10           | DB3          | ONLINE | 1      |
+--------------+--------------+--------+--------+

निम्नलिखित गैलेरा होस्टग्रुप परिभाषा के साथ:

Admin> select * from mysql_galera_hostgroups\G
*************************** 1. row ***************************
       writer_hostgroup: 10
backup_writer_hostgroup: 20
       reader_hostgroup: 30
      offline_hostgroup: 9999
                 active: 1
            max_writers: 1
  writer_is_also_reader: 2
max_transactions_behind: 20
                comment:

यह देखते हुए कि सभी होस्ट ऊपर और चल रहे हैं, ProxySQL सबसे अधिक संभावना है कि मेजबानों को नीचे के रूप में समूहित करेगा:

आइए एक-एक करके उन्हें देखें:

<थ>विवरण

कॉन्फ़िगरेशन
writer_is_also_reader=0	होस्ट को 2 होस्टग्रुप (लेखक और बैकअप_राइटर) में समूहित करता है। लेखक बैकअप_राइटर का हिस्सा है। चूंकि लेखक पाठक नहीं है, होस्टग्रुप 30 (रीडर) में कुछ भी नहीं है क्योंकि कोई भी होस्ट read_only=1 के साथ सेट नहीं है। केवल-पढ़ने के लिए ध्वज को सक्षम करने के लिए गैलेरा में यह एक सामान्य प्रथा नहीं है।
writer_is_also_reader=1	होस्ट को 3 होस्टग्रुप (लेखक, बैकअप_लेखक और पाठक) में समूहित करता है। गैलेरा में वेरिएबल read_only=0 का कोई प्रभाव नहीं है इसलिए लेखक भी होस्टग्रुप 30 (रीडर) में है लेखक बैकअप_राइटर का हिस्सा नहीं है।
writer_is_also_reader=2	लेखक_is_also_reader=1 के समान, हालांकि, लेखक बैकअप_लेखक का हिस्सा है।

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

गैलेरा क्लस्टर के लिए ProxySQL परिनियोजन

इस उदाहरण में, मान लें कि हमारे पास पहले से ही एक तीन-नोड गैलेरा क्लस्टर है जिसे ClusterControl द्वारा परिनियोजित किया गया है जैसा कि निम्नलिखित आरेख में दिखाया गया है:

हमारे Wordpress एप्लिकेशन डॉकर पर चल रहे हैं जबकि Wordpress डेटाबेस को हमारे गैलेरा क्लस्टर पर बेयर-मेटल सर्वर पर होस्ट किया गया है। हमने अपने Wordpress कंटेनरों के साथ एक ProxySQL कंटेनर चलाने का फैसला किया है ताकि Wordpress डेटाबेस क्वेरी रूटिंग पर बेहतर नियंत्रण हो और हमारे डेटाबेस क्लस्टर इंफ्रास्ट्रक्चर का पूरी तरह से उपयोग हो सके। चूंकि पढ़ने-लिखने का अनुपात लगभग 80% -20% है, इसलिए हम ProxySQL को इस पर कॉन्फ़िगर करना चाहते हैं:

सभी लिखने को एक गैलेरा नोड पर अग्रेषित करें (कम संघर्ष, लिखने पर ध्यान दें)
बैलेंस सभी अन्य दो गैलेरा नोड्स को पढ़ता है (अधिकांश कार्यभार के लिए बेहतर वितरण)

सबसे पहले, डॉकर होस्ट के अंदर एक ProxySQL कॉन्फ़िगरेशन फ़ाइल बनाएं ताकि हम इसे अपने कंटेनर में मैप कर सकें:

$ mkdir /root/proxysql-docker
$ vim /root/proxysql-docker/proxysql.cnf

फिर, निम्नलिखित पंक्तियों को कॉपी करें (हम कॉन्फ़िगरेशन लाइनों को और नीचे समझाएंगे):

datadir="/var/lib/proxysql"

admin_variables=
{
    admin_credentials="admin:admin"
    mysql_ifaces="0.0.0.0:6032"
    refresh_interval=2000
    web_enabled=true
    web_port=6080
    stats_credentials="stats:admin"
}

mysql_variables=
{
    threads=4
    max_connections=2048
    default_query_delay=0
    default_query_timeout=36000000
    have_compress=true
    poll_timeout=2000
    interfaces="0.0.0.0:6033;/tmp/proxysql.sock"
    default_schema="information_schema"
    stacksize=1048576
    server_version="5.1.30"
    connect_timeout_server=10000
    monitor_history=60000
    monitor_connect_interval=200000
    monitor_ping_interval=200000
    ping_interval_server_msec=10000
    ping_timeout_server=200
    commands_stats=true
    sessions_sort=true
    monitor_username="proxysql"
    monitor_password="proxysqlpassword"
    monitor_galera_healthcheck_interval=2000
    monitor_galera_healthcheck_timeout=800
}

mysql_galera_hostgroups =
(
    {
        writer_hostgroup=10
        backup_writer_hostgroup=20
        reader_hostgroup=30
        offline_hostgroup=9999
        max_writers=1
        writer_is_also_reader=1
        max_transactions_behind=30
        active=1
    }
)

mysql_servers =
(
    { address="db1.cluster.local" , port=3306 , hostgroup=10, max_connections=100 },
    { address="db2.cluster.local" , port=3306 , hostgroup=10, max_connections=100 },
    { address="db3.cluster.local" , port=3306 , hostgroup=10, max_connections=100 }
)

mysql_query_rules =
(
    {
        rule_id=100
        active=1
        match_pattern="^SELECT .* FOR UPDATE"
        destination_hostgroup=10
        apply=1
    },
    {
        rule_id=200
        active=1
        match_pattern="^SELECT .*"
        destination_hostgroup=30
        apply=1
    },
    {
        rule_id=300
        active=1
        match_pattern=".*"
        destination_hostgroup=10
        apply=1
    }
)

mysql_users =
(
    { username = "wordpress", password = "passw0rd", default_hostgroup = 10, transaction_persistent = 0, active = 1 },
    { username = "sbtest", password = "passw0rd", default_hostgroup = 10, transaction_persistent = 0, active = 1 }
)

अब, आइए कुछ सबसे अधिक कॉन्फ़िगरेशन अनुभागों पर जाएँ। सबसे पहले, हम गैलेरा होस्टग्रुप कॉन्फ़िगरेशन को नीचे के रूप में परिभाषित करते हैं:

mysql_galera_hostgroups =
(
    {
        writer_hostgroup=10
        backup_writer_hostgroup=20
        reader_hostgroup=30
        offline_hostgroup=9999
        max_writers=1
        writer_is_also_reader=1
        max_transactions_behind=30
        active=1
    }
)

होस्टग्रुप 10 राइटर_होस्टग्रुप, होस्टग्रुप 20 बैकअप_राइटर और होस्टग्रुप 30 रीडर के लिए होगा। हम max_writers को 1 पर सेट करते हैं ताकि हमारे पास होस्टग्रुप 10 के लिए एक सिंगल-राइटर होस्टग्रुप हो, जहां सभी राइट्स को भेजा जाना चाहिए। फिर, हम लेखक_इस_भी_रीडर को 1 से परिभाषित करते हैं जो सभी गैलेरा नोड्स को पाठक के रूप में भी बना देगा, उन प्रश्नों के लिए उपयुक्त जो सभी नोड्स में समान रूप से वितरित किए जा सकते हैं। होस्टग्रुप 9999 ऑफ़लाइन_होस्टग्रुप के लिए आरक्षित है यदि प्रॉक्सीएसक्यूएल गैर-संचालन वाले गैलेरा नोड्स का पता लगाता है।

फिर, हम अपने MySQL सर्वर को डिफ़ॉल्ट रूप से होस्टग्रुप 10 में कॉन्फ़िगर करते हैं:

mysql_servers =
(
    { address="db1.cluster.local" , port=3306 , hostgroup=10, max_connections=100 },
    { address="db2.cluster.local" , port=3306 , hostgroup=10, max_connections=100 },
    { address="db3.cluster.local" , port=3306 , hostgroup=10, max_connections=100 }
)

उपरोक्त कॉन्फ़िगरेशन के साथ, ProxySQL हमारे होस्टग्रुप को नीचे के रूप में "देखेगा":

फिर, हम क्वेरी नियमों के माध्यम से क्वेरी रूटिंग को परिभाषित करते हैं। हमारी आवश्यकता के आधार पर, लेखक (होस्टग्रुप 20) को छोड़कर सभी गैलेरा नोड्स को सभी रीड्स भेजे जाने चाहिए और बाकी सब कुछ सिंगल राइटर के लिए होस्टग्रुप 10 को अग्रेषित किया जाना चाहिए:

mysql_query_rules =
(
    {
        rule_id=100
        active=1
        match_pattern="^SELECT .* FOR UPDATE"
        destination_hostgroup=10
        apply=1
    },
    {
        rule_id=200
        active=1
        match_pattern="^SELECT .*"
        destination_hostgroup=20
        apply=1
    },
    {
        rule_id=300
        active=1
        match_pattern=".*"
        destination_hostgroup=10
        apply=1
    }
)

अंत में, हम MySQL उपयोगकर्ताओं को परिभाषित करते हैं जिन्हें ProxySQL के माध्यम से पारित किया जाएगा:

mysql_users =
(
    { username = "wordpress", password = "passw0rd", default_hostgroup = 10, transaction_persistent = 0, active = 1 },
    { username = "sbtest", password = "passw0rd", default_hostgroup = 10, transaction_persistent = 0, active = 1 }
)

हम लेन-देन_पर्सिस्टेंट को 0 पर सेट करते हैं, इसलिए इन उपयोगकर्ताओं से आने वाले सभी कनेक्शन पढ़ने और लिखने के लिए क्वेरी नियमों का सम्मान करेंगे। अन्यथा, कनेक्शन एक होस्टग्रुप को मार देंगे जो लोड संतुलन के उद्देश्य को हरा देता है। उन उपयोगकर्ताओं को पहले सभी MySQL सर्वर पर बनाना न भूलें। ClusterControl उपयोगकर्ता के लिए, आप उन उपयोगकर्ताओं को बनाने के लिए प्रबंधित -> स्कीमा और उपयोगकर्ता सुविधा का उपयोग कर सकते हैं।

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

$ docker run -d \
--name proxysql2 \
--hostname proxysql2 \
--publish 6033:6033 \
--publish 6032:6032 \
--publish 6080:6080 \
--restart=unless-stopped \
-v /root/proxysql/proxysql.cnf:/etc/proxysql.cnf \
severalnines/proxysql:2.0

अंत में, ProxySQL कंटेनर पोर्ट 6033 की ओर इशारा करते हुए Wordpress डेटाबेस को बदलें, उदाहरण के लिए:

$ docker run -d \
--name wordpress \
--publish 80:80 \
--restart=unless-stopped \
-e WORDPRESS_DB_HOST=proxysql2:6033 \
-e WORDPRESS_DB_USER=wordpress \
-e WORDPRESS_DB_HOST=passw0rd \
wordpress

इस समय, हमारी वास्तुकला कुछ इस तरह दिख रही है:

यदि आप चाहते हैं कि ProxySQL कंटेनर लगातार बना रहे, तो /var/lib/proxysql/ को किसी डॉकर वॉल्यूम में मैप करें या माउंट को बाइंड करें, उदाहरण के लिए:

$ docker run -d \
--name proxysql2 \
--hostname proxysql2 \
--publish 6033:6033 \
--publish 6032:6032 \
--publish 6080:6080 \
--restart=unless-stopped \
-v /root/proxysql/proxysql.cnf:/etc/proxysql.cnf \
-v proxysql-volume:/var/lib/proxysql \
severalnines/proxysql:2.0

ध्यान रखें कि ऊपर की तरह लगातार भंडारण के साथ चलने से हमारा /root/proxysql/proxysql.cnf दूसरे पुनरारंभ पर अप्रचलित हो जाएगा। यह ProxySQL मल्टी-लेयर कॉन्फ़िगरेशन के कारण है जिससे यदि /var/lib/proxysql/proxysql.db मौजूद है, तो ProxySQL कॉन्फ़िगरेशन फ़ाइल से लोडिंग विकल्पों को छोड़ देगा और इसके बजाय SQLite डेटाबेस में जो कुछ भी है उसे लोड करेगा (जब तक कि आप --initial के साथ proxysql सेवा शुरू नहीं करते हैं) झंडा)। ऐसा कहने के बाद, अगला ProxySQL कॉन्फ़िगरेशन प्रबंधन कॉन्फ़िगरेशन फ़ाइल का उपयोग करने के बजाय, पोर्ट 6032 पर ProxySQL व्यवस्थापक कंसोल के माध्यम से किया जाना है।

निगरानी

ProxySQL प्रक्रिया लॉग डिफ़ॉल्ट रूप से syslog में लॉग इन करती है और आप उन्हें मानक docker कमांड का उपयोग करके देख सकते हैं:

$ docker ps
$ docker logs proxysql2

वर्तमान होस्टग्रुप को सत्यापित करने के लिए, रनटाइम_mysql_servers तालिका को क्वेरी करें:

$ docker exec -it proxysql2 mysql -uadmin -padmin -h127.0.0.1 -P6032 --prompt='Admin> '
Admin> select hostgroup_id,hostname,status from runtime_mysql_servers;
+--------------+--------------+--------+
| hostgroup_id | hostname     | status |
+--------------+--------------+--------+
| 10           | 192.168.0.21 | ONLINE |
| 30           | 192.168.0.21 | ONLINE |
| 30           | 192.168.0.22 | ONLINE |
| 30           | 192.168.0.23 | ONLINE |
| 20           | 192.168.0.22 | ONLINE |
| 20           | 192.168.0.23 | ONLINE |
+--------------+--------------+--------+

यदि चयनित लेखक नीचे चला जाता है, तो उसे ऑफलाइन_होस्टग्रुप (HID 9999) में स्थानांतरित कर दिया जाएगा:

Admin> select hostgroup_id,hostname,status from runtime_mysql_servers;
+--------------+--------------+--------+
| hostgroup_id | hostname     | status |
+--------------+--------------+--------+
| 10           | 192.168.0.22 | ONLINE |
| 9999         | 192.168.0.21 | ONLINE |
| 30           | 192.168.0.22 | ONLINE |
| 30           | 192.168.0.23 | ONLINE |
| 20           | 192.168.0.23 | ONLINE |
+--------------+--------------+--------+

उपरोक्त टोपोलॉजी परिवर्तनों को निम्नलिखित आरेख में दिखाया जा सकता है:

हमने admin-web_enabled=true के साथ वेब आँकड़े UI को भी सक्षम किया है। वेब UI तक पहुँचने के लिए, बस पोर्ट 6080 में डॉकर होस्ट पर जाएँ, उदाहरण के लिए:http://192.168.0.200:8060 और आपको उपयोगकर्ता नाम/पासवर्ड पॉप अप के साथ संकेत दिया जाएगा। admin-stats_credentials के तहत परिभाषित क्रेडेंशियल दर्ज करें और आपको निम्न पृष्ठ देखना चाहिए:

MySQL कनेक्शन पूल टेबल की निगरानी करके, हम सभी होस्टग्रुप के लिए कनेक्शन वितरण अवलोकन प्राप्त कर सकते हैं:

Admin> select hostgroup, srv_host, status, ConnUsed, MaxConnUsed, Queries from stats.stats_mysql_connection_pool order by srv_host;
+-----------+--------------+--------+----------+-------------+---------+
| hostgroup | srv_host     | status | ConnUsed | MaxConnUsed | Queries |
+-----------+--------------+--------+----------+-------------+---------+
| 20        | 192.168.0.23 | ONLINE | 5        | 24          | 11458   |
| 30        | 192.168.0.23 | ONLINE | 0        | 0           | 0       |
| 20        | 192.168.0.22 | ONLINE | 2        | 24          | 11485   |
| 30        | 192.168.0.22 | ONLINE | 0        | 0           | 0       |
| 10        | 192.168.0.21 | ONLINE | 32       | 32          | 9746    |
| 30        | 192.168.0.21 | ONLINE | 0        | 0           | 0       |
+-----------+--------------+--------+----------+-------------+---------+

ऊपर दिए गए आउटपुट से पता चलता है कि होस्टग्रुप 30 कुछ भी प्रोसेस नहीं करता है क्योंकि हमारे क्वेरी नियमों में इस होस्टग्रुप को डेस्टिनेशन होस्टग्रुप के रूप में कॉन्फ़िगर नहीं किया गया है।

गैलेरा नोड्स से संबंधित आंकड़े mysql_server_galera_log तालिका में देखे जा सकते हैं:

Admin>  select * from mysql_server_galera_log order by time_start_us desc limit 3\G
*************************** 1. row ***************************
                       hostname: 192.168.0.23
                           port: 3306
                  time_start_us: 1552992553332489
                success_time_us: 2045
              primary_partition: YES
                      read_only: NO
         wsrep_local_recv_queue: 0
              wsrep_local_state: 4
                   wsrep_desync: NO
           wsrep_reject_queries: NO
wsrep_sst_donor_rejects_queries: NO
                          error: NULL
*************************** 2. row ***************************
                       hostname: 192.168.0.22
                           port: 3306
                  time_start_us: 1552992553329653
                success_time_us: 2799
              primary_partition: YES
                      read_only: NO
         wsrep_local_recv_queue: 0
              wsrep_local_state: 4
                   wsrep_desync: NO
           wsrep_reject_queries: NO
wsrep_sst_donor_rejects_queries: NO
                          error: NULL
*************************** 3. row ***************************
                       hostname: 192.168.0.21
                           port: 3306
                  time_start_us: 1552992553329013
                success_time_us: 2715
              primary_partition: YES
                      read_only: NO
         wsrep_local_recv_queue: 0
              wsrep_local_state: 4
                   wsrep_desync: NO
           wsrep_reject_queries: NO
wsrep_sst_donor_rejects_queries: NO
                          error: NULL

परिणामसेट किसी विशेष टाइमस्टैम्प के लिए प्रत्येक गैलेरा नोड के लिए संबंधित MySQL चर/स्थिति स्थिति देता है। इस कॉन्फ़िगरेशन में, हमने गैलेरा स्वास्थ्य जांच को हर 2 सेकंड में चलाने के लिए कॉन्फ़िगर किया है (monitor_galera_healthcheck_interval=2000)। इसलिए, यदि क्लस्टर में कोई टोपोलॉजी परिवर्तन होता है, तो अधिकतम विफलता समय लगभग 2 सेकंड होगा।

संदर्भ

ProxySQL नेटिव गैलेरा सपोर्ट
HA और क्लस्टरिंग समाधान:Galera और समूह प्रतिकृति के लिए एक बुद्धिमान राउटर के रूप में ProxySQL
प्रॉक्सीएसक्यूएल डॉकर इमेज बाई कईनिन्स
Prometheus और ClusterControl के साथ ProxySQL की निगरानी कैसे करें