Loading blog...

MySQL उत्पादन में उच्च उपलब्धता: InnoDB क्लस्टर, समूह प्रतिकृति, और Kubernetes ऑपरेटर

InnoDB क्लस्टर, ग्रुप प्रतिकृति, Kubernetes के लिए MySQL ऑपरेटर, पेरकोना एक्स्ट्राDB क्लस्टर, मल्टी-क्लाउड रणनीतियों और लॉन्गहॉर्न स्टोरेज के साथ बेयर मेटल k3s/रंचर परिनियोजन के लिए एक प्रोडक्शन इंजीनियर की मार्गदर्शिका

Balinder Walia12 अप्रैल 202629 min read

उत्पादन में MySQL चलाना अधिकांश इंजीनियरिंग टीमों के लिए परिचित क्षेत्र है। इसे वास्तविक उच्च उपलब्धता के साथ चलाने के लिए - जहां एक नोड विफलता, एक नेटवर्क विभाजन, या संपूर्ण उपलब्धता क्षेत्र अंधेरा हो जाता है, जिसके परिणामस्वरूप डाउनटाइम या डेटा हानि नहीं होती है - जानबूझकर वास्तुकला की आवश्यकता होती है। यह मार्गदर्शिका उस आर्किटेक्चर की हर परत से गुजरती है: MySQL के अंदर प्रतिकृति प्राइमेटिव्स से, Kubernetes ऑपरेटरों के माध्यम से जो जीवनचक्र प्रबंधन को स्वचालित करते हैं, हर प्रमुख क्लाउड प्रदाता पर प्रबंधित और स्व-प्रबंधित विकल्पों के माध्यम से, और रंचर द्वारा प्रबंधित नंगे धातु k3s क्लस्टर तक।

इस लेख के अंत तक आपके पास उत्पादन में MySQL HA को चुनने और संचालित करने के लिए एक संपूर्ण मानसिक मॉडल होगा, साथ ही ठोस कॉन्फ़िगरेशन उदाहरणों के साथ आप अपने स्वयं के वातावरण को अनुकूलित कर सकते हैं।

MySQL InnoDB क्लस्टर आर्किटेक्चर

InnoDB क्लस्टर MySQL के लिए Oracle का एकीकृत उच्च उपलब्धता समाधान है। यह तीन घटकों को जोड़ती है: डेटा सिंक्रनाइज़ेशन के लिए MySQL समूह प्रतिकृति, क्लस्टर प्रशासन के लिए MySQL शेल, और पारदर्शी कनेक्शन रूटिंग और स्वचालित विफलता के लिए MySQL राउटर। साथ में वे एक स्व-उपचार क्लस्टर बनाते हैं जो मैन्युअल हस्तक्षेप के बिना नोड विफलताओं को सहन कर सकता है।

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

समूह प्रतिकृति मूल बातें

MySQL ग्रुप प्रतिकृति InnoDB क्लस्टर की नींव है। यह यह सुनिश्चित करने के लिए पैक्सोस-आधारित सर्वसम्मति प्रोटोकॉल का उपयोग करता है कि प्राथमिक पर किए गए प्रत्येक लेनदेन को स्वीकार किए जाने से पहले अधिकांश नोड्स में दोहराया जाता है। यहवर्चुअल सिंक्रोनस प्रतिकृतिप्रदान करता है - एक गारंटी है कि प्रतिबद्धता के समय कम से कम अधिकांश क्लस्टर सदस्यों पर प्रतिबद्ध डेटा मौजूद है।

समूह प्रतिकृति दो मोड में संचालित होती है:

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

MySQL शेल

के साथ InnoDB क्लस्टर की स्थापना

MySQL शेल, AdminAPI प्रदान करता है, जो फ़ंक्शंस का एक सेट है जो संपूर्ण क्लस्टर जीवनचक्र को स्वचालित करता है। यहां 3-नोड क्लस्टर के लिए संपूर्ण सेटअप अनुक्रम है।

# Step 1: Prepare each MySQL instance (run on all 3 nodes)
# Ensure my.cnf has required settings
[mysqld]
server-id=1                          # unique per node: 1, 2, 3
gtid_mode=ON
enforce_gtid_consistency=ON
binlog_checksum=NONE
binlog_transaction_dependency_tracking=WRITESET
transaction_write_set_extraction=XXHASH64
loose-group_replication_start_on_boot=OFF
plugin_load_add='group_replication.so'
plugin_load_add='mysql_clone.so'
report_host='mysql-node-1'           # unique per node

# Step 2: Use MySQL Shell to configure and create the cluster
mysqlsh -- dba configure-instance root@mysql-node-1:3306 --clusterAdmin=gradmin --clusterAdminPassword='SecurePass123!'
mysqlsh -- dba configure-instance root@mysql-node-2:3306 --clusterAdmin=gradmin --clusterAdminPassword='SecurePass123!'
mysqlsh -- dba configure-instance root@mysql-node-3:3306 --clusterAdmin=gradmin --clusterAdminPassword='SecurePass123!'

# Step 3: Connect to the first node and create the cluster
mysqlsh gradmin@mysql-node-1:3306
# Inside MySQL Shell:
var cluster = dba.createCluster('productionCluster', {
    memberWeight: 90,
    exitStateAction: 'ABORT_SERVER',
    consistency: 'BEFORE_ON_PRIMARY_FAILOVER',
    expelTimeout: 10
})

# Step 4: Add remaining nodes
cluster.addInstance('gradmin@mysql-node-2:3306', {recoveryMethod: 'clone'})
cluster.addInstance('gradmin@mysql-node-3:3306', {recoveryMethod: 'clone'})

# Step 5: Verify cluster status
cluster.status()

recoveryMethod: 'clone'विकल्प प्राथमिक से जुड़ने वाले सदस्य तक पूर्ण डेटा कॉपी करने के लिए MySQL क्लोन प्लगइन का उपयोग करता है, जो बड़े डेटासेट के लिए बाइनरी लॉग से वृद्धिशील पुनर्प्राप्ति से कहीं अधिक तेज़ है।

MySQL राउटर कॉन्फ़िगरेशन

MySQL राउटर क्लस्टर के विरुद्ध बूटस्ट्रैप किया गया है और स्वचालित रूप से इसकी कॉन्फ़िगरेशन फ़ाइल उत्पन्न करता है।

# Bootstrap MySQL Router against the cluster
mysqlrouter --bootstrap gradmin@mysql-node-1:3306 \
  --directory /opt/mysqlrouter \
  --conf-use-sockets \
  --user=mysqlrouter \
  --name='production-router'

# Start MySQL Router
/opt/mysqlrouter/start.sh

# Default ports after bootstrap:
# 6446 — R/W (routes to primary)
# 6447 — R/O (round-robin across secondaries)
# 6448 — R/W (X Protocol)
# 6449 — R/O (X Protocol)

एप्लिकेशन लिखने के लिए राउटर के R/W पोर्ट और रीड प्रतिकृतियों के लिए R/O पोर्ट से कनेक्ट होते हैं। जब प्राथमिक विफल हो जाता है, तो राउटर टोपोलॉजी परिवर्तन का पता लगाता है और सेकंड के भीतर पुन: रूट करता है।

बहु-क्षेत्र MySQL परिनियोजन

विभिन्न भौगोलिक क्षेत्रों में आपदा पुनर्प्राप्ति और कम-विलंबता रीडिंग के लिए, MySQL को कई क्षेत्रों में तैनात किया जा सकता है। InnoDB क्लस्टरसेट प्राथमिक क्लस्टर और विभिन्न क्षेत्रों में एक या अधिक प्रतिकृति क्लस्टर के बीच अतुल्यकालिक प्रतिकृति का समर्थन करने के लिए InnoDB क्लस्टर का विस्तार करता है।

InnoDB क्लस्टरसेट एक प्राथमिक क्लस्टर के साथ संचालित होता है जो सभी लेखन को संभालता है, और एक या अधिक प्रतिकृति क्लस्टर जो अतुल्यकालिक रूप से परिवर्तन प्राप्त करते हैं। आपदा परिदृश्य में, एक प्रतिकृति क्लस्टर को MySQL शेल के माध्यम से प्राथमिक में पदोन्नत किया जा सकता है।

# Create a ClusterSet from an existing InnoDB Cluster
mysqlsh gradmin@mysql-node-1:3306
var cluster = dba.getCluster()
var cs = cluster.createClusterSet('globalSet')

# Create a replica cluster in eu-west region
cs.createReplicaCluster('gradmin@mysql-eu-node-1:3306', 'euWestCluster', {
    recoveryMethod: 'clone'
})
var euCluster = cs.getCluster('euWestCluster')
euCluster.addInstance('gradmin@mysql-eu-node-2:3306', {recoveryMethod: 'clone'})
euCluster.addInstance('gradmin@mysql-eu-node-3:3306', {recoveryMethod: 'clone'})

# Emergency failover (when primary cluster is unreachable)
cs.forcePrimaryCluster('euWestCluster')

Kubernetes पर

MySQL — ऑपरेटर पैटर्न

Kubernetes ऑपरेटर इस डोमेन-विशिष्ट परिचालन ज्ञान को एक नियंत्रक में एन्कोड करते हैं जो कस्टम संसाधनों पर नज़र रखता है और MySQL की वास्तविक स्थिति को YAML में घोषित वांछित स्थिति में समेटता है।

Kubernetes (Oracle)के लिए

MySQL ऑपरेटर Kubernetes के लिए

Oracle का MySQL ऑपरेटर मूल रूप से Kubernetes पर InnoDB क्लस्टर इंस्टेंस को तैनात और प्रबंधित करता है। यह MySQL सर्वर पॉड के लिए स्टेटफुलसेट, MySQL राउटर के लिए परिनियोजन बनाता है, और स्वचालित विफलता, स्केलिंग, बैकअप और कॉन्फ़िगरेशन परिवर्तनों को संभालता है।

# Install the MySQL Operator via Helm
helm repo add mysql-operator https://mysql.github.io/mysql-operator/
helm repo update

helm install mysql-operator mysql-operator/mysql-operator \
  --namespace mysql-operator \
  --create-namespace \
  --set image.pullPolicy=IfNotPresent

एक बार जब ऑपरेटर चल रहा हो, तो एक कस्टम संसाधन बनाकर एक InnoDB क्लस्टर तैनात करें।

apiVersion: v1
kind: Secret
metadata:
  name: mysql-root-credentials
  namespace: production
stringData:
  rootUser: root
  rootHost: '%'
  rootPassword: 'ProductionSecurePass123!'
---
apiVersion: mysql.oracle.com/v2
kind: InnoDBCluster
metadata:
  name: production-mysql
  namespace: production
spec:
  secretName: mysql-root-credentials
  instances: 3
  tlsUseSelfSigned: true
  router:
    instances: 2
  datadirVolumeClaimTemplate:
    accessModes:
      - ReadWriteOnce
    resources:
      requests:
        storage: 100Gi
    storageClassName: gp3-encrypted
  mycnf: |
    [mysqld]
    innodb_buffer_pool_size=4G
    innodb_log_file_size=1G
    innodb_flush_log_at_trx_commit=1
    sync_binlog=1
    max_connections=500
    innodb_io_capacity=2000
    innodb_io_capacity_max=4000
    innodb_read_io_threads=8
    innodb_write_io_threads=8
    performance_schema=ON
    slow_query_log=ON
    long_query_time=1
  podSpec:
    containers:
      - name: mysql
        resources:
          requests:
            cpu: "2"
            memory: 8Gi
          limits:
            cpu: "4"
            memory: 16Gi
    affinity:
      podAntiAffinity:
        requiredDuringSchedulingIgnoredDuringExecution:
          - labelSelector:
              matchExpressions:
                - key: component
                  operator: In
                  values: [mysqld]
            topologyKey: topology.kubernetes.io/zone

पॉड एंटी-एफ़िनिटी नियम यह सुनिश्चित करता है कि MySQL पॉड उपलब्धता क्षेत्रों में फैले हुए हैं, जो ज़ोन-स्तरीय दोष सहनशीलता प्रदान करते हैं।mycnfब्लॉक आपको सीधे सीआर के माध्यम से उत्पादन-ट्यून किए गए MySQL कॉन्फ़िगरेशन को इंजेक्ट करने की अनुमति देता है।

MySQL (PXC)

के लिए

पेरकोना ऑपरेटर MySQL के लिए

पेरकोना ऑपरेटर गैलेरा पर आधारित एक बहु-प्राथमिक सिंक्रोनस प्रतिकृति समाधान, पेरकोना एक्स्ट्राडीबी क्लस्टर (पीएक्ससी) को तैनात करता है। PXC InnoDB क्लस्टर से इस मायने में भिन्न है कि प्रत्येक नोड राइट्स (वास्तविक बहु-प्राथमिक) स्वीकार कर सकता है, और प्रतिकृति wsrep API का उपयोग करके प्रमाणन स्तर पर समकालिक है।

# Install Percona Operator
helm repo add percona https://percona.github.io/percona-helm-charts/
helm repo update

helm install pxc-operator percona/pxc-operator \
  --namespace pxc \
  --create-namespace

# Percona XtraDB Cluster Custom Resource
apiVersion: pxc.percona.com/v1
kind: PerconaXtraDBCluster
metadata:
  name: production-pxc
  namespace: pxc
spec:
  crVersion: '1.14.0'
  secretsName: pxc-secrets
  pxc:
    size: 3
    image: percona/percona-xtradb-cluster:8.0.35
    resources:
      requests:
        memory: 8Gi
        cpu: "2"
      limits:
        memory: 16Gi
        cpu: "4"
    volumeSpec:
      persistentVolumeClaim:
        storageClassName: gp3-encrypted
        accessModes: [ReadWriteOnce]
        resources:
          requests:
            storage: 200Gi
    affinity:
      antiAffinityTopologyKey: topology.kubernetes.io/zone
    configuration: |
      [mysqld]
      innodb_buffer_pool_size=4G
      innodb_flush_log_at_trx_commit=1
      wsrep_provider_options="gcache.size=2G; gcs.fc_limit=256"
      wsrep_slave_threads=8
      wsrep_certify_nonPK=1
      wsrep_trx_fragment_size=10M
      max_connections=500
  haproxy:
    enabled: true
    size: 3
    image: percona/haproxy:2.8.5
    resources:
      requests:
        memory: 1Gi
        cpu: 500m
  proxysql:
    enabled: false
  backup:
    image: percona/percona-xtradb-cluster-operator:1.14.0-pxc8.0-backup-pxb8.0.35
    storages:
      s3-backup:
        type: s3
        verifyTLS: true
        s3:
          bucket: production-mysql-backups
          region: us-east-1
          credentialsSecret: aws-s3-credentials
    schedule:
      - name: daily-full
        schedule: "0 3 * * *"
        keep: 7
        storageName: s3-backup
      - name: hourly-incremental
        schedule: "0 * * * *"
        keep: 24
        storageName: s3-backup

पेरकोना ऑपरेटर S3 के लिए स्वचालित बैकअप, पॉइंट-इन-टाइम रिकवरी, रोलिंग अपग्रेड और कनेक्शन रूटिंग के लिए ProxySQL या HAProxy को संभालता है। पीएक्ससी में गैलेरा-आधारित प्रतिकृति सही सिंक्रोनस मल्टी-प्राइमरी राइट्स प्रदान करती है - प्रत्येक प्रतिबद्ध लेनदेन को सभी नोड्स पर मौजूद होने की गारंटी है।

कनेक्शन रूटिंग: MySQL राउटर बनाम ProxySQL

MySQL राउटर और ProxySQL दोनों डेटाबेस प्रॉक्सी के रूप में काम करते हैं, लेकिन उनकी ताकत अलग-अलग होती है।

MySQL राउटरInnoDB क्लस्टर के लिए उद्देश्य से बनाया गया है। यह क्लस्टर मेटाडेटा को पढ़ता है, टोपोलॉजी परिवर्तनों को ट्रैक करता है, और कनेक्शन को सही प्राथमिक या द्वितीयक तक रूट करता है। इसका कॉन्फ़िगरेशन न्यूनतम है और यह MySQL पारिस्थितिकी तंत्र के साथ सहजता से एकीकृत होता है। नकारात्मक पक्ष सीमित क्वेरी-स्तरीय रूटिंग है - यह कनेक्शन स्तर पर संचालित होता है, क्वेरी स्तर पर नहीं।

ProxySQLउन्नत सुविधाओं के साथ एक सामान्य प्रयोजन MySQL प्रॉक्सी है: क्वेरी-स्तरीय रीड/राइट स्प्लिटिंग, क्वेरी कैशिंग, कनेक्शन मल्टीप्लेक्सिंग, क्वेरी रीराइटिंग और परिष्कृत रूटिंग नियम। यह उन वातावरणों में उत्कृष्टता प्राप्त करता है जहां आपको प्रश्नों को वितरित करने के तरीके पर सूक्ष्म नियंत्रण की आवश्यकता होती है।

# ProxySQL configuration for read/write splitting
# proxysql.cnf

mysql_servers:
(
    { hostgroup_id=10, hostname="mysql-primary", port=3306, max_connections=200, weight=1000 },
    { hostgroup_id=20, hostname="mysql-secondary-1", port=3306, max_connections=200, weight=500 },
    { hostgroup_id=20, hostname="mysql-secondary-2", port=3306, max_connections=200, weight=500 }
)

mysql_query_rules:
(
    { rule_id=1, active=1, match_digest="^SELECT .* FOR UPDATE$", destination_hostgroup=10, apply=1 },
    { rule_id=2, active=1, match_digest="^SELECT", destination_hostgroup=20, apply=1 },
    { rule_id=3, active=1, match_digest=".*", destination_hostgroup=10, apply=1 }
)

mysql_replication_hostgroups:
(
    { writer_hostgroup=10, reader_hostgroup=20, comment="InnoDB Cluster" }
)

Kubernetes वातावरण में, ProxySQL आपके एप्लिकेशन पॉड्स में एक साइडकार कंटेनर के रूप में या एक समर्पित परिनियोजन के रूप में चल सकता है। इसे साइडकार के रूप में चलाने से नेटवर्क हॉप समाप्त हो जाता है लेकिन पॉड संसाधन उपयोग बढ़ जाता है; एक समर्पित तैनाती को बड़े पैमाने पर प्रबंधित करना आसान है।

क्लाउड प्रदाता तुलना: प्रबंधित बनाम स्व-प्रबंधित

AWS: RDS मल्टी-AZ बनाम ऑरोरा बनाम EKS

पर स्व-प्रबंधित

Amazon RDS मल्टी-AZविभिन्न उपलब्धता क्षेत्रों में प्राथमिक और स्टैंडबाय इंस्टेंस के बीच स्वचालित विफलता प्रदान करता है। फ़ेलओवर में आमतौर पर 60-120 सेकंड लगते हैं। यह स्टैंडबाय में समकालिक भौतिक प्रतिकृति का उपयोग करता है। रीड स्केलिंग के लिए रीड प्रतिकृतियां जोड़ी जा सकती हैं लेकिन वे अतुल्यकालिक प्रतिकृति का उपयोग करते हैं। आरडीएस बैकअप, पैचिंग और मॉनिटरिंग को संभालता है लेकिन MySQL कॉन्फ़िगरेशन और संस्करण चयन पर आपके नियंत्रण को सीमित करता है।

अमेज़न ऑरोरा MySQLMySQL स्टोरेज इंजन का क्लाउड-नेटिव रीराइट है। यह गणना को भंडारण से अलग करता है - भंडारण परत एक वितरित, दोष-सहिष्णु प्रणाली है जो तीन एज़ेड में छह तरीकों से डेटा की नकल करती है। ऑरोरा 10-सेकंड से कम का फेलओवर, न्यूनतम प्रतिकृति अंतराल के साथ 15 पढ़ी गई प्रतिकृतियां और 128 टीआईबी तक स्वचालित भंडारण स्केलिंग प्रदान करता है। ऑरोरा सर्वरलेस v2 अप्रत्याशित कार्यभार के लिए स्वचालित गणना स्केलिंग जोड़ता है। ट्रेड-ऑफ लागत है (ऑरोरा आरडीएस की तुलना में 20-40% अधिक महंगा है) और कुछ MySQL सुविधाओं के साथ संगतता कम हो गई है।

EKSपर स्व-प्रबंधित आपको MySQL संस्करण, कॉन्फ़िगरेशन और प्रतिकृति टोपोलॉजी पर पूर्ण नियंत्रण देता है। इसका उपयोग तब करें जब आपको विशिष्ट MySQL सुविधाओं की आवश्यकता हो जो प्रबंधित सेवाओं में उपलब्ध नहीं हैं, जब आपको मल्टी-क्लाउड पोर्टेबिलिटी की आवश्यकता होती है, या जब बड़े पैमाने पर लागत अनुकूलन परिचालन ओवरहेड को उचित ठहराता है।

# EKS StorageClass for MySQL with gp3 volumes
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: gp3-encrypted
provisioner: ebs.csi.aws.com
parameters:
  type: gp3
  iops: "6000"
  throughput: "250"
  encrypted: "true"
  fsType: ext4
volumeBindingMode: WaitForFirstConsumer
reclaimPolicy: Retain
allowVolumeExpansion: true

Azure: AKS

पर लचीला सर्वर बनाम स्व-प्रबंधित MySQL फ्लेक्सिबल सर्वरके लिए

Azure डेटाबेस स्वचालित फेलओवर, समान-क्षेत्र रीड प्रतिकृतियां और 16 TiB स्टोरेज के साथ ज़ोन-अनावश्यक HA प्रदान करता है। यह कॉन्फ़िगर करने योग्य रखरखाव विंडो, इंस्टेंस को रोकने/शुरू करने की क्षमता (डेवलप/टेस्ट लागत बचत के लिए उपयोगी), और नेटवर्क अलगाव के लिए Azure प्राइवेट लिंक के साथ एकीकरण का समर्थन करता है। बिजनेस क्रिटिकल टियर स्थानीय एसएसडी स्टोरेज के साथ सर्वश्रेष्ठ प्रदर्शन प्रदान करता है।

AKS पर स्व-प्रबंधितMySQL ऑपरेटर या पेरकोना ऑपरेटर के साथ Azure प्रबंधित डिस्क (डेटाबेस वर्कलोड के लिए अनुशंसित प्रीमियम SSD v2) का उपयोग करता है। AKS उपलब्धता क्षेत्र समर्थन और पॉड-स्तरीय VNET एकीकरण के लिए Azure CNI प्रदान करता है।

# AKS StorageClass for MySQL
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: premium-ssd-zrs
provisioner: disk.csi.azure.com
parameters:
  skuName: Premium_ZRS
  cachingMode: None
  DiskIOPSReadWrite: "5000"
  DiskMBpsReadWrite: "200"
volumeBindingMode: WaitForFirstConsumer
reclaimPolicy: Retain
allowVolumeExpansion: true

Google क्लाउड: क्लाउड SQL बनाम GKE

पर स्व-प्रबंधित
MySQLके लिए Google Cloud क्लाउड SQL Google के IAM, VPC और मॉनिटरिंग इकोसिस्टम में एकीकरण के साथ उच्चतम स्तर की प्रबंधित सुविधा प्रदान करता है। एंटरप्राइज प्लस टियर बेहतर रीड परफॉर्मेंस के लिए लगभग शून्य डाउनटाइम रखरखाव और डेटा कैश जोड़ता है।
GKEपर स्व-प्रबंधित स्टोरेज के लिए पर्सिस्टेंट डिस्क SSD या हाइपरडिस्क का उपयोग करता है। GKE ऑटोपायलट नोड प्रबंधन को सरल बनाता है और MySQL ऑपरेटर को न्यूनतम परिचालन ओवरहेड के साथ चला सकता है।
# GKE StorageClass for MySQL apiVersion: storage.k8s.io/v1 kind: StorageClass metadata: name: ssd-regional provisioner: pd.csi.storage.gke.io parameters: type: pd-ssd replication-type: regional-pd volumeBindingMode: WaitForFirstConsumer reclaimPolicy: Retain allowVolumeExpansion: true
बेयर मेटल: k3s + रैंचर + लॉन्गहॉर्न
प्रत्येक कार्यभार सार्वजनिक क्लाउड में नहीं होता है। डेटा संप्रभुता, अनुपालन, लागत अनुकूलन, या विलंबता आवश्यकताओं के लिए, रैंचर प्रबंधन और लॉन्गहॉर्न स्टोरेज के साथ k3s चलाने वाले नंगे धातु Kubernetes क्लस्टर MySQL HA के लिए एक उत्पादन-ग्रेड प्लेटफ़ॉर्म प्रदान करते हैं।
k3s इंस्टालेशन और कॉन्फ़िगरेशन
k3s एक हल्का, प्रमाणित Kubernetes वितरण है जो किनारे और नंगे धातु के लिए आदर्श है। यह सभी नियंत्रण-प्लेन घटकों को एक एकल बाइनरी में बंडल करता है और राज्य भंडारण के लिए SQLite या एम्बेडेड आदि का उपयोग करता है।
# Install k3s server (first control-plane node) curl -sfL https://get.k3s.io | sh -s - server \ --cluster-init \ --tls-san 10.10.0.10 \ --disable traefik \ --disable servicelb \ --write-kubeconfig-mode 644 # Join additional server nodes curl -sfL https://get.k3s.io | K3S_TOKEN=$(cat /var/lib/rancher/k3s/server/node-token) sh -s - server \ --server https://10.10.0.10:6443 \ --tls-san 10.10.0.10 # Join worker nodes curl -sfL https://get.k3s.io | K3S_URL=https://10.10.0.10:6443 \ K3S_TOKEN=$(cat /var/lib/rancher/k3s/server/node-token) sh -s -
MySQLके लिए
लॉन्गहॉर्न स्टोरेज
लॉन्गहॉर्न Kubernetes के लिए बनाया गया एक क्लाउड-नेटिव वितरित ब्लॉक स्टोरेज सिस्टम है। यह सभी नोड्स में डेटा की प्रतिलिपि बनाता है, स्नैपशॉट और बैकअप प्रदान करता है, और Kubernetes CSI ड्राइवर के साथ मूल रूप से एकीकृत होता है। MySQL के लिए, लॉन्गहॉर्न लगातार, प्रतिकृति भंडारण परत प्रदान करता है जिसे क्लाउड प्रदाता अपनी प्रबंधित डिस्क पेशकश के साथ संभालते हैं।
# Install Longhorn helm repo add longhorn https://charts.longhorn.io helm repo update helm install longhorn longhorn/longhorn \ --namespace longhorn-system \ --create-namespace \ --set defaultSettings.defaultReplicaCount=3 \ --set defaultSettings.storageMinimalAvailablePercentage=15 \ --set defaultSettings.guaranteedInstanceManagerCPU=12 # StorageClass for MySQL on Longhorn apiVersion: storage.k8s.io/v1 kind: StorageClass metadata: name: longhorn-mysql provisioner: driver.longhorn.io parameters: numberOfReplicas: "3" staleReplicaTimeout: "2880" dataLocality: best-effort diskSelector: ssd fsType: ext4 reclaimPolicy: Retain volumeBindingMode: Immediate allowVolumeExpansion: true
लोड संतुलन के लिए
MetalLB
नंगे धातु पर, कोई क्लाउड लोड बैलेंसर नहीं है। मेटलएलबी लेयर 2 (एआरपी) या बीजीपी मोड का उपयोग करके लोडबैलेंसर प्रकार की एक्सपीआर1एक्स सेवाओं को बाहरी आईपी पते निर्दिष्ट करके इस अंतर को भरता है।
# MetalLB IP Address Pool and L2 Advertisement apiVersion: metallb.io/v1beta1 kind: IPAddressPool metadata: name: mysql-pool namespace: metallb-system spec: addresses: - 10.10.0.100-10.10.0.110 --- apiVersion: metallb.io/v1beta1 kind: L2Advertisement metadata: name: mysql-l2 namespace: metallb-system spec: ipAddressPools: - mysql-pool
बैकअप और पुनर्प्राप्ति रणनीतियाँ
एक उच्च उपलब्धता क्लस्टर नोड विफलताओं से बचाता है। बैकअप डेटा भ्रष्टाचार, आकस्मिक डिलीट, एप्लिकेशन बग और आपदा पुनर्प्राप्ति परिदृश्यों से बचाता है जहां पूरा क्लस्टर खो जाता है। आपको दोनों की जरूरत है.
mysqldumpके साथ
लॉजिकल बैकअप
mysqldumpSQL-प्रारूप बैकअप तैयार करता है जो पोर्टेबल और मानव-पठनीय हैं। 50 जीबी से कम के डेटाबेस के लिए, यह सबसे सरल विकल्प है। बड़े डेटासेट के लिए, लॉकिंग और निर्यात समय व्यावसायिक घंटों के दौरान उत्पादन के उपयोग के लिए इसे अव्यावहारिक बनाता है।
# Full logical backup with consistent snapshot mysqldump --all-databases \ --single-transaction \ --routines \ --triggers \ --events \ --set-gtid-purged=ON \ --result-file=/backups/full-$(date +%Y%m%d-%H%M%S).sql # Compressed backup piped to S3 mysqldump --all-databases --single-transaction | \ gzip | aws s3 cp - s3://mysql-backups/full-$(date +%Y%m%d).sql.gz
पेरकोना एक्स्ट्राबैकअप
के साथ
भौतिक बैकअप
Percona XtraBackup InnoDB डेटा का हॉट, नॉन-ब्लॉकिंग फिजिकल बैकअप करता है। यह रीडो लॉग को ट्रैक करते समय InnoDB डेटा फ़ाइलों को कॉपी करता है, फिर लगातार बैकअप बनाने के लिए तैयारी चरण के दौरान रीडो लॉग को लागू करता है। यह बड़े डेटासेट के लिए mysqldump से नाटकीय रूप से तेज़ है और वृद्धिशील बैकअप का समर्थन करता है।
# Full physical backup xtrabackup --backup \ --target-dir=/backups/full \ --user=backup_user \ --password=SecureBackupPass \ --parallel=4 \ --compress \ --compress-threads=4 # Incremental backup based on previous full xtrabackup --backup \ --target-dir=/backups/incr-$(date +%H) \ --incremental-basedir=/backups/full \ --user=backup_user \ --password=SecureBackupPass # Prepare (apply redo log) and restore xtrabackup --prepare --target-dir=/backups/full xtrabackup --prepare --target-dir=/backups/full \ --incremental-dir=/backups/incr-01 # Copy back to data directory xtrabackup --copy-back --target-dir=/backups/full --datadir=/var/lib/mysql chown -R mysql:mysql /var/lib/mysql
बाइनरी लॉग (बिनलॉग) पॉइंट-इन-टाइम रिकवरी
बाइनरी लॉग प्रत्येक डेटा-संशोधित लेनदेन को रिकॉर्ड करते हैं। पूर्ण बैकअप के साथ मिलकर, वे पॉइंट-इन-टाइम रिकवरी (PITR) को सक्षम करते हैं - किसी भी विशिष्ट क्षण को पुनर्स्थापित करना, न कि केवल अंतिम बैकअप के समय को।
# Enable binlog retention (my.cnf) [mysqld] log_bin=mysql-bin binlog_expire_logs_seconds=604800 # 7 days binlog_format=ROW gtid_mode=ON enforce_gtid_consistency=ON # Restore from backup then replay binlogs to a specific point mysqlbinlog --start-datetime="2026-04-12 08:00:00" \ --stop-datetime="2026-04-12 09:30:00" \ mysql-bin.000042 mysql-bin.000043 | mysql -u root -p # Or replay to a specific GTID position mysqlbinlog --include-gtids="3c2d4f9e-d17e-ec59-9029-6aafa8accef8:1-5000" \ mysql-bin.000042 | mysql -u root -p
Kubernetes बैकअप क्रोनजॉब
Kubernetes में, बैकअप को एड-हॉक कमांड के बजाय क्रोनजॉब्स के रूप में चलना चाहिए। यह सुनिश्चित करता है कि बैकअप स्वचालित हैं, निगरानी की जाती है, और विफल होने पर सतर्क किया जा सकता है।
apiVersion: batch/v1 kind: CronJob metadata: name: mysql-backup namespace: production spec: schedule: "0 2 * * *" concurrencyPolicy: Forbid successfulJobsHistoryLimit: 7 failedJobsHistoryLimit: 3 jobTemplate: spec: activeDeadlineSeconds: 7200 template: spec: restartPolicy: OnFailure containers: - name: backup image: percona/percona-xtrabackup:8.0.35 command: - /bin/sh - -c - | BACKUP_DIR=/backups/$(date +%Y%m%d-%H%M%S) mkdir -p $BACKUP_DIR xtrabackup --backup \ --host=production-mysql.production.svc \ --user=backup_user \ --password=$BACKUP_PASSWORD \ --target-dir=$BACKUP_DIR \ --parallel=4 \ --compress xtrabackup --prepare --target-dir=$BACKUP_DIR # Upload to S3 aws s3 sync $BACKUP_DIR s3://mysql-backups/$(date +%Y%m%d)/ # Cleanup local rm -rf $BACKUP_DIR env: - name: BACKUP_PASSWORD valueFrom: secretKeyRef: name: mysql-backup-credentials key: password volumeMounts: - name: backup-scratch mountPath: /backups resources: requests: cpu: "1" memory: 2Gi limits: cpu: "2" memory: 4Gi volumes: - name: backup-scratch emptyDir: sizeLimit: 100Gi
पेरकोना मॉनिटरिंग और प्रबंधन (पीएमएम) के साथ
मॉनिटरिंग
पेरकोना मॉनिटरिंग एंड मैनेजमेंट (पीएमएम) एक ओपन-सोर्स मॉनिटरिंग प्लेटफॉर्म है जिसे डेटाबेस अवलोकन के लिए बनाया गया है। जबकि Prometheus और Grafana सामान्य Kubernetes मॉनिटरिंग प्रदान करते हैं, PMM MySQL-विशिष्ट अंतर्दृष्टि जोड़ता है: क्वेरी एनालिटिक्स (QAN) जो धीमी क्वेरी, प्रतिकृति लैग डैशबोर्ड, InnoDB बफर पूल हिट अनुपात, टेबल लॉक विवाद और बहुत कुछ की पहचान करता है।
# Deploy PMM Server on Kubernetes apiVersion: apps/v1 kind: Deployment metadata: name: pmm-server namespace: monitoring spec: replicas: 1 selector: matchLabels: app: pmm-server template: metadata: labels: app: pmm-server spec: containers: - name: pmm-server image: percona/pmm-server:2 ports: - containerPort: 443 env: - name: DISABLE_TELEMETRY value: "1" volumeMounts: - name: pmm-data mountPath: /srv resources: requests: cpu: "1" memory: 4Gi limits: cpu: "2" memory: 8Gi volumes: - name: pmm-data persistentVolumeClaim: claimName: pmm-data-pvc --- apiVersion: v1 kind: Service metadata: name: pmm-server namespace: monitoring spec: type: ClusterIP selector: app: pmm-server ports: - port: 443 targetPort: 443
# Register MySQL instances with PMM Client (run on each MySQL pod or sidecar) pmm-admin config --server-url=https://admin:password@pmm-server.monitoring:443 --server-insecure-tls pmm-admin add mysql \ --username=pmm_monitor \ --password=MonitorPass123 \ --host=127.0.0.1 \ --port=3306 \ --query-source=perfschema \ --service-name=mysql-node-1
PMM का क्वेरी एनालिटिक्स उत्पादन में विशेष रूप से मूल्यवान है। यह सर्वर पर निष्पादित प्रत्येक क्वेरी को कैप्चर करता है (प्रदर्शन स्कीमा या धीमी क्वेरी लॉग के माध्यम से), उन्हें फिंगरप्रिंट द्वारा एकत्रित करता है, और औसत विलंबता, जांच की गई पंक्तियों बनाम भेजी गई पंक्तियों और लॉक समय जैसे मेट्रिक्स दिखाता है। इस प्रकार आप उन प्रश्नों की पहचान करते हैं जो आपके एप्लिकेशन के प्रदर्शन को ख़राब कर रहे हैं।
उत्पादन कॉन्फ़िगरेशन ट्यूनिंग
डिफ़ॉल्ट MySQL कॉन्फ़िगरेशन को छोटे, सामान्य प्रयोजन के कार्यभार के लिए ट्यून किया गया है। समर्पित डेटाबेस सर्वर वाले उत्पादन वातावरण को काफी भिन्न सेटिंग्स की आवश्यकता होती है। यहां महत्वपूर्ण पैरामीटर और उन्हें आकार देने का तरीका बताया गया है।
InnoDB बफ़र पूल
InnoDB बफर पूल वह जगह है जहां MySQL टेबल और इंडेक्स डेटा को मेमोरी में कैश करता है। यह एकल सबसे प्रभावशाली कॉन्फ़िगरेशन पैरामीटर है। एक समर्पित MySQL सर्वर के लिए, इसे उपलब्ध RAM के 70-80% पर सेट करें।
[mysqld] # Memory: 16Gi container limit -> allocate ~12Gi to buffer pool innodb_buffer_pool_size = 12G innodb_buffer_pool_instances = 8 # 1 per GB (up to 64) innodb_buffer_pool_chunk_size = 1536M # pool_size / instances
लॉग कॉन्फ़िगरेशन दोबारा करें
डेटा फ़ाइलों में फ्लश होने से पहले रीडो लॉग लेखन को अवशोषित कर लेता है। बड़े रीडो लॉग चेकपॉइंट फ्लश की आवृत्ति को कम करते हैं और राइट थ्रूपुट में सुधार करते हैं। MySQL 8.0.30+ पुरानेinnodb_log_file_sizeके बजायinnodb_redo_log_capacityका उपयोग करता है।
[mysqld] # MySQL 8.0.30+ innodb_redo_log_capacity = 4G # MySQL 8.0.29 and earlier # innodb_log_file_size = 2G # innodb_log_files_in_group = 2
स्थायित्व बनाम प्रदर्शन ट्रेड-ऑफ
innodb_flush_log_at_trx_commitऔरsync_binlogका संयोजन आपकी स्थायित्व गारंटी निर्धारित करता है।
अधिकतम स्थायित्व(उत्पादन के लिए अनुशंसित):innodb_flush_log_at_trx_commit=1+sync_binlog=1। प्रत्येक लेनदेन को स्वीकार किए जाने से पहले डिस्क पर रीडो लॉग और बाइनरी लॉग में फ्लश किया जाता है। क्रैश होने पर शून्य डेटा हानि.
संतुलित:innodb_flush_log_at_trx_commit=2+sync_binlog=1। Redo लॉग प्रति कमिट OS कैश में लिखा जाता है लेकिन प्रति सेकंड केवल एक बार डिस्क पर फ्लश किया जाता है। OS क्रैश होने पर 1 सेकंड तक का लेन-देन नष्ट हो सकता है (MySQL क्रैश अभी भी सुरक्षित है)।
अधिकतम प्रदर्शन(उत्पादन के लिए अनुशंसित नहीं):innodb_flush_log_at_trx_commit=0+sync_binlog=0। राइट्स को समय-समय पर बैच और फ्लश किया जाता है। किसी भी दुर्घटना पर लेनदेन का 1 सेकंड तक खोने का जोखिम।
[mysqld] # Production durability settings innodb_flush_log_at_trx_commit = 1 sync_binlog = 1 innodb_doublewrite = ON innodb_checksum_algorithm = crc32
I/O कॉन्फ़िगरेशन
[mysqld] # SSD-optimised I/O settings innodb_io_capacity = 4000 innodb_io_capacity_max = 8000 innodb_read_io_threads = 8 innodb_write_io_threads = 8 innodb_flush_method = O_DIRECT innodb_file_per_table = ON innodb_open_files = 10000
कनेक्शन और थ्रेड प्रबंधन
[mysqld] max_connections = 500 max_connect_errors = 1000000 thread_cache_size = 64 table_open_cache = 4096 table_open_cache_instances = 16 back_log = 1500 # Thread pool (MySQL Enterprise or Percona) thread_pool_size = 16 thread_pool_max_threads = 1000
अस्थायी तालिकाएँ और सॉर्ट बफ़र्स
[mysqld] tmp_table_size = 64M max_heap_table_size = 64M sort_buffer_size = 4M join_buffer_size = 4M read_rnd_buffer_size = 2M
पूर्ण उत्पादन कॉन्फ़िगरेशन टेम्पलेट
[mysqld] # Identity server-id = 1 report_host = mysql-node-1 # GTID Replication gtid_mode = ON enforce_gtid_consistency = ON binlog_format = ROW log_bin = mysql-bin binlog_expire_logs_seconds = 604800 log_slave_updates = ON relay_log_recovery = ON # InnoDB Engine innodb_buffer_pool_size = 12G innodb_buffer_pool_instances = 8 innodb_redo_log_capacity = 4G innodb_flush_log_at_trx_commit = 1 sync_binlog = 1 innodb_doublewrite = ON innodb_flush_method = O_DIRECT innodb_io_capacity = 4000 innodb_io_capacity_max = 8000 innodb_read_io_threads = 8 innodb_write_io_threads = 8 innodb_file_per_table = ON innodb_open_files = 10000 innodb_adaptive_hash_index = ON innodb_change_buffering = all # Connections max_connections = 500 max_connect_errors = 1000000 thread_cache_size = 64 table_open_cache = 4096 table_open_cache_instances = 16 back_log = 1500 # Temp / Sort tmp_table_size = 64M max_heap_table_size = 64M sort_buffer_size = 4M join_buffer_size = 4M # Monitoring performance_schema = ON slow_query_log = ON long_query_time = 1 log_queries_not_using_indexes = ON log_throttle_queries_not_using_indexes = 60 # Security local_infile = OFF skip_name_resolve = ON default_authentication_plugin = caching_sha2_password # Group Replication (InnoDB Cluster) plugin_load_add = 'group_replication.so' plugin_load_add = 'mysql_clone.so' loose-group_replication_start_on_boot = OFF loose-group_replication_bootstrap_group = OFF loose-group_replication_recovery_use_ssl = ON loose-group_replication_ssl_mode = REQUIRED
विफलता परीक्षण और कैओस इंजीनियरिंग
एक उच्च उपलब्धता प्रणाली जिसका विफलता की स्थिति में कभी परीक्षण नहीं किया गया है वह वास्तव में उच्च उपलब्धता नहीं है - यह एक परिकल्पना है। फ़ेलओवर परीक्षण आपके नियमित परिचालन ताल का हिस्सा होना चाहिए, न कि ऐसा कुछ जिसे आप वास्तविक घटना के दौरान काम करते हैं (या काम नहीं करते हैं)।
नियंत्रित विफलता परीक्षण
# Test 1: Graceful primary failover (InnoDB Cluster) mysqlsh gradmin@mysql-node-1:3306 var cluster = dba.getCluster() cluster.setPrimaryInstance('gradmin@mysql-node-2:3306') # Verify: cluster.status() should show node-2 as PRIMARY # Test 2: Simulate primary crash # On the primary node: kill -9 $(pidof mysqld) # Monitor: watch the cluster elect a new primary # Verify: applications reconnect via MySQL Router within seconds # Test 3: Network partition simulation # On the primary node, block Group Replication port: iptables -A INPUT -p tcp --dport 33061 -j DROP iptables -A OUTPUT -p tcp --dport 33061 -j DROP # The isolated node should be expelled; cluster continues with remaining members # Cleanup: iptables -D INPUT -p tcp --dport 33061 -j DROP iptables -D OUTPUT -p tcp --dport 33061 -j DROP # Test 4: Kubernetes pod deletion kubectl delete pod mysql-0 -n production --grace-period=0 --force # The StatefulSet controller recreates the pod # The operator rejoins it to the cluster
लिटमस या कैओस मेशके साथ
कैओस इंजीनियरिंग
संरचित अराजकता इंजीनियरिंग उपकरण विफलताओं को व्यवस्थित रूप से इंजेक्ट करते हैं और विस्फोट त्रिज्या को मापते हैं। कैओस मेश, एक सीएनसीएफ परियोजना, मूल रूप से Kubernetes के साथ एकीकृत होती है।
# Chaos Mesh: Kill a MySQL pod randomly apiVersion: chaos-mesh.org/v1alpha1 kind: PodChaos metadata: name: mysql-pod-kill namespace: production spec: action: pod-kill mode: one selector: namespaces: - production labelSelectors: app.kubernetes.io/component: mysqld scheduler: cron: "0 */4 * * *" --- # Chaos Mesh: Network delay between MySQL pods apiVersion: chaos-mesh.org/v1alpha1 kind: NetworkChaos metadata: name: mysql-network-delay namespace: production spec: action: delay mode: one selector: namespaces: - production labelSelectors: app.kubernetes.io/component: mysqld delay: latency: "200ms" jitter: "50ms" duration: "5m" scheduler: cron: "30 */6 * * *" --- # Chaos Mesh: Disk I/O stress apiVersion: chaos-mesh.org/v1alpha1 kind: IOChaos metadata: name: mysql-io-latency namespace: production spec: action: latency mode: one selector: namespaces: - production labelSelectors: app.kubernetes.io/component: mysqld volumePath: /var/lib/mysql path: '*' delay: '100ms' percent: 50 duration: '5m'
फेलओवर टेस्ट के दौरान क्या मापें
पुनर्प्राप्ति समय उद्देश्य (आरटीओ)- विफलता का पता लगाने से सेवा बहाली तक कितना समय? InnoDB क्लस्टर आमतौर पर 5-30 सेकंड प्राप्त करता है। पेरकोना एक्स्ट्राडीबी क्लस्टर तेज़ हो सकता है क्योंकि कोई चुनाव नहीं है (सभी नोड्स लिखने योग्य हैं)।
रिकवरी प्वाइंट ऑब्जेक्टिव (आरपीओ)- फेलओवर के दौरान कितना डेटा नष्ट होता है? समकालिक प्रतिकृति (एकल-प्राथमिक मोड में समूह प्रतिकृति, पीएक्ससी) के साथ, प्रतिबद्ध लेनदेन के लिए आरपीओ शून्य है। अतुल्यकालिक प्रतिकृति (क्लस्टरसेट क्रॉस-क्षेत्र) के साथ, आरपीओ प्रतिकृति अंतराल के बराबर है।
एप्लिकेशन त्रुटि दर- फ़ेलओवर विंडो के दौरान कितने एप्लिकेशन अनुरोध विफल होते हैं? यह न केवल डेटाबेस विफलता का परीक्षण करता है बल्कि आपके एप्लिकेशन के कनेक्शन पुनः प्रयास तर्क और MySQL राउटर की पुनः रूटिंग गति का भी परीक्षण करता है।
कनेक्शन ख़त्म होने का समय— पुराने प्राइमरी से मौजूदा कनेक्शन ख़त्म होने और नए प्राइमरी से दोबारा जुड़ने में कितना समय लगता है?
रनबुक: प्राथमिक नोड विफलता चेकलिस्ट
सत्यापित करें कि क्लस्टर ने एक नया प्राथमिक चुना है:cluster.status()
पुष्टि करें कि MySQL राउटर नए प्राथमिक पर रूट कर रहा है: राउटर लॉग और कनेक्शन गणना की जांच करें
शेष सेकेंडरी पर मॉनिटर प्रतिकृति अंतराल:SELECT * FROM performance_schema.replication_group_member_stats
यदि विफल नोड को पुनर्प्राप्त किया जा सकता है, तो इसे फिर से जोड़ें:cluster.rejoinInstance('gradmin@failed-node:3306')
यदि विफल नोड पुनर्प्राप्त नहीं किया जा सकता है, तो इसे हटा दें और एक नया जोड़ें:cluster.removeInstance('gradmin@failed-node:3306', {force: true})
क्लस्टर स्वास्थ्य सत्यापित करें: सभी सदस्य ऑनलाइन, कोई प्रतिकृति त्रुटियाँ नहीं, बैकअप शेड्यूल बरकरार
अपनी क्षमता योजना को अपडेट करें: 2 नोड्स के साथ चलने का मतलब है कि तीसरे के बहाल होने तक आपके पास शून्य दोष सहनशीलता है
सुरक्षा हार्डनिंग
उत्पादन MySQL परिनियोजन को बुनियादी प्रमाणीकरण से परे कई सुरक्षा चिंताओं का समाधान करना चाहिए।
ट्रांज़िट में और बाकी समय
एन्क्रिप्शन
[mysqld] # TLS for client connections ssl_ca = /etc/mysql/certs/ca.pem ssl_cert = /etc/mysql/certs/server-cert.pem ssl_key = /etc/mysql/certs/server-key.pem require_secure_transport = ON tls_version = TLSv1.3 # Encryption at rest (InnoDB tablespace encryption) early-plugin-load = keyring_file.so keyring_file_data = /var/lib/mysql-keyring/keyring innodb_undo_log_encrypt = ON innodb_redo_log_encrypt = ON default_table_encryption = ON
Kubernetes रहस्य और सीलबंद रहस्य
# Never store database credentials in plain YAML # Use Sealed Secrets or an external secret manager apiVersion: bitnami.com/v1alpha1 kind: SealedSecret metadata: name: mysql-root-credentials namespace: production spec: encryptedData: rootUser: AgBy3i4OJSWK+PiTy... rootPassword: AgCtr7pJ2XQWK+Pi... template: metadata: name: mysql-root-credentials namespace: production type: Opaque
ऑडिट लॉगिंग
[mysqld] # MySQL Enterprise Audit (or Percona Audit Log plugin) plugin-load-add = audit_log.so audit_log_format = JSON audit_log_policy = LOGINS audit_log_rotate_on_size = 100M audit_log_rotations = 10
निर्णय मैट्रिक्स: अपना MySQL HA आर्किटेक्चर चुनना
सही आर्किटेक्चर आपकी विशिष्ट आवश्यकताओं पर निर्भर करता है। यहाँ एक निर्णय रूपरेखा है.
एकल क्लाउड, प्रबंधित प्राथमिकता, MySQL-संगत- ऑरोरा (AWS), फ्लेक्सिबल सर्वर बिजनेस क्रिटिकल (Azure), या क्लाउड SQL एंटरप्राइज प्लस (GCP) का उपयोग करें। ये न्यूनतम परिचालन ओवरहेड प्रदान करते हैं।
एकल क्लाउड, स्व-प्रबंधित, पूर्ण MySQL नियंत्रण की आवश्यकता है- क्लाउड-नेटिव स्टोरेज कक्षाओं के साथ EKS/AKS/GKE पर MySQL ऑपरेटर या पेरकोना ऑपरेटर का उपयोग करें।
मल्टी-क्लाउड या हाइब्रिड क्लाउड- PXC के साथ पेरकोना ऑपरेटर या InnoDB क्लस्टर के साथ MySQL ऑपरेटर का उपयोग करें। Kubernetes एब्स्ट्रैक्शन परत आपके MySQL परिनियोजन को बादलों में पोर्टेबल बनाती है।
नंगे धातु या किनारे- रंचर, लॉन्गहॉर्न स्टोरेज, मेटलएलबी और MySQL ऑपरेटर या पेरकोना ऑपरेटर के साथ k3s का उपयोग करें।
अधिकतम लेखन थ्रूपुट, बहु-प्राथमिक आवश्यक- पेरकोना ऑपरेटर के साथ पेरकोना एक्स्ट्राडीबी क्लस्टर (गैलेरा) का उपयोग करें। सभी नोड समकालिक प्रमाणीकरण के साथ लेखन स्वीकार करते हैं।
आपदा पुनर्प्राप्ति के साथ वैश्विक वितरण- क्षेत्रों के बीच अतुल्यकालिक प्रतिकृति के साथ InnoDB क्लस्टरसेट का उपयोग करें। स्थानीय लेखन के विलंबता लाभों के लिए अतुल्यकालिक प्रतिकृति के आरपीओ ट्रेड-ऑफ़ को स्वीकार करें।
उत्पादन MySQL HAके लिए
परिचालन चेकलिस्ट
अपने MySQL HA परिनियोजन को उत्पादन के लिए तैयार घोषित करने से पहले, इस चेकलिस्ट के प्रत्येक आइटम को सत्यापित करें।
क्लस्टर स्वास्थ्य- सभी सदस्य ऑनलाइन स्थिति की रिपोर्ट करते हैं। समूह प्रतिकृति कोई त्रुटि नहीं दिखाती.
स्वचालित बैकअप- क्रोनजॉब या ऑपरेटर-प्रबंधित बैकअप शेड्यूल पर चल रहे हैं। समय-समय पर पुनर्स्थापना परीक्षणों द्वारा सत्यापित बैकअप।
मॉनिटरिंग- PMM या Prometheus/Grafana MySQL मेट्रिक्स एकत्रित करना। प्रतिकृति अंतराल, कनेक्शन संतृप्ति, 99% से कम बफर पूल हिट अनुपात और डिस्क स्थान के लिए अलर्ट कॉन्फ़िगर किया गया।
फेलओवर का परीक्षण किया गया- पिछले 30 दिनों के भीतर प्राथमिक फेलओवर का परीक्षण किया गया। आरटीओ और आरपीओ मापा गया और एसएलए लक्ष्य के भीतर।
कनेक्शन रूटिंग- MySQL राउटर या ProxySQL स्वास्थ्य-जांच और लोड-संतुलित। एप्लिकेशन कनेक्शन स्ट्रिंग्स राउटर को इंगित करती हैं, व्यक्तिगत MySQL इंस्टेंसेस को नहीं।
सुरक्षा- सभी कनेक्शनों के लिए TLS आवश्यक है। आराम पर एन्क्रिप्शन सक्षम। क्रेडेंशियल एक गुप्त प्रबंधक में संग्रहीत। ऑडिट लॉगिंग सक्रिय. प्रत्येक एप्लिकेशन के लिए कम से कम विशेषाधिकार प्राप्त डेटाबेस उपयोगकर्ता।
संसाधन सीमाएं- Kubernetes संसाधन अनुरोध और सीमाएं उचित रूप से निर्धारित की गई हैं। पॉडडिसरप्शनबजट यथास्थान। पॉड एंटी-एफ़िनिटी MySQL पॉड्स को सभी क्षेत्रों में फैला रहा है।
क्षमता योजना- भंडारण उपयोग की निगरानी 70% और 85% अलर्ट के साथ की जाती है। वॉल्यूम विस्तार का परीक्षण किया गया। ऊर्ध्वाधर और क्षैतिज स्केलिंग प्रक्रियाओं का दस्तावेजीकरण किया गया।
रनबुक- प्राथमिक विफलता, नोड प्रतिस्थापन, बैकअप पुनर्स्थापना, संस्करण अपग्रेड और आपातकालीन रीड-ओनली मोड के लिए प्रलेखित प्रक्रियाएं।
अराजकता परीक्षण- लचीलापन धारणाओं को मान्य करने के लिए नियमित अराजकता प्रयोग निर्धारित हैं।
निष्कर्ष
MySQL उत्पादन में उच्च उपलब्धता एक एकल प्रौद्योगिकी विकल्प नहीं है - यह इंटरलॉकिंग निर्णयों की एक प्रणाली है जो प्रतिकृति परत, ऑर्केस्ट्रेशन प्लेटफ़ॉर्म, स्टोरेज सबसिस्टम, मॉनिटरिंग स्टैक और उनके आसपास की परिचालन प्रक्रियाओं को फैलाती है। समूह प्रतिकृति के साथ InnoDB क्लस्टर मूलभूत HA आदिम प्रदान करता है। Oracle और Percona के Kubernetes ऑपरेटर जीवनचक्र प्रबंधन को स्वचालित करते हैं जो अन्यथा महत्वपूर्ण इंजीनियरिंग समय का उपभोग करेगा। सुविधा के लिए क्लाउड प्रबंधित सेवाएँ व्यापार नियंत्रण। k3s, Rancher, और Longhorn के साथ बेयर मेटल परिनियोजन साबित करते हैं कि आपको उत्पादन-ग्रेड MySQL HA चलाने के लिए क्लाउड प्रदाता की आवश्यकता नहीं है।
सबसे महत्वपूर्ण अंतर्दृष्टि यह है कि उच्च उपलब्धता केवल डेटाबेस की नहीं बल्कि पूरे सिस्टम की एक संपत्ति है। इसमें शामिल है कि आपका एप्लिकेशन कनेक्शन विफलताओं और पुनर्प्रयासों को कैसे संभालता है, आपकी प्रॉक्सी परत कैसे विफल नोड्स का पता लगाती है और उनके चारों ओर रूट करती है, उपयोगकर्ताओं को नोटिस करने से पहले आपकी निगरानी कैसे अलर्ट करती है, आपकी बैकअप रणनीति उन परिदृश्यों से पुनर्प्राप्ति को कैसे सक्षम करती है जिन्हें एचए अकेले संभाल नहीं सकता है, और आपकी टीम फेलओवर प्रक्रियाओं का अभ्यास कैसे करती है ताकि वे एक वास्तविक घटना के तनाव के तहत सफाई से निष्पादित करें।
इसे जानबूझकर बनाएं, नियमित रूप से इसका परीक्षण करें, और अपनी रनबुक को जीवित दस्तावेजों के रूप में मानें जो हर घटना और हर अराजकता प्रयोग के साथ विकसित होते हैं। इस तरह MySQL उत्पादन में एक विश्वसनीय, अत्यधिक उपलब्ध डेटा प्लेटफ़ॉर्म के रूप में अपनी जगह बनाता है।

Loading blog...

Database Kubernetes DevOps Backend

MySQL उत्पादन में उच्च उपलब्धता: InnoDB क्लस्टर, समूह प्रतिकृति, और Kubernetes ऑपरेटर

Balinder Walia12 अप्रैल 202629 min read

MySQL InnoDB क्लस्टर आर्किटेक्चर

समूह प्रतिकृति मूल बातें

समूह प्रतिकृति दो मोड में संचालित होती है:

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

MySQL शेल

के साथ InnoDB क्लस्टर की स्थापना
MySQL शेल, AdminAPI प्रदान करता है, जो फ़ंक्शंस का एक सेट है जो संपूर्ण क्लस्टर जीवनचक्र को स्वचालित करता है। यहां 3-नोड क्लस्टर के लिए संपूर्ण सेटअप अनुक्रम है।
# Step 1: Prepare each MySQL instance (run on all 3 nodes) # Ensure my.cnf has required settings [mysqld] server-id=1 # unique per node: 1, 2, 3 gtid_mode=ON enforce_gtid_consistency=ON binlog_checksum=NONE binlog_transaction_dependency_tracking=WRITESET transaction_write_set_extraction=XXHASH64 loose-group_replication_start_on_boot=OFF plugin_load_add='group_replication.so' plugin_load_add='mysql_clone.so' report_host='mysql-node-1' # unique per node # Step 2: Use MySQL Shell to configure and create the cluster mysqlsh -- dba configure-instance root@mysql-node-1:3306 --clusterAdmin=gradmin --clusterAdminPassword='SecurePass123!' mysqlsh -- dba configure-instance root@mysql-node-2:3306 --clusterAdmin=gradmin --clusterAdminPassword='SecurePass123!' mysqlsh -- dba configure-instance root@mysql-node-3:3306 --clusterAdmin=gradmin --clusterAdminPassword='SecurePass123!' # Step 3: Connect to the first node and create the cluster mysqlsh gradmin@mysql-node-1:3306 # Inside MySQL Shell: var cluster = dba.createCluster('productionCluster', { memberWeight: 90, exitStateAction: 'ABORT_SERVER', consistency: 'BEFORE_ON_PRIMARY_FAILOVER', expelTimeout: 10 }) # Step 4: Add remaining nodes cluster.addInstance('gradmin@mysql-node-2:3306', {recoveryMethod: 'clone'}) cluster.addInstance('gradmin@mysql-node-3:3306', {recoveryMethod: 'clone'}) # Step 5: Verify cluster status cluster.status()
recoveryMethod: 'clone'विकल्प प्राथमिक से जुड़ने वाले सदस्य तक पूर्ण डेटा कॉपी करने के लिए MySQL क्लोन प्लगइन का उपयोग करता है, जो बड़े डेटासेट के लिए बाइनरी लॉग से वृद्धिशील पुनर्प्राप्ति से कहीं अधिक तेज़ है।
MySQL राउटर कॉन्फ़िगरेशन
MySQL राउटर क्लस्टर के विरुद्ध बूटस्ट्रैप किया गया है और स्वचालित रूप से इसकी कॉन्फ़िगरेशन फ़ाइल उत्पन्न करता है।
# Bootstrap MySQL Router against the cluster mysqlrouter --bootstrap gradmin@mysql-node-1:3306 \ --directory /opt/mysqlrouter \ --conf-use-sockets \ --user=mysqlrouter \ --name='production-router' # Start MySQL Router /opt/mysqlrouter/start.sh # Default ports after bootstrap: # 6446 — R/W (routes to primary) # 6447 — R/O (round-robin across secondaries) # 6448 — R/W (X Protocol) # 6449 — R/O (X Protocol)
एप्लिकेशन लिखने के लिए राउटर के R/W पोर्ट और रीड प्रतिकृतियों के लिए R/O पोर्ट से कनेक्ट होते हैं। जब प्राथमिक विफल हो जाता है, तो राउटर टोपोलॉजी परिवर्तन का पता लगाता है और सेकंड के भीतर पुन: रूट करता है।
बहु-क्षेत्र MySQL परिनियोजन
विभिन्न भौगोलिक क्षेत्रों में आपदा पुनर्प्राप्ति और कम-विलंबता रीडिंग के लिए, MySQL को कई क्षेत्रों में तैनात किया जा सकता है। InnoDB क्लस्टरसेट प्राथमिक क्लस्टर और विभिन्न क्षेत्रों में एक या अधिक प्रतिकृति क्लस्टर के बीच अतुल्यकालिक प्रतिकृति का समर्थन करने के लिए InnoDB क्लस्टर का विस्तार करता है।
InnoDB क्लस्टरसेट एक प्राथमिक क्लस्टर के साथ संचालित होता है जो सभी लेखन को संभालता है, और एक या अधिक प्रतिकृति क्लस्टर जो अतुल्यकालिक रूप से परिवर्तन प्राप्त करते हैं। आपदा परिदृश्य में, एक प्रतिकृति क्लस्टर को MySQL शेल के माध्यम से प्राथमिक में पदोन्नत किया जा सकता है।
# Create a ClusterSet from an existing InnoDB Cluster mysqlsh gradmin@mysql-node-1:3306 var cluster = dba.getCluster() var cs = cluster.createClusterSet('globalSet') # Create a replica cluster in eu-west region cs.createReplicaCluster('gradmin@mysql-eu-node-1:3306', 'euWestCluster', { recoveryMethod: 'clone' }) var euCluster = cs.getCluster('euWestCluster') euCluster.addInstance('gradmin@mysql-eu-node-2:3306', {recoveryMethod: 'clone'}) euCluster.addInstance('gradmin@mysql-eu-node-3:3306', {recoveryMethod: 'clone'}) # Emergency failover (when primary cluster is unreachable) cs.forcePrimaryCluster('euWestCluster')
Kubernetes पर
MySQL — ऑपरेटर पैटर्न
Kubernetes ऑपरेटर इस डोमेन-विशिष्ट परिचालन ज्ञान को एक नियंत्रक में एन्कोड करते हैं जो कस्टम संसाधनों पर नज़र रखता है और MySQL की वास्तविक स्थिति को YAML में घोषित वांछित स्थिति में समेटता है।
Kubernetes (Oracle)के लिए
MySQL ऑपरेटर Kubernetes के लिए
Oracle का MySQL ऑपरेटर मूल रूप से Kubernetes पर InnoDB क्लस्टर इंस्टेंस को तैनात और प्रबंधित करता है। यह MySQL सर्वर पॉड के लिए स्टेटफुलसेट, MySQL राउटर के लिए परिनियोजन बनाता है, और स्वचालित विफलता, स्केलिंग, बैकअप और कॉन्फ़िगरेशन परिवर्तनों को संभालता है।
# Install the MySQL Operator via Helm helm repo add mysql-operator https://mysql.github.io/mysql-operator/ helm repo update helm install mysql-operator mysql-operator/mysql-operator \ --namespace mysql-operator \ --create-namespace \ --set image.pullPolicy=IfNotPresent
एक बार जब ऑपरेटर चल रहा हो, तो एक कस्टम संसाधन बनाकर एक InnoDB क्लस्टर तैनात करें।
apiVersion: v1 kind: Secret metadata: name: mysql-root-credentials namespace: production stringData: rootUser: root rootHost: '%' rootPassword: 'ProductionSecurePass123!' --- apiVersion: mysql.oracle.com/v2 kind: InnoDBCluster metadata: name: production-mysql namespace: production spec: secretName: mysql-root-credentials instances: 3 tlsUseSelfSigned: true router: instances: 2 datadirVolumeClaimTemplate: accessModes: - ReadWriteOnce resources: requests: storage: 100Gi storageClassName: gp3-encrypted mycnf: | [mysqld] innodb_buffer_pool_size=4G innodb_log_file_size=1G innodb_flush_log_at_trx_commit=1 sync_binlog=1 max_connections=500 innodb_io_capacity=2000 innodb_io_capacity_max=4000 innodb_read_io_threads=8 innodb_write_io_threads=8 performance_schema=ON slow_query_log=ON long_query_time=1 podSpec: containers: - name: mysql resources: requests: cpu: "2" memory: 8Gi limits: cpu: "4" memory: 16Gi affinity: podAntiAffinity: requiredDuringSchedulingIgnoredDuringExecution: - labelSelector: matchExpressions: - key: component operator: In values: [mysqld] topologyKey: topology.kubernetes.io/zone
पॉड एंटी-एफ़िनिटी नियम यह सुनिश्चित करता है कि MySQL पॉड उपलब्धता क्षेत्रों में फैले हुए हैं, जो ज़ोन-स्तरीय दोष सहनशीलता प्रदान करते हैं।mycnfब्लॉक आपको सीधे सीआर के माध्यम से उत्पादन-ट्यून किए गए MySQL कॉन्फ़िगरेशन को इंजेक्ट करने की अनुमति देता है।
MySQL (PXC)
के लिए
पेरकोना ऑपरेटर MySQL के लिए
पेरकोना ऑपरेटर गैलेरा पर आधारित एक बहु-प्राथमिक सिंक्रोनस प्रतिकृति समाधान, पेरकोना एक्स्ट्राडीबी क्लस्टर (पीएक्ससी) को तैनात करता है। PXC InnoDB क्लस्टर से इस मायने में भिन्न है कि प्रत्येक नोड राइट्स (वास्तविक बहु-प्राथमिक) स्वीकार कर सकता है, और प्रतिकृति wsrep API का उपयोग करके प्रमाणन स्तर पर समकालिक है।
# Install Percona Operator helm repo add percona https://percona.github.io/percona-helm-charts/ helm repo update helm install pxc-operator percona/pxc-operator \ --namespace pxc \ --create-namespace
# Percona XtraDB Cluster Custom Resource apiVersion: pxc.percona.com/v1 kind: PerconaXtraDBCluster metadata: name: production-pxc namespace: pxc spec: crVersion: '1.14.0' secretsName: pxc-secrets pxc: size: 3 image: percona/percona-xtradb-cluster:8.0.35 resources: requests: memory: 8Gi cpu: "2" limits: memory: 16Gi cpu: "4" volumeSpec: persistentVolumeClaim: storageClassName: gp3-encrypted accessModes: [ReadWriteOnce] resources: requests: storage: 200Gi affinity: antiAffinityTopologyKey: topology.kubernetes.io/zone configuration: | [mysqld] innodb_buffer_pool_size=4G innodb_flush_log_at_trx_commit=1 wsrep_provider_options="gcache.size=2G; gcs.fc_limit=256" wsrep_slave_threads=8 wsrep_certify_nonPK=1 wsrep_trx_fragment_size=10M max_connections=500 haproxy: enabled: true size: 3 image: percona/haproxy:2.8.5 resources: requests: memory: 1Gi cpu: 500m proxysql: enabled: false backup: image: percona/percona-xtradb-cluster-operator:1.14.0-pxc8.0-backup-pxb8.0.35 storages: s3-backup: type: s3 verifyTLS: true s3: bucket: production-mysql-backups region: us-east-1 credentialsSecret: aws-s3-credentials schedule: - name: daily-full schedule: "0 3 * * *" keep: 7 storageName: s3-backup - name: hourly-incremental schedule: "0 * * * *" keep: 24 storageName: s3-backup
पेरकोना ऑपरेटर S3 के लिए स्वचालित बैकअप, पॉइंट-इन-टाइम रिकवरी, रोलिंग अपग्रेड और कनेक्शन रूटिंग के लिए ProxySQL या HAProxy को संभालता है। पीएक्ससी में गैलेरा-आधारित प्रतिकृति सही सिंक्रोनस मल्टी-प्राइमरी राइट्स प्रदान करती है - प्रत्येक प्रतिबद्ध लेनदेन को सभी नोड्स पर मौजूद होने की गारंटी है।
कनेक्शन रूटिंग: MySQL राउटर बनाम ProxySQL
MySQL राउटर और ProxySQL दोनों डेटाबेस प्रॉक्सी के रूप में काम करते हैं, लेकिन उनकी ताकत अलग-अलग होती है।
MySQL राउटरInnoDB क्लस्टर के लिए उद्देश्य से बनाया गया है। यह क्लस्टर मेटाडेटा को पढ़ता है, टोपोलॉजी परिवर्तनों को ट्रैक करता है, और कनेक्शन को सही प्राथमिक या द्वितीयक तक रूट करता है। इसका कॉन्फ़िगरेशन न्यूनतम है और यह MySQL पारिस्थितिकी तंत्र के साथ सहजता से एकीकृत होता है। नकारात्मक पक्ष सीमित क्वेरी-स्तरीय रूटिंग है - यह कनेक्शन स्तर पर संचालित होता है, क्वेरी स्तर पर नहीं।
ProxySQLउन्नत सुविधाओं के साथ एक सामान्य प्रयोजन MySQL प्रॉक्सी है: क्वेरी-स्तरीय रीड/राइट स्प्लिटिंग, क्वेरी कैशिंग, कनेक्शन मल्टीप्लेक्सिंग, क्वेरी रीराइटिंग और परिष्कृत रूटिंग नियम। यह उन वातावरणों में उत्कृष्टता प्राप्त करता है जहां आपको प्रश्नों को वितरित करने के तरीके पर सूक्ष्म नियंत्रण की आवश्यकता होती है।
# ProxySQL configuration for read/write splitting # proxysql.cnf mysql_servers: ( { hostgroup_id=10, hostname="mysql-primary", port=3306, max_connections=200, weight=1000 }, { hostgroup_id=20, hostname="mysql-secondary-1", port=3306, max_connections=200, weight=500 }, { hostgroup_id=20, hostname="mysql-secondary-2", port=3306, max_connections=200, weight=500 } ) mysql_query_rules: ( { rule_id=1, active=1, match_digest="^SELECT .* FOR UPDATE$", destination_hostgroup=10, apply=1 }, { rule_id=2, active=1, match_digest="^SELECT", destination_hostgroup=20, apply=1 }, { rule_id=3, active=1, match_digest=".*", destination_hostgroup=10, apply=1 } ) mysql_replication_hostgroups: ( { writer_hostgroup=10, reader_hostgroup=20, comment="InnoDB Cluster" } )
Kubernetes वातावरण में, ProxySQL आपके एप्लिकेशन पॉड्स में एक साइडकार कंटेनर के रूप में या एक समर्पित परिनियोजन के रूप में चल सकता है। इसे साइडकार के रूप में चलाने से नेटवर्क हॉप समाप्त हो जाता है लेकिन पॉड संसाधन उपयोग बढ़ जाता है; एक समर्पित तैनाती को बड़े पैमाने पर प्रबंधित करना आसान है।
क्लाउड प्रदाता तुलना: प्रबंधित बनाम स्व-प्रबंधित
AWS: RDS मल्टी-AZ बनाम ऑरोरा बनाम EKS
पर स्व-प्रबंधित
Amazon RDS मल्टी-AZविभिन्न उपलब्धता क्षेत्रों में प्राथमिक और स्टैंडबाय इंस्टेंस के बीच स्वचालित विफलता प्रदान करता है। फ़ेलओवर में आमतौर पर 60-120 सेकंड लगते हैं। यह स्टैंडबाय में समकालिक भौतिक प्रतिकृति का उपयोग करता है। रीड स्केलिंग के लिए रीड प्रतिकृतियां जोड़ी जा सकती हैं लेकिन वे अतुल्यकालिक प्रतिकृति का उपयोग करते हैं। आरडीएस बैकअप, पैचिंग और मॉनिटरिंग को संभालता है लेकिन MySQL कॉन्फ़िगरेशन और संस्करण चयन पर आपके नियंत्रण को सीमित करता है।
अमेज़न ऑरोरा MySQLMySQL स्टोरेज इंजन का क्लाउड-नेटिव रीराइट है। यह गणना को भंडारण से अलग करता है - भंडारण परत एक वितरित, दोष-सहिष्णु प्रणाली है जो तीन एज़ेड में छह तरीकों से डेटा की नकल करती है। ऑरोरा 10-सेकंड से कम का फेलओवर, न्यूनतम प्रतिकृति अंतराल के साथ 15 पढ़ी गई प्रतिकृतियां और 128 टीआईबी तक स्वचालित भंडारण स्केलिंग प्रदान करता है। ऑरोरा सर्वरलेस v2 अप्रत्याशित कार्यभार के लिए स्वचालित गणना स्केलिंग जोड़ता है। ट्रेड-ऑफ लागत है (ऑरोरा आरडीएस की तुलना में 20-40% अधिक महंगा है) और कुछ MySQL सुविधाओं के साथ संगतता कम हो गई है।
EKSपर स्व-प्रबंधित आपको MySQL संस्करण, कॉन्फ़िगरेशन और प्रतिकृति टोपोलॉजी पर पूर्ण नियंत्रण देता है। इसका उपयोग तब करें जब आपको विशिष्ट MySQL सुविधाओं की आवश्यकता हो जो प्रबंधित सेवाओं में उपलब्ध नहीं हैं, जब आपको मल्टी-क्लाउड पोर्टेबिलिटी की आवश्यकता होती है, या जब बड़े पैमाने पर लागत अनुकूलन परिचालन ओवरहेड को उचित ठहराता है।
# EKS StorageClass for MySQL with gp3 volumes apiVersion: storage.k8s.io/v1 kind: StorageClass metadata: name: gp3-encrypted provisioner: ebs.csi.aws.com parameters: type: gp3 iops: "6000" throughput: "250" encrypted: "true" fsType: ext4 volumeBindingMode: WaitForFirstConsumer reclaimPolicy: Retain allowVolumeExpansion: true
Azure: AKS
पर लचीला सर्वर बनाम स्व-प्रबंधित MySQL फ्लेक्सिबल सर्वरके लिए

# AKS StorageClass for MySQL
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: premium-ssd-zrs
provisioner: disk.csi.azure.com
parameters:
  skuName: Premium_ZRS
  cachingMode: None
  DiskIOPSReadWrite: "5000"
  DiskMBpsReadWrite: "200"
volumeBindingMode: WaitForFirstConsumer
reclaimPolicy: Retain
allowVolumeExpansion: true