MariaDB
 sql >> डेटाबेस >  >> RDS >> MariaDB

कुबेरनेट्स के साथ प्रॉक्सीएसक्यूएल नेटिव क्लस्टरिंग

ProxySQL ने v1.4.2.2 से देशी क्लस्टरिंग का समर्थन किया है। इसका मतलब है कि एकाधिक ProxySQL उदाहरण क्लस्टर-जागरूक हैं; वे एक-दूसरे की स्थिति से अवगत हैं और कॉन्फ़िगरेशन संस्करण, टाइमस्टैम्प और चेकसम मान के आधार पर सबसे अद्यतित कॉन्फ़िगरेशन को सिंक करके स्वचालित रूप से कॉन्फ़िगरेशन परिवर्तनों को संभालने में सक्षम हैं। इस ब्लॉग पोस्ट को देखें जो दर्शाता है कि प्रॉक्सीएसक्यूएल के लिए क्लस्टरिंग समर्थन को कैसे कॉन्फ़िगर किया जाए और आप इसे कैसे व्यवहार करने की उम्मीद कर सकते हैं।

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

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

हालाँकि, तेजी से बदलते परिवेश में, यह ConfigMap दृष्टिकोण शायद सबसे अच्छा तरीका नहीं है क्योंकि नए कॉन्फ़िगरेशन को लोड करने के लिए, ConfigMap वॉल्यूम को रिमाउंट करने के लिए पॉड पुनर्निर्धारण की आवश्यकता होती है और यह ProxySQL सेवा को समग्र रूप से ख़तरे में डाल सकता है। उदाहरण के लिए, मान लें कि हमारे वातावरण में, हमारी सख्त पासवर्ड नीति के लिए हर 7 दिनों के लिए MySQL उपयोगकर्ता पासवर्ड की समाप्ति को बाध्य करने की आवश्यकता होती है, जिसे हमें साप्ताहिक आधार पर नए पासवर्ड के लिए ProxySQL ConfigMap को अपडेट करते रहना होगा। एक साइड नोट के रूप में, प्रॉक्सीएसक्यूएल के अंदर MySQL उपयोगकर्ता को बैकएंड MySQL सर्वर पर एक से मेल खाने के लिए उपयोगकर्ता और पासवर्ड की आवश्यकता होती है। यहीं से हमें Kubernetes में ProxySQL नेटिव क्लस्टरिंग सपोर्ट का उपयोग करना शुरू करना चाहिए, ताकि ConfigMap वर्जनिंग और पॉड रीशेड्यूलिंग की परेशानी के बिना कॉन्फ़िगरेशन परिवर्तनों को स्वचालित रूप से लागू किया जा सके।

इस ब्लॉग पोस्ट में, हम आपको दिखाएंगे कि कुबेरनेट्स पर हेडलेस सेवा के साथ प्रॉक्सीएसक्यूएल देशी क्लस्टरिंग कैसे चलाएं। हमारी उच्च-स्तरीय वास्तुकला को नीचे दिखाया जा सकता है:

हमारे पास 3 गैलेरा नोड हैं जो क्लस्टरकंट्रोल द्वारा तैनात और प्रबंधित बेयर-मेटल इन्फ्रास्ट्रक्चर पर चल रहे हैं:

  • 192.168.0.21
  • 192.168.0.22
  • 192.168.0.23

हमारे सभी एप्लिकेशन कुबेरनेट्स के भीतर पॉड के रूप में चल रहे हैं। रिवर्स प्रॉक्सी के रूप में काम करने के लिए एप्लिकेशन और हमारे डेटाबेस क्लस्टर के बीच दो प्रॉक्सीएसक्यूएल इंस्टेंस को पेश करने का विचार है। अनुप्रयोग तब Kubernetes सेवा के माध्यम से ProxySQL पॉड्स से कनेक्ट होंगे जो कई ProxySQL प्रतिकृतियों में संतुलित और फ़ेलओवर लोड होगा।

हमारे कुबेरनेट्स सेटअप का सारांश निम्नलिखित है:

[email protected]:~# kubectl get nodes -o wide
NAME    STATUS   ROLES    AGE     VERSION   INTERNAL-IP       EXTERNAL-IP   OS-IMAGE             KERNEL-VERSION      CONTAINER-RUNTIME
kube1   Ready    master   5m      v1.15.1   192.168.100.201   <none>        Ubuntu 18.04.1 LTS   4.15.0-39-generic   docker://18.9.7
kube2   Ready    <none>   4m1s    v1.15.1   192.168.100.202   <none>        Ubuntu 18.04.1 LTS   4.15.0-39-generic   docker://18.9.7
kube3   Ready    <none>   3m42s   v1.15.1   192.168.100.203   <none>        Ubuntu 18.04.1 LTS   4.15.0-39-generic   docker://18.9.7

ConfigMap के माध्यम से ProxySQL कॉन्फ़िगरेशन

आइए पहले अपना आधार विन्यास तैयार करें जिसे ConfigMap में लोड किया जाएगा। Proxysql.cnf नामक एक फ़ाइल बनाएँ और निम्नलिखित पंक्तियाँ जोड़ें:

datadir="/var/lib/proxysql"

admin_variables=
{
    admin_credentials="proxysql-admin:adminpassw0rd;cluster1:secret1pass"
    mysql_ifaces="0.0.0.0:6032"
    refresh_interval=2000
    cluster_username="cluster1"
    cluster_password="secret1pass"
    cluster_check_interval_ms=200
    cluster_check_status_frequency=100
    cluster_mysql_query_rules_save_to_disk=true
    cluster_mysql_servers_save_to_disk=true
    cluster_mysql_users_save_to_disk=true
    cluster_proxysql_servers_save_to_disk=true
    cluster_mysql_query_rules_diffs_before_sync=3
    cluster_mysql_servers_diffs_before_sync=3
    cluster_mysql_users_diffs_before_sync=3
    cluster_proxysql_servers_diffs_before_sync=3
}

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="proxysqlpassw0rd"
    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="192.168.0.21" , port=3306 , hostgroup=10, max_connections=100 },
    { address="192.168.0.22" , port=3306 , hostgroup=10, max_connections=100 },
    { address="192.168.0.23" , 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=20
        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 }
)

proxysql_servers =
(
    { hostname = "proxysql-0.proxysqlcluster", port = 6032, weight = 1 },
    { hostname = "proxysql-1.proxysqlcluster", port = 6032, weight = 1 }
)

ऊपर दी गई कुछ कॉन्फ़िगरेशन लाइनों को प्रति सेक्शन नीचे समझाया गया है:

admin_variables

admin_credentials पर ध्यान दें वेरिएबल जहां हमने गैर-डिफ़ॉल्ट उपयोगकर्ता का उपयोग किया जो "proxysql-admin" है। ProxySQL स्थानीय कनेक्शन के लिए केवल लोकलहोस्ट के माध्यम से डिफ़ॉल्ट "व्यवस्थापक" उपयोगकर्ता को सुरक्षित रखता है। इसलिए, हमें प्रॉक्सीएसक्यूएल इंस्टेंस को दूरस्थ रूप से एक्सेस करने के लिए अन्य उपयोगकर्ताओं का उपयोग करना होगा। अन्यथा, आपको निम्न त्रुटि प्राप्त होगी:

ERROR 1040 (42000): User 'admin' can only connect locally

हमने cluster_username . को भी जोड़ा है और cluster_password admin_credentials . में मान स्वचालित समन्वयन की अनुमति देने के लिए अर्धविराम द्वारा अलग की गई पंक्ति। cluster_* . के साथ पहले लगे सभी वेरिएबल ProxySQL देशी क्लस्टरिंग से संबंधित हैं और स्व-व्याख्यात्मक हैं।

mysql_galera_hostgroups

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

mysql_servers

सभी लाइनें स्व-व्याख्यात्मक हैं, जो कि MySQL गैलेरा क्लस्टर में चल रहे तीन डेटाबेस सर्वरों पर आधारित है, जैसा कि क्लस्टरकंट्रोल से लिए गए निम्नलिखित टोपोलॉजी स्क्रीनशॉट में संक्षेप में दिया गया है:

proxysql_servers

यहां हम ProxySQL साथियों की सूची परिभाषित करते हैं:

  • होस्टनाम - पीयर का होस्टनाम/आईपी पता
  • पोर्ट - पीयर का एडमिन पोर्ट
  • वजन - वर्तमान में अप्रयुक्त, लेकिन भविष्य में सुधार के लिए रोडमैप में
  • टिप्पणी - फ्री फॉर्म कमेंट फील्ड

Docker/Kubernetes वातावरण में, कंटेनर होस्टनाम या IP पतों को खोजने और लिंक करने और उन्हें इस तालिका में सम्मिलित करने के कई तरीके हैं, या तो ConfigMap, मैन्युअल इंसर्ट, entrypoint.sh स्क्रिप्टिंग, पर्यावरण चर या कुछ अन्य माध्यमों का उपयोग करके। Kubernetes में, उपयोग किए गए प्रतिकृति नियंत्रक या परिनियोजन विधि के आधार पर, पॉड के हल करने योग्य होस्टनाम का पहले से अनुमान लगाना थोड़ा मुश्किल है, जब तक कि आप StatefulSet पर नहीं चल रहे हों।

स्टेटफुलस्टेट पॉड ऑर्डिनल इंडेक्स पर इस ट्यूटोरियल को देखें जो बनाए गए पॉड्स के लिए एक स्थिर रिजॉल्वेबल होस्टनाम प्रदान करता है। इसे हेडलेस सर्विस (आगे नीचे समझाया गया) के साथ मिलाएं, हल करने योग्य होस्टनाम प्रारूप होगा:

{app_name}-{index_number}.{service}

जहां {service} एक हेडलेस सर्विस है, जो बताती है कि "proxysql-0.proxysqlcluster" और "proxysql-1.proxysqlcluster" कहां से आते हैं। यदि आप 2 से अधिक प्रतिकृतियां रखना चाहते हैं, तो स्टेटफुलसेट एप्लिकेशन नाम के सापेक्ष आरोही अनुक्रमणिका संख्या जोड़कर तदनुसार अधिक प्रविष्टियां जोड़ें।

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

$ kubectl create configmap proxysql-configmap --from-file=proxysql.cnf

सत्यापित करें कि क्या हमारा ConfigMap सही ढंग से लोड किया गया है:

$ kubectl get configmap
NAME                 DATA   AGE
proxysql-configmap   1      7h57m

ProxySQL मॉनिटरिंग उपयोगकर्ता बनाना

परिनियोजन शुरू करने से पहले अगला कदम हमारे डेटाबेस क्लस्टर में एक प्रॉक्सीएसक्यूएल निगरानी उपयोगकर्ता बनाना है। चूंकि हम गैलेरा क्लस्टर पर चल रहे हैं, गैलेरा नोड्स में से किसी एक पर निम्नलिखित कथन चलाएँ:

mysql> CREATE USER 'proxysql'@'%' IDENTIFIED BY 'proxysqlpassw0rd';
mysql> GRANT USAGE ON *.* TO 'proxysql'@'%';

यदि आपने MySQL उपयोगकर्ता नहीं बनाए हैं (जैसा कि ऊपर mysql_users अनुभाग में निर्दिष्ट किया गया है), तो हमें उन्हें भी बनाना होगा:

mysql> CREATE USER 'wordpress'@'%' IDENTIFIED BY 'passw0rd';
mysql> GRANT ALL PRIVILEGES ON wordpress.* TO 'wordpress'@'%';
mysql> CREATE USER 'sbtest'@'%' IDENTIFIED BY 'passw0rd';
mysql> GRANT ALL PRIVILEGES ON sbtest.* TO 'proxysql'@'%';

यही बात है। अब हम परिनियोजन शुरू करने के लिए तैयार हैं।

एक स्टेटफुलसेट परिनियोजित करना

हम स्टेटफुलसेट का उपयोग करते हुए दो ProxySQL इंस्टेंस, या रिडंडेंसी उद्देश्यों के लिए प्रतिकृतियां बनाकर शुरू करेंगे।

चलिए एक टेक्स्ट फ़ाइल बनाकर शुरू करते हैं जिसे proxysql-ss-svc.yml कहा जाता है और निम्नलिखित पंक्तियाँ जोड़ें:

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: proxysql
  labels:
    app: proxysql
spec:
  replicas: 2
  serviceName: proxysqlcluster
  selector:
    matchLabels:
      app: proxysql
      tier: frontend
  updateStrategy:
    type: RollingUpdate
  template:
    metadata:
      labels:
        app: proxysql
        tier: frontend
    spec:
      restartPolicy: Always
      containers:
      - image: severalnines/proxysql:2.0.4
        name: proxysql
        volumeMounts:
        - name: proxysql-config
          mountPath: /etc/proxysql.cnf
          subPath: proxysql.cnf
        ports:
        - containerPort: 6033
          name: proxysql-mysql
        - containerPort: 6032
          name: proxysql-admin
      volumes:
      - name: proxysql-config
        configMap:
          name: proxysql-configmap
---
apiVersion: v1
kind: Service
metadata:
  annotations:
  labels:
    app: proxysql
    tier: frontend
  name: proxysql
spec:
  ports:
  - name: proxysql-mysql
    nodePort: 30033
    port: 6033
    protocol: TCP
    targetPort: 6033
  - name: proxysql-admin
    nodePort: 30032
    port: 6032
    protocol: TCP
    targetPort: 6032
  selector:
    app: proxysql
    tier: frontend
  type: NodePort

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

ProxySQL स्टेटफुल सेट और सर्विस बनाएं:

$ kubectl create -f proxysql-ss-svc.yml

पॉड और सेवा की स्थिति की पुष्टि करें:

$ kubectl get pods,svc
NAME             READY   STATUS    RESTARTS   AGE
pod/proxysql-0   1/1     Running   0          4m46s
pod/proxysql-1   1/1     Running   0          2m59s

NAME                      TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)                         AGE
service/kubernetes        ClusterIP   10.96.0.1        <none>        443/TCP                         10h
service/proxysql          NodePort    10.111.240.193   <none>        6033:30033/TCP,6032:30032/TCP   5m28s

यदि आप पॉड के लॉग को देखते हैं, तो आप देखेंगे कि हम इस चेतावनी से भर गए हैं:

$ kubectl logs -f proxysql-0
...
2019-08-01 19:06:18 ProxySQL_Cluster.cpp:215:ProxySQL_Cluster_Monitor_thread(): [WARNING] Cluster: unable to connect to peer proxysql-1.proxysqlcluster:6032 . Error: Unknown MySQL server host 'proxysql-1.proxysqlcluster' (0)

उपरोक्त का सीधा सा मतलब है कि प्रॉक्सीएसक्यूएल-0 "proxysql-1.proxysqlcluster" को हल करने और उससे कनेक्ट करने में असमर्थ था, जो कि अपेक्षित है क्योंकि हमने DNS रिकॉर्ड्स के लिए हमारी हेडलेस सेवा नहीं बनाई है जो इंटर-प्रॉक्सीएसक्यूएल संचार के लिए आवश्यक हैं।

कुबेरनेट्स हेडलेस सर्विस

ProxySQL पॉड्स प्रत्याशित FQDN को हल करने और इसे सीधे कनेक्ट करने में सक्षम होने के लिए, समाधान प्रक्रिया को असाइन किए गए लक्ष्य पॉड IP पते को देखने में सक्षम होना चाहिए न कि वर्चुअल IP पता। यह वह जगह है जहां हेडलेस सर्विस तस्वीर में आती है। "क्लस्टरआईपी =कोई नहीं" सेट करके एक हेडलेस सेवा बनाते समय, कोई लोड-बैलेंसिंग कॉन्फ़िगर नहीं किया गया है और इस सेवा के लिए कोई क्लस्टर आईपी (वर्चुअल आईपी) आवंटित नहीं किया गया है। केवल DNS स्वचालित रूप से कॉन्फ़िगर किया गया है। जब आप हेडलेस सेवा के लिए DNS क्वेरी चलाते हैं, तो आपको पॉड्स के आईपी पते की सूची मिल जाएगी।

यदि हम "proxysqlcluster" के लिए हेडलेस सर्विस DNS रिकॉर्ड्स को देखें तो यह ऐसा दिखता है (इस उदाहरण में हमारे पास 3 ProxySQL इंस्टेंस थे):

$ host proxysqlcluster
proxysqlcluster.default.svc.cluster.local has address 10.40.0.2
proxysqlcluster.default.svc.cluster.local has address 10.40.0.3
proxysqlcluster.default.svc.cluster.local has address 10.32.0.2

जबकि निम्न आउटपुट "proxysql" नामक मानक सेवा के लिए DNS रिकॉर्ड दिखाता है जो क्लस्टरआईपी को हल करता है:

$ host proxysql
proxysql.default.svc.cluster.local has address 10.110.38.154

एक हेडलेस सर्विस बनाने और इसे पॉड्स से जोड़ने के लिए, स्टेटफुलसेट डिक्लेरेशन के अंदर सर्विसनाम को परिभाषित करना होगा, और सर्विस डेफिनिशन में "क्लस्टरआईपी =कोई नहीं" होना चाहिए जैसा कि नीचे दिखाया गया है। Proxysql-headless-svc.yml नाम से एक टेक्स्ट फ़ाइल बनाएँ और निम्न पंक्तियाँ जोड़ें:

apiVersion: v1
kind: Service
metadata:
  name: proxysqlcluster
  labels:
    app: proxysql
spec:
  clusterIP: None
  ports:
  - port: 6032
    name: proxysql-admin
  selector:
    app: proxysql

बिना सिर वाली सेवा बनाएं:

$ kubectl create -f proxysql-headless-svc.yml

केवल सत्यापन के लिए, इस समय, हमारे पास निम्नलिखित सेवाएं चल रही हैं:

$ kubectl get svc
NAME              TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)                         AGE
kubernetes        ClusterIP   10.96.0.1       <none>        443/TCP                         8h
proxysql          NodePort    10.110.38.154   <none>        6033:30033/TCP,6032:30032/TCP   23m
proxysqlcluster   ClusterIP   None            <none>        6032/TCP                        4s

अब, हमारे पॉड के लॉग में से एक को देखें:

$ kubectl logs -f proxysql-0
...
2019-08-01 19:06:19 ProxySQL_Cluster.cpp:215:ProxySQL_Cluster_Monitor_thread(): [WARNING] Cluster: unable to connect to peer proxysql-1.proxysqlcluster:6032 . Error: Unknown MySQL server host 'proxysql-1.proxysqlcluster' (0)
2019-08-01 19:06:19 [INFO] Cluster: detected a new checksum for mysql_query_rules from peer proxysql-1.proxysqlcluster:6032, version 1, epoch 1564686376, checksum 0x3FEC69A5C9D96848 . Not syncing yet ...
2019-08-01 19:06:19 [INFO] Cluster: checksum for mysql_query_rules from peer proxysql-1.proxysqlcluster:6032 matches with local checksum 0x3FEC69A5C9D96848 , we won't sync.

आप देखेंगे कि क्लस्टर घटक "proxysqlcluster" नामक हेडलेस सेवा के माध्यम से पोर्ट 6032 पर अन्य सहकर्मी, proxysql-1.proxysqlcluster से एक नए चेकसम को हल करने, कनेक्ट करने और पहचानने में सक्षम है। ध्यान दें कि यह सेवा केवल कुबेरनेट्स नेटवर्क के भीतर पोर्ट 6032 को उजागर करती है, इसलिए यह बाहरी रूप से पहुंच योग्य नहीं है।

इस बिंदु पर, हमारा परिनियोजन अब पूरा हो गया है।

ProxySQL से कनेक्ट हो रहा है

ProxySQL सेवाओं से जुड़ने के कई तरीके हैं। लोड-संतुलित MySQL कनेक्शन कुबेरनेट्स नेटवर्क के भीतर से पोर्ट 6033 पर भेजे जाने चाहिए और यदि क्लाइंट बाहरी नेटवर्क से कनेक्ट हो रहा है तो पोर्ट 30033 का उपयोग करें।

बाहरी नेटवर्क से ProxySQL व्यवस्थापक इंटरफ़ेस से कनेक्ट करने के लिए, हम NodePort सेक्शन के तहत परिभाषित पोर्ट से कनेक्ट कर सकते हैं, 30032 (192.168.100.203 होस्ट kube3.local का प्राथमिक IP पता है):

$ mysql -uproxysql-admin -padminpassw0rd -h192.168.100.203 -P30032

यदि आप कुबेरनेट्स नेटवर्क में अन्य पॉड्स से इसे एक्सेस करना चाहते हैं, तो पोर्ट 6032 पर क्लस्टरआईपी 10.110.38.154 ("प्रॉक्सीस्क्ल" सेवा के तहत परिभाषित) का उपयोग करें।

फिर अपनी इच्छानुसार ProxySQL कॉन्फ़िगरेशन परिवर्तन करें और उन्हें रनटाइम पर लोड करें:

mysql> INSERT INTO mysql_users (username,password,default_hostgroup) VALUES ('newuser','passw0rd',10);
mysql> LOAD MYSQL USERS TO RUNTIME;

आप पॉड्स में से किसी एक में निम्न पंक्तियाँ देखेंगे जो दर्शाती हैं कि कॉन्फ़िगरेशन सिंकिंग पूर्ण हो गई है:

$ kubectl logs -f proxysql-0
...
2019-08-02 03:53:48 [INFO] Cluster: detected a peer proxysql-1.proxysqlcluster:6032 with mysql_users version 2, epoch 1564718027, diff_check 4. Own version: 1, epoch: 1564714803. Proceeding with remote sync
2019-08-02 03:53:48 [INFO] Cluster: detected peer proxysql-1.proxysqlcluster:6032 with mysql_users version 2, epoch 1564718027
2019-08-02 03:53:48 [INFO] Cluster: Fetching MySQL Users from peer proxysql-1.proxysqlcluster:6032 started
2019-08-02 03:53:48 [INFO] Cluster: Fetching MySQL Users from peer proxysql-1.proxysqlcluster:6032 completed

ध्यान रखें कि स्वचालित सिंकिंग केवल तभी होती है जब ProxySQL रनटाइम में कॉन्फ़िगरेशन परिवर्तन होता है। इसलिए, कार्रवाई देखने से पहले "LOAD ... TO RUNTIME" कथन चलाना महत्वपूर्ण है। दृढ़ता के लिए ProxySQL परिवर्तनों को डिस्क में सहेजना न भूलें:

mysql> SAVE MYSQL USERS TO DISK;

सीमा

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

संपत कामिनेनी का विशेष धन्यवाद, जिन्होंने इस ब्लॉग पोस्ट के विचार को जन्म दिया और उपयोग के मामलों और कार्यान्वयन के बारे में जानकारी प्रदान की।


  1. Database
    2.   
  2. Mysql
    3.   
  3. Oracle
    4.   
  4. Sqlserver
    5.   
  5. PostgreSQL
    6.   
  6. Access
    7.   
  7. SQLite
    8.   
  8. MariaDB

  1. मारियाडीबी में ADDTIME () कैसे काम करता है?

  2. मारियाडीबी सर्वर के साथ मायरॉक्स स्टोरेज इंजन का उपयोग करना

  3. मारियाडीबी बेंचमार्क () समझाया गया

  4. कैसे CONCAT () मारियाडीबी में काम करता है

  5. कैसे SOUNDEX () मारियाडीबी में काम करता है