MySQL ਉਤਪਾਦਨ ਵਿੱਚ ਉੱਚ ਉਪਲਬਧਤਾ: InnoDB ਕਲੱਸਟਰ, ਸਮੂਹ ਪ੍ਰਤੀਕ੍ਰਿਤੀ, ਅਤੇ Kubernetes ਆਪਰੇਟਰ

Azure ਡਾਟਾਬੇਸ MySQL ਲਚਕਦਾਰ ਸਰਵਰਲਈ ਆਟੋਮੈਟਿਕ ਫੇਲਓਵਰ, ਸਮਾਨ-ਖੇਤਰ ਰੀਡ ਪ੍ਰਤੀਕ੍ਰਿਤੀਆਂ, ਅਤੇ 16 TiB ਸਟੋਰੇਜ ਦੇ ਨਾਲ ਜ਼ੋਨ-ਰਿਡੰਡੈਂਟ HA ਦੀ ਪੇਸ਼ਕਸ਼ ਕਰਦਾ ਹੈ। ਇਹ ਸੰਰਚਨਾਯੋਗ ਰੱਖ-ਰਖਾਅ ਵਿੰਡੋਜ਼, ਉਦਾਹਰਨਾਂ ਨੂੰ ਰੋਕਣ/ਸ਼ੁਰੂ ਕਰਨ ਦੀ ਸਮਰੱਥਾ (ਦੇਵ/ਟੈਸਟ ਲਾਗਤ ਬੱਚਤਾਂ ਲਈ ਉਪਯੋਗੀ), ਅਤੇ ਨੈੱਟਵਰਕ ਆਈਸੋਲੇਸ਼ਨ ਲਈ Azure ਪ੍ਰਾਈਵੇਟ ਲਿੰਕ ਨਾਲ ਏਕੀਕਰਣ ਦਾ ਸਮਰਥਨ ਕਰਦਾ ਹੈ। ਕਾਰੋਬਾਰੀ ਨਾਜ਼ੁਕ ਪੱਧਰ ਸਥਾਨਕ SSD ਸਟੋਰੇਜ ਦੇ ਨਾਲ ਵਧੀਆ ਪ੍ਰਦਰਸ਼ਨ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ।

MySQLਲਈ Google ਕਲਾਊਡ SQL ਜ਼ੋਨਾਂ ਵਿੱਚ ਆਟੋਮੈਟਿਕ ਫੇਲਓਵਰ, ਰੀਡ ਰਿਪਲੀਕਾ (ਕ੍ਰਾਸ-ਰੀਜਨ ਸਮੇਤ), ਅਤੇ ਪੁਆਇੰਟ-ਇਨ-ਟਾਈਮ ਰਿਕਵਰੀ ਦੇ ਨਾਲ ਸਵੈਚਲਿਤ ਬੈਕਅੱਪ ਦੇ ਨਾਲ ਖੇਤਰੀ ਉਦਾਹਰਨਾਂ ਦੀ ਪੇਸ਼ਕਸ਼ ਕਰਦਾ ਹੈ। 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 ਇੱਕ ਕਲਾਉਡ-ਨੇਟਿਵ ਡਿਸਟਰੀਬਿਊਟਡ ਬਲਾਕ ਸਟੋਰੇਜ ਸਿਸਟਮ ਹੈ ਜੋ 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। ਰੀਡੋ ਲੌਗ ਨੂੰ ਪ੍ਰਤੀ ਕਮਿਟ 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

Litmus ਜਾਂ 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 ਕਲੱਸਟਰ ਤੇਜ਼ ਹੋ ਸਕਦਾ ਹੈ ਕਿਉਂਕਿ ਕੋਈ ਚੋਣ ਨਹੀਂ ਹੈ (ਸਾਰੇ ਨੋਡ ਲਿਖਣਯੋਗ ਹਨ)।
• ਰਿਕਵਰੀ ਪੁਆਇੰਟ ਆਬਜੈਕਟਿਵ (RPO)— ਫੇਲਓਵਰ ਦੇ ਦੌਰਾਨ ਕਿੰਨਾ ਡਾਟਾ ਖਤਮ ਹੁੰਦਾ ਹੈ? ਸਮਕਾਲੀ ਪ੍ਰਤੀਕ੍ਰਿਤੀ (ਸਿੰਗਲ-ਪ੍ਰਾਇਮਰੀ ਮੋਡ ਵਿੱਚ ਸਮੂਹ ਪ੍ਰਤੀਕ੍ਰਿਤੀ, PXC) ਦੇ ਨਾਲ, ਪ੍ਰਤੀਬੱਧ ਟ੍ਰਾਂਜੈਕਸ਼ਨਾਂ ਲਈ ਆਰਪੀਓ ਜ਼ੀਰੋ ਹੈ। ਅਸਿੰਕ੍ਰੋਨਸ ਰੀਪਲੀਕੇਸ਼ਨ (ਕਲੱਸਟਰਸੈਟ ਕਰਾਸ-ਰੀਜਨ) ਦੇ ਨਾਲ, 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 ਐਂਟਰਪ੍ਰਾਈਜ਼ ਪਲੱਸ (GCP) ਦੀ ਵਰਤੋਂ ਕਰੋ। ਇਹ ਸਭ ਤੋਂ ਘੱਟ ਕਾਰਜਸ਼ੀਲ ਓਵਰਹੈੱਡ ਪ੍ਰਦਾਨ ਕਰਦੇ ਹਨ।
• ਸਿੰਗਲ ਕਲਾਉਡ, ਸਵੈ-ਪ੍ਰਬੰਧਿਤ, ਪੂਰੇ MySQL ਨਿਯੰਤਰਣ ਦੀ ਲੋੜ ਹੈ— ਕਲਾਉਡ-ਨੇਟਿਵ ਸਟੋਰੇਜ ਕਲਾਸਾਂ ਦੇ ਨਾਲ EKS/AKS/GKE 'ਤੇ MySQL ਓਪਰੇਟਰ ਜਾਂ ਪਰਕੋਨਾ ਓਪਰੇਟਰ ਦੀ ਵਰਤੋਂ ਕਰੋ।
• ਮਲਟੀ-ਕਲਾਊਡ ਜਾਂ ਹਾਈਬ੍ਰਿਡ ਕਲਾਊਡ— PXC ਦੇ ਨਾਲ ਪਰਕੋਨਾ ਓਪਰੇਟਰ ਜਾਂ InnoDB ਕਲੱਸਟਰ ਦੇ ਨਾਲ MySQL ਓਪਰੇਟਰ ਦੀ ਵਰਤੋਂ ਕਰੋ। Kubernetes ਐਬਸਟਰੈਕਸ਼ਨ ਲੇਅਰ ਤੁਹਾਡੀ MySQL ਤੈਨਾਤੀ ਨੂੰ ਬੱਦਲਾਂ ਵਿੱਚ ਪੋਰਟੇਬਲ ਬਣਾਉਂਦੀ ਹੈ।
• ਬੇਅਰ ਮੈਟਲ ਜਾਂ ਕਿਨਾਰਾ— ਰੈਂਚਰ, ਲੋਂਗਹੋਰਨ ਸਟੋਰੇਜ, ਮੈਟਲਐਲਬੀ, ਅਤੇ ਜਾਂ ਤਾਂ MySQL ਓਪਰੇਟਰ ਜਾਂ ਪਰਕੋਨਾ ਓਪਰੇਟਰ ਨਾਲ k3s ਦੀ ਵਰਤੋਂ ਕਰੋ।
• ਅਧਿਕਤਮ ਰਾਈਟ ਥ੍ਰੋਪੁੱਟ, ਬਹੁ-ਪ੍ਰਾਇਮਰੀ ਲੋੜੀਂਦਾ— ਪਰਕੋਨਾ ਓਪਰੇਟਰ ਦੇ ਨਾਲ ਪਰਕੋਨਾ ਐਕਸਟਰਾਡੀਬੀ ਕਲੱਸਟਰ (ਗੈਲੇਰਾ) ਦੀ ਵਰਤੋਂ ਕਰੋ। ਸਾਰੇ ਨੋਡ ਸਮਕਾਲੀ ਪ੍ਰਮਾਣੀਕਰਣ ਦੇ ਨਾਲ ਲਿਖਤਾਂ ਨੂੰ ਸਵੀਕਾਰ ਕਰਦੇ ਹਨ।
• ਤਬਾਹੀ ਰਿਕਵਰੀ ਦੇ ਨਾਲ ਗਲੋਬਲ ਵੰਡ— ਖੇਤਰਾਂ ਦੇ ਵਿਚਕਾਰ ਅਸਿੰਕ੍ਰੋਨਸ ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਦੇ ਨਾਲ InnoDB ਕਲੱਸਟਰਸੈੱਟ ਦੀ ਵਰਤੋਂ ਕਰੋ। ਸਥਾਨਕ ਲਿਖਤਾਂ ਦੇ ਲੇਟੈਂਸੀ ਲਾਭਾਂ ਲਈ ਅਸਿੰਕ੍ਰੋਨਸ ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਦੇ ਆਰਪੀਓ ਟ੍ਰੇਡ-ਆਫ ਨੂੰ ਸਵੀਕਾਰ ਕਰੋ।

ਸੰਚਾਲਨ ਜਾਂਚ ਸੂਚੀ

ਆਪਣੀ MySQL HA ਤੈਨਾਤੀ ਉਤਪਾਦਨ-ਤਿਆਰ ਘੋਸ਼ਿਤ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ, ਇਸ ਚੈੱਕਲਿਸਟ 'ਤੇ ਹਰ ਆਈਟਮ ਨੂੰ ਪ੍ਰਮਾਣਿਤ ਕਰੋ।

1. ਕਲੱਸਟਰ ਹੈਲਥ— ਸਾਰੇ ਮੈਂਬਰ ਔਨਲਾਈਨ ਸਥਿਤੀ ਦੀ ਰਿਪੋਰਟ ਕਰਦੇ ਹਨ। ਗਰੁੱਪ ਰਿਪਲੀਕੇਸ਼ਨ ਕੋਈ ਗਲਤੀ ਨਹੀਂ ਦਿਖਾਉਂਦਾ।
2. ਸਵੈਚਲਿਤ ਬੈਕਅੱਪ— ਕਰੋਨਜੌਬ ਜਾਂ ਓਪਰੇਟਰ-ਪ੍ਰਬੰਧਿਤ ਬੈਕਅੱਪ ਸਮਾਂ-ਸਾਰਣੀ 'ਤੇ ਚੱਲ ਰਹੇ ਹਨ। ਸਮੇਂ-ਸਮੇਂ 'ਤੇ ਰੀਸਟੋਰ ਟੈਸਟਾਂ ਦੁਆਰਾ ਪ੍ਰਮਾਣਿਤ ਬੈਕਅੱਪ।
3. ਨਿਗਰਾਨੀ— PMM ਜਾਂ Prometheus/Grafana MySQL ਮੈਟ੍ਰਿਕਸ ਇਕੱਤਰ ਕਰਨਾ। ਰੀਪਲੀਕੇਸ਼ਨ ਲੈਗ, ਕਨੈਕਸ਼ਨ ਸੰਤ੍ਰਿਪਤਾ, ਬਫਰ ਪੂਲ ਹਿੱਟ ਅਨੁਪਾਤ 99% ਤੋਂ ਹੇਠਾਂ, ਅਤੇ ਡਿਸਕ ਸਪੇਸ ਲਈ ਸੰਰਚਿਤ ਚੇਤਾਵਨੀਆਂ।
4. ਫੇਲਓਵਰ ਟੈਸਟ ਕੀਤਾ ਗਿਆ— ਪ੍ਰਾਇਮਰੀ ਫੇਲਓਵਰ ਪਿਛਲੇ 30 ਦਿਨਾਂ ਦੇ ਅੰਦਰ ਟੈਸਟ ਕੀਤਾ ਗਿਆ। RTO ਅਤੇ RPO ਮਾਪਿਆ ਗਿਆ ਅਤੇ SLA ਟੀਚਿਆਂ ਦੇ ਅੰਦਰ।
5. ਕਨੈਕਸ਼ਨ ਰੂਟਿੰਗ— MySQL ਰਾਊਟਰ ਜਾਂ ProxySQL ਸਿਹਤ-ਜਾਂਚ ਅਤੇ ਲੋਡ-ਸੰਤੁਲਿਤ। ਐਪਲੀਕੇਸ਼ਨ ਕਨੈਕਸ਼ਨ ਦੀਆਂ ਸਤਰਾਂ ਰਾਊਟਰ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਦੀਆਂ ਹਨ, ਨਾ ਕਿ ਵਿਅਕਤੀਗਤ MySQL ਉਦਾਹਰਨਾਂ।
6. ਸੁਰੱਖਿਆ— TLS ਸਾਰੇ ਕਨੈਕਸ਼ਨਾਂ ਲਈ ਲੋੜੀਂਦਾ ਹੈ। ਆਰਾਮ 'ਤੇ ਏਨਕ੍ਰਿਪਸ਼ਨ ਸਮਰਥਿਤ ਹੈ। ਇੱਕ ਗੁਪਤ ਮੈਨੇਜਰ ਵਿੱਚ ਸਟੋਰ ਕੀਤੇ ਪ੍ਰਮਾਣ ਪੱਤਰ। ਆਡਿਟ ਲਾਗਿੰਗ ਸਰਗਰਮ ਹੈ। ਹਰੇਕ ਐਪਲੀਕੇਸ਼ਨ ਲਈ ਸਭ ਤੋਂ ਘੱਟ ਵਿਸ਼ੇਸ਼ ਅਧਿਕਾਰ ਵਾਲੇ ਡੇਟਾਬੇਸ ਉਪਭੋਗਤਾ।
7. ਸਰੋਤ ਸੀਮਾਵਾਂ— Kubernetes ਸਰੋਤ ਬੇਨਤੀਆਂ ਅਤੇ ਸੀਮਾਵਾਂ ਉਚਿਤ ਤੌਰ 'ਤੇ ਸੈੱਟ ਕੀਤੀਆਂ ਗਈਆਂ ਹਨ। PodDisruptionBudgets ਜਗ੍ਹਾ ਵਿੱਚ ਹਨ। MySQL ਪੌਡਾਂ ਨੂੰ ਜ਼ੋਨਾਂ ਵਿੱਚ ਫੈਲਾਉਣ ਵਾਲਾ ਪੌਡ ਐਂਟੀ-ਐਫੀਨਿਟੀ।
8. ਸਮਰੱਥਾ ਯੋਜਨਾ— 70% ਅਤੇ 85% 'ਤੇ ਅਲਰਟ ਦੇ ਨਾਲ ਸਟੋਰੇਜ ਉਪਯੋਗਤਾ ਦੀ ਨਿਗਰਾਨੀ ਕੀਤੀ ਗਈ। ਵਾਲੀਅਮ ਵਿਸਥਾਰ ਦੀ ਜਾਂਚ ਕੀਤੀ ਗਈ। ਵਰਟੀਕਲ ਅਤੇ ਹਰੀਜੱਟਲ ਸਕੇਲਿੰਗ ਪ੍ਰਕਿਰਿਆਵਾਂ ਦਾ ਦਸਤਾਵੇਜ਼ੀਕਰਨ ਕੀਤਾ ਗਿਆ ਹੈ।
9. ਰਨਬੁੱਕਾਂ— ਪ੍ਰਾਇਮਰੀ ਫੇਲਓਵਰ, ਨੋਡ ਬਦਲਣ, ਬੈਕਅੱਪ ਰੀਸਟੋਰ, ਵਰਜ਼ਨ ਅੱਪਗਰੇਡ, ਅਤੇ ਐਮਰਜੈਂਸੀ ਰੀਡ-ਓਨਲੀ ਮੋਡ ਲਈ ਦਸਤਾਵੇਜ਼ੀ ਪ੍ਰਕਿਰਿਆਵਾਂ।
10. ਅਰਾਜਕਤਾ ਟੈਸਟਿੰਗ— ਲਚਕੀਲੇਪਣ ਦੀਆਂ ਧਾਰਨਾਵਾਂ ਨੂੰ ਪ੍ਰਮਾਣਿਤ ਕਰਨ ਲਈ ਨਿਯਮਤ ਅਰਾਜਕਤਾ ਪ੍ਰਯੋਗ ਨਿਯਤ ਕੀਤੇ ਗਏ ਹਨ।

ਸਿੱਟਾ

MySQL ਉਤਪਾਦਨ ਵਿੱਚ ਉੱਚ ਉਪਲਬਧਤਾ ਇੱਕ ਸਿੰਗਲ ਟੈਕਨਾਲੋਜੀ ਵਿਕਲਪ ਨਹੀਂ ਹੈ - ਇਹ ਇੰਟਰਲਾਕਿੰਗ ਫੈਸਲਿਆਂ ਦੀ ਇੱਕ ਪ੍ਰਣਾਲੀ ਹੈ ਜੋ ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਪਰਤ, ਆਰਕੈਸਟ੍ਰੇਸ਼ਨ ਪਲੇਟਫਾਰਮ, ਸਟੋਰੇਜ ਸਬ-ਸਿਸਟਮ, ਨਿਗਰਾਨੀ ਸਟੈਕ, ਅਤੇ ਉਹਨਾਂ ਦੇ ਆਲੇ ਦੁਆਲੇ ਸੰਚਾਲਨ ਪ੍ਰਕਿਰਿਆਵਾਂ ਨੂੰ ਫੈਲਾਉਂਦੀ ਹੈ। ਗਰੁੱਪ ਰਿਪਲੀਕੇਸ਼ਨ ਵਾਲਾ InnoDB ਕਲੱਸਟਰ ਫਾਊਂਡੇਸ਼ਨਲ HA ਮੁੱਢਲਾ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ। Oracle ਅਤੇ Percona ਦੇ Kubernetes ਆਪਰੇਟਰ ਜੀਵਨ ਚੱਕਰ ਪ੍ਰਬੰਧਨ ਨੂੰ ਸਵੈਚਲਿਤ ਕਰਦੇ ਹਨ ਜੋ ਨਹੀਂ ਤਾਂ ਮਹੱਤਵਪੂਰਨ ਇੰਜੀਨੀਅਰਿੰਗ ਸਮੇਂ ਦੀ ਖਪਤ ਕਰਨਗੇ। ਸਹੂਲਤ ਲਈ ਕਲਾਉਡ ਪ੍ਰਬੰਧਿਤ ਸੇਵਾਵਾਂ ਵਪਾਰ ਨਿਯੰਤਰਣ। k3s, Rancher, ਅਤੇ Longhorn ਦੇ ਨਾਲ ਬੇਅਰ ਮੈਟਲ ਤੈਨਾਤੀਆਂ ਸਾਬਤ ਕਰਦੀਆਂ ਹਨ ਕਿ ਤੁਹਾਨੂੰ ਉਤਪਾਦਨ-ਗ੍ਰੇਡ MySQL HA ਨੂੰ ਚਲਾਉਣ ਲਈ ਕਲਾਉਡ ਪ੍ਰਦਾਤਾ ਦੀ ਲੋੜ ਨਹੀਂ ਹੈ।

ਸਭ ਤੋਂ ਮਹੱਤਵਪੂਰਨ ਸਮਝ ਇਹ ਹੈ ਕਿ ਉੱਚ ਉਪਲਬਧਤਾ ਪੂਰੇ ਸਿਸਟਮ ਦੀ ਵਿਸ਼ੇਸ਼ਤਾ ਹੈ, ਨਾ ਕਿ ਸਿਰਫ਼ ਡੇਟਾਬੇਸ। ਇਸ ਵਿੱਚ ਇਹ ਸ਼ਾਮਲ ਹੈ ਕਿ ਤੁਹਾਡੀ ਐਪਲੀਕੇਸ਼ਨ ਕਨੈਕਸ਼ਨ ਅਸਫਲਤਾਵਾਂ ਅਤੇ ਮੁੜ ਕੋਸ਼ਿਸ਼ਾਂ ਨੂੰ ਕਿਵੇਂ ਸੰਭਾਲਦੀ ਹੈ, ਤੁਹਾਡੀ ਪ੍ਰੌਕਸੀ ਲੇਅਰ ਅਸਫਲ ਨੋਡਾਂ ਦੇ ਆਲੇ-ਦੁਆਲੇ ਕਿਵੇਂ ਖੋਜਦੀ ਹੈ ਅਤੇ ਕਿਵੇਂ ਰੂਟ ਕਰਦੀ ਹੈ, ਉਪਭੋਗਤਾਵਾਂ ਦੇ ਧਿਆਨ ਵਿੱਚ ਆਉਣ ਤੋਂ ਪਹਿਲਾਂ ਤੁਹਾਡੀ ਨਿਗਰਾਨੀ ਕਿਵੇਂ ਚੇਤਾਵਨੀ ਦਿੰਦੀ ਹੈ, ਤੁਹਾਡੀ ਬੈਕਅਪ ਰਣਨੀਤੀ ਉਹਨਾਂ ਸਥਿਤੀਆਂ ਤੋਂ ਰਿਕਵਰੀ ਨੂੰ ਕਿਵੇਂ ਸਮਰੱਥ ਬਣਾਉਂਦੀ ਹੈ ਜਿਨ੍ਹਾਂ ਨੂੰ HA ਇਕੱਲੇ ਨਹੀਂ ਸੰਭਾਲ ਸਕਦਾ, ਅਤੇ ਤੁਹਾਡੀ ਟੀਮ ਫੇਲਓਵਰ ਪ੍ਰਕਿਰਿਆਵਾਂ ਦਾ ਅਭਿਆਸ ਕਿਵੇਂ ਕਰਦੀ ਹੈ ਤਾਂ ਜੋ ਉਹ ਇੱਕ ਅਸਲ ਘਟਨਾ ਦੇ ਤਣਾਅ ਵਿੱਚ ਸਾਫ਼-ਸੁਥਰੇ ਢੰਗ ਨਾਲ ਲਾਗੂ ਕਰੇ।

ਇਸ ਨੂੰ ਜਾਣਬੁੱਝ ਕੇ ਬਣਾਓ, ਨਿਯਮਿਤ ਤੌਰ 'ਤੇ ਇਸ ਦੀ ਜਾਂਚ ਕਰੋ, ਅਤੇ ਆਪਣੀਆਂ ਰਨਬੁੱਕਾਂ ਨੂੰ ਜੀਵਿਤ ਦਸਤਾਵੇਜ਼ਾਂ ਦੇ ਰੂਪ ਵਿੱਚ ਵਰਤੋ ਜੋ ਹਰ ਘਟਨਾ ਅਤੇ ਹਰ ਹਫੜਾ-ਦਫੜੀ ਦੇ ਪ੍ਰਯੋਗ ਨਾਲ ਵਿਕਸਤ ਹੁੰਦੇ ਹਨ। ਇਸ ਤਰ੍ਹਾਂ MySQL ਉਤਪਾਦਨ ਵਿੱਚ ਇੱਕ ਭਰੋਸੇਮੰਦ, ਉੱਚ ਉਪਲਬਧ ਡਾਟਾ ਪਲੇਟਫਾਰਮ ਵਜੋਂ ਆਪਣੀ ਥਾਂ ਕਮਾਉਂਦਾ ਹੈ।