پیداوار میں MySQL اعلی دستیابی: InnoDB کلسٹر، گروپ ریپلیکیشن، اور Kubernetes آپریٹرز

Azure ڈیٹا بیس MySQL لچکدار سرور کے لیےخودکار فیل اوور، ایک ہی ریجن ریڈ ریپلیکس، اور 16 TiB اسٹوریج کے ساتھ زون فالتو HA پیش کرتا ہے۔ یہ کنفیگر ایبل مینٹیننس ونڈوز، مثالوں کو روکنے/شروع کرنے کی صلاحیت (ڈیو/ٹیسٹ لاگت کی بچت کے لیے مفید)، اور نیٹ ورک آئسولیشن کے لیے Azure پرائیویٹ لنک کے ساتھ انضمام کی حمایت کرتا ہے۔ بزنس کریٹیکل ٹائر مقامی SSD اسٹوریج کے ساتھ بہترین کارکردگی فراہم کرتا ہے۔

Google Cloud SQL MySQLکے لیے تمام زونز میں خودکار فیل اوور کے ساتھ علاقائی مثالیں پیش کرتا ہے، ریپلیکاز (بشمول کراس ریجن)، اور پوائنٹ ان ٹائم ریکوری کے ساتھ خودکار بیک اپ پیش کرتا ہے۔ Cloud SQL Google کے IAM، VPC، اور نگرانی کے ماحولیاتی نظام میں انضمام کے ساتھ منظم سہولت کی اعلیٰ ترین سطح فراہم کرتا ہے۔ انٹرپرائز پلس درجے میں پڑھنے کی بہتر کارکردگی کے لیے تقریباً صفر ڈاؤن ٹائم مینٹیننس اور ڈیٹا کیش کا اضافہ ہوتا ہے۔

k3s انسٹالیشن اور کنفیگریشن

k3s ایک ہلکا پھلکا، تصدیق شدہ Kubernetes ڈسٹری بیوشن ہے جو کنارے اور ننگی دھات کے لیے مثالی ہے۔ یہ تمام کنٹرول پلین اجزاء کو ایک ہی بائنری میں بنڈل کرتا ہے اور اسٹیٹ اسٹوریج کے لیے SQLite یا ایمبیڈڈ etcd استعمال کرتا ہے۔

# 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 -

Longhorn Storage برائے MySQL

Longhorn ایک کلاؤڈ مقامی تقسیم شدہ بلاک اسٹوریج سسٹم ہے جو Kubernetes کے لیے بنایا گیا ہے۔ یہ تمام نوڈس میں ڈیٹا کی نقل تیار کرتا ہے، سنیپ شاٹس اور بیک اپ فراہم کرتا ہے، اور Kubernetes CSI ڈرائیور کے ساتھ مقامی طور پر مربوط ہوتا ہے۔ MySQL کے لیے، Longhorn مستقل، نقل شدہ اسٹوریج پرت فراہم کرتا ہے جسے کلاؤڈ فراہم کرنے والے اپنی منظم ڈسک پیشکشوں کے ساتھ ہینڈل کرتے ہیں۔

# 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

ننگی دھات پر، کوئی کلاؤڈ لوڈ بیلنسر نہیں ہے۔ MetalLB اس خلا کو پرت 2 (ARP) یا BGP موڈ کا استعمال کرتے ہوئے Kubernetes قسم کی لوڈ بیلنس سروسز کو بیرونی IP ایڈریس تفویض کر کے پر کرتا ہے۔

# 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

بیک اپ اور ریکوری کی حکمت عملی

ایک اعلی دستیابی کلسٹر نوڈ کی ناکامیوں سے بچاتا ہے۔ بیک اپ ڈیٹا کی بدعنوانی، حادثاتی طور پر حذف ہونے، ایپلیکیشن کیڑے، اور تباہی کی بحالی کے منظرناموں سے حفاظت کرتے ہیں جہاں پورا کلسٹر ضائع ہو جاتا ہے۔ آپ کو دونوں کی ضرورت ہے۔

منطقی بیک اپ

mysqldumpSQL فارمیٹ کے بیک اپ تیار کرتا ہے جو پورٹیبل اور انسانی پڑھنے کے قابل ہیں۔ 50 GB سے کم ڈیٹا بیس کے لیے، یہ سب سے آسان آپشن ہے۔ بڑے ڈیٹا سیٹس کے لیے، لاکنگ اور ایکسپورٹ ٹائم اسے کاروباری اوقات کے دوران پیداواری استعمال کے لیے ناقابل عمل بنا دیتا ہے۔

# 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

فزیکل بیک اپ

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

مانیٹرنگ

پرکونا مانیٹرنگ اینڈ مینجمنٹ (PMM) ایک اوپن سورس مانیٹرنگ پلیٹ فارم ہے جو ڈیٹا بیس کے مشاہدے کے لیے بنایا گیا ہے۔ جبکہ 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 log 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

Chaos انجینئرنگ Litmus یا Chaos Mesh

ساختی افراتفری انجینئرنگ ٹولز ناکامیوں کو منظم طریقے سے انجیکشن دیتے ہیں اور دھماکے کے رداس کی پیمائش کرتے ہیں۔ Chaos Mesh، ایک CNCF پروجیکٹ، 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'

فیل اوور ٹیسٹ کے دوران کیا پیمائش کرنا ہے

• ریکوری ٹائم مقصد (RTO)— ناکامی کا پتہ لگانے سے لے کر سروس کی بحالی تک کب تک؟ InnoDB کلسٹر عام طور پر 5-30 سیکنڈ تک حاصل کرتا ہے۔ Percona XtraDB کلسٹر تیز تر ہو سکتا ہے کیونکہ کوئی الیکشن نہیں ہے (تمام نوڈس قابل تحریر ہیں)۔
• Recovery Point Objective (RPO)— فیل اوور کے دوران کتنا ڈیٹا ضائع ہوتا ہے؟ ہم وقت ساز نقل کے ساتھ (گروپ ریپلیکیشن سنگل پرائمری موڈ میں، PXC)، آر پی او پرعزم ٹرانزیکشنز کے لیے صفر ہے۔ غیر مطابقت پذیر نقل (ClusterSet کراس ریجن) کے ساتھ، RPO نقل کے وقفے کے برابر ہے۔
• درخواست کی خرابی کی شرح— فیل اوور ونڈو کے دوران کتنی درخواستیں ناکام ہو جاتی ہیں؟ یہ نہ صرف ڈیٹا بیس فیل اوور کی جانچ کرتا ہے بلکہ آپ کی ایپلیکیشن کے کنکشن کی دوبارہ کوشش کی منطق اور MySQL راؤٹر کی ری روٹنگ کی رفتار کو بھی جانچتا ہے۔
• کنکشن ڈرین ٹائم— پرانے پرائمری سے موجودہ کنکشن کو ڈرین ہونے اور نئے پرائمری سے دوبارہ منسلک ہونے میں کتنا وقت لگتا ہے؟

رن بک: پرائمری نوڈ فیلور چیک لسٹ

1. تصدیق کریں کہ کلسٹر نے ایک نیا پرائمری منتخب کیا ہے:cluster.status()
2. تصدیق کریں کہ MySQL راؤٹر نئے پرائمری کی طرف جا رہا ہے: روٹر لاگز اور کنکشن کی گنتی چیک کریں
3. مانیٹر ریپلیکیشن لیگ بقیہ سیکنڈریز پر:SELECT * FROM performance_schema.replication_group_member_stats
4. اگر ناکام نوڈ کو بازیافت کیا جا سکتا ہے، تو اس میں دوبارہ شامل ہوں:cluster.rejoinInstance('gradmin@failed-node:3306')
5. اگر ناکام نوڈ کو بازیافت نہیں کیا جا سکتا ہے، تو اسے ہٹا دیں اور ایک نیا شامل کریں:cluster.removeInstance('gradmin@failed-node:3306', {force: true})
6. کلسٹر ہیلتھ کی تصدیق کریں: تمام ممبران آن لائن، نقل کی کوئی خرابی نہیں، بیک اپ شیڈول برقرار
7. اپنے کیپسٹی پلان کو اپ ڈیٹ کریں: 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 سے مطابقت رکھنے والا— Aurora (AWS)، لچکدار سرور بزنس کریٹیکل (Azure)، یا کلاؤڈ SQL Enterprise Plus (GCP) کا استعمال کریں۔ یہ سب سے کم آپریشنل اوور ہیڈ فراہم کرتے ہیں۔
• سنگل کلاؤڈ، خود نظم، مکمل MySQL کنٹرول کی ضرورت ہے— کلاؤڈ مقامی اسٹوریج کلاسز کے ساتھ EKS/AKS/GKE پر MySQL آپریٹر یا پرکونا آپریٹر استعمال کریں۔
• ملٹی کلاؤڈ یا ہائبرڈ کلاؤڈ— PXC کے ساتھ Percona آپریٹر یا InnoDB کلسٹر کے ساتھ MySQL آپریٹر استعمال کریں۔ Kubernetes تجریدی تہہ آپ کی MySQL تعیناتی کو بادلوں میں پورٹیبل بناتی ہے۔
• ننگی دھات یا کنارے— رینچر، لانگ ہارن اسٹوریج، میٹل ایل بی، اور یا تو MySQL آپریٹر یا پرکونا آپریٹر کے ساتھ k3s استعمال کریں۔
• زیادہ سے زیادہ تحریری تھرو پٹ، ملٹی پرائمری درکار— Percona آپریٹر کے ساتھ Percona XtraDB کلسٹر (Galera) کا استعمال کریں۔ تمام نوڈس مطابقت پذیر سرٹیفیکیشن کے ساتھ تحریروں کو قبول کرتے ہیں۔
• ڈیزاسٹر ریکوری کے ساتھ عالمی تقسیم— خطوں کے درمیان غیر مطابقت پذیر نقل کے ساتھ InnoDB کلسٹر سیٹ کا استعمال کریں۔ مقامی تحریروں کے لیٹنسی فوائد کے لیے غیر مطابقت پذیر نقل کے آر پی او ٹریڈ آف کو قبول کریں۔

آپریشنل چیک لسٹ MySQL HA

اپنی MySQL HA تعیناتی پروڈکشن کے لیے تیار ہونے کا اعلان کرنے سے پہلے، اس چیک لسٹ میں موجود ہر آئٹم کی توثیق کریں۔

1. کلسٹر ہیلتھ— تمام ممبران آن لائن اسٹیٹس کی اطلاع دیتے ہیں۔ گروپ کی نقل میں کوئی غلطی نہیں دکھائی دیتی ہے۔
2. خودکار بیک اپس— کرون جاب یا آپریٹر کے زیر انتظام بیک اپ شیڈول پر چل رہے ہیں۔ بیک اپ کی تصدیق متواتر بحالی ٹیسٹوں سے ہوتی ہے۔
3. مانیٹرنگ— PMM یا Prometheus/Grafana MySQL میٹرکس جمع کرنا۔ ریپلیکشن وقفہ، کنکشن سنترپتی، بفر پول ہٹ ریشو 99% سے نیچے، اور ڈسک کی جگہ کے لیے ترتیب کردہ الرٹس۔
4. فیل اوور کا تجربہ کیا گیا— پرائمری فیل اوور کا آخری 30 دنوں میں تجربہ کیا گیا۔ RTO اور RPO کی پیمائش اور SLA اہداف کے اندر۔
5. کنکشن روٹنگ— MySQL راؤٹر یا ProxySQL ہیلتھ چیک شدہ اور لوڈ متوازن۔ ایپلیکیشن کنکشن کے تار راؤٹر کی طرف اشارہ کرتے ہیں، انفرادی MySQL مثالوں کی نہیں۔
6. سیکیورٹی— TLS تمام کنکشنز کے لیے درکار ہے۔ باقی میں خفیہ کاری فعال ہے۔ ایک خفیہ مینیجر میں محفوظ کردہ اسناد۔ آڈٹ لاگنگ فعال ہے۔ ہر درخواست کے لیے کم سے کم استحقاق والے ڈیٹا بیس کے صارفین۔
7. وسائل کی حدیں— Kubernetes وسائل کی درخواستیں اور حدیں مناسب طریقے سے سیٹ کی گئی ہیں۔ PodDisruptionBudges جگہ پر ہیں۔ Pod anti-affinity MySQL pods کو پورے زون میں پھیلاتا ہے۔
8. صلاحیت کا منصوبہ— 70% اور 85% پر الرٹس کے ساتھ اسٹوریج کے استعمال کی نگرانی کی گئی۔ حجم کی توسیع کا تجربہ کیا گیا۔ عمودی اور افقی پیمانے کے طریقہ کار کو دستاویز کیا گیا ہے۔
9. Runbooks— پرائمری فیل اوور، نوڈ ریپلیسمنٹ، بیک اپ ریسٹور، ورژن اپ گریڈ، اور ایمرجنسی ریڈ اونلی موڈ کے لیے دستاویزی طریقہ کار۔
10. Chaos ٹیسٹنگ— لچک کے مفروضوں کی توثیق کے لیے باقاعدہ افراتفری کے تجربات طے کیے گئے ہیں۔

نتیجہ

MySQL پیداوار میں اعلیٰ دستیابی کسی ایک ٹیکنالوجی کا انتخاب نہیں ہے — یہ آپس میں جڑے فیصلوں کا ایک ایسا نظام ہے جو نقل کی تہہ، آرکیسٹریشن پلیٹ فارم، اسٹوریج سب سسٹم، مانیٹرنگ اسٹیک، اور ان کے ارد گرد آپریشنل عمل کو پھیلاتا ہے۔ گروپ ریپلیکیشن کے ساتھ InnoDB کلسٹر بنیادی HA پرائمیٹو فراہم کرتا ہے۔ Oracle اور Percona کے Kubernetes آپریٹرز لائف سائیکل مینجمنٹ کو خودکار بناتے ہیں جو بصورت دیگر انجینئرنگ کا اہم وقت خرچ کرے گا۔ سہولت کے لیے کلاؤڈ کے زیر انتظام خدمات کا تجارتی کنٹرول۔ k3s، Rancher، اور Longhorn کے ساتھ ننگی دھات کی تعیناتیاں یہ ثابت کرتی ہیں کہ آپ کو پروڈکشن گریڈ MySQL HA چلانے کے لیے کلاؤڈ فراہم کنندہ کی ضرورت نہیں ہے۔

سب سے اہم بصیرت یہ ہے کہ اعلی دستیابی پورے نظام کی خاصیت ہے، نہ کہ صرف ڈیٹا بیس کی۔ اس میں یہ شامل ہے کہ آپ کی ایپلی کیشن کنکشن کی ناکامیوں اور دوبارہ کوششوں کو کیسے ہینڈل کرتی ہے، آپ کی پراکسی لیئر ناکام نوڈس کے ارد گرد کیسے پتہ لگاتی ہے، کس طرح آپ کی نگرانی کے انتباہات صارفین کے نوٹس لینے سے پہلے، کس طرح آپ کی بیک اپ حکمت عملی ان منظرناموں سے بازیابی کو قابل بناتی ہے جنہیں HA اکیلے ہینڈل نہیں کر سکتا، اور کس طرح آپ کی ٹیم ناکامی کے طریقہ کار پر عمل کرتی ہے تاکہ وہ ایک حقیقی واقعے کے دباؤ میں صاف طور پر عمل کریں۔

اسے جان بوجھ کر بنائیں، اسے باقاعدگی سے آزمائیں، اور اپنی رن بکس کو زندہ دستاویزات کے طور پر دیکھیں جو ہر واقعے اور ہر افراتفری کے تجربے کے ساتھ تیار ہوتی ہیں۔ اس طرح MySQL پیداوار میں ایک قابل اعتماد، انتہائی دستیاب ڈیٹا پلیٹ فارم کے طور پر اپنا مقام حاصل کرتا ہے۔