MySQL উৎপাদনে উচ্চ প্রাপ্যতা: InnoDB ক্লাস্টার, গ্রুপ রেপ্লিকেশন, এবং Kubernetes অপারেটর

Azure ডাটাবেস MySQL নমনীয় সার্ভারের জন্যস্বয়ংক্রিয় ফেইলওভার, একই-অঞ্চল রিড রেপ্লিকা এবং 16 টি টিবি স্টোরেজ সহ জোন-অপ্রয়োজনীয় HA অফার করে। এটি কনফিগারযোগ্য রক্ষণাবেক্ষণ উইন্ডো, দৃষ্টান্ত বন্ধ/শুরু করার ক্ষমতা (ডেভ/পরীক্ষা খরচ সঞ্চয়ের জন্য দরকারী), এবং নেটওয়ার্ক বিচ্ছিন্নতার জন্য Azure প্রাইভেট লিঙ্কের সাথে একীকরণ সমর্থন করে। বিজনেস ক্রিটিক্যাল টিয়ার স্থানীয় SSD স্টোরেজের সাথে সেরা পারফরম্যান্স প্রদান করে।

MySQLএর জন্য Google ক্লাউড SQL অঞ্চল জুড়ে স্বয়ংক্রিয় ব্যর্থতা সহ আঞ্চলিক দৃষ্টান্তগুলি অফার করে, প্রতিলিপিগুলি পড়ুন (ক্রস-অঞ্চল সহ), এবং পয়েন্ট-ইন-টাইম পুনরুদ্ধারের সাথে স্বয়ংক্রিয় ব্যাকআপ৷ ক্লাউড 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 -

লংহর্ন স্টোরেজ

লংহর্ন হল একটি ক্লাউড-নেটিভ ডিস্ট্রিবিউটেড ব্লক স্টোরেজ সিস্টেম যা 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

বেয়ার মেটালে, কোন ক্লাউড লোড ব্যালেন্সার নেই। মেটালএলবি লেয়ার 2 (ARP) বা BGP মোড ব্যবহার করে Kubernetes ধরনের লোডব্যালেন্সার পরিষেবাগুলিতে বাহ্যিক আইপি ঠিকানা বরাদ্দ করে এই শূন্যতা পূরণ করে।

# 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 গিগাবাইটের নিচে ডাটাবেসের জন্য, এটি সবচেয়ে সহজ বিকল্প। বৃহত্তর ডেটাসেটের জন্য, লকিং এবং রপ্তানির সময় ব্যবসায়িক সময়ে উত্পাদন ব্যবহারের জন্য এটিকে অবাস্তব করে তোলে।

# 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 লগ প্রতি কমিটে 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

কেওস ইঞ্জিনিয়ারিং

স্ট্রাকচার্ড কেওস ইঞ্জিনিয়ারিং টুলগুলি পদ্ধতিগতভাবে ব্যর্থতাগুলিকে ইনজেক্ট করে এবং বিস্ফোরণের ব্যাসার্ধ পরিমাপ করে। ক্যাওস মেশ, একটি 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-সামঞ্জস্যপূর্ণ— অরোরা (AWS), নমনীয় সার্ভার বিজনেস ক্রিটিক্যাল (Azure), অথবা ক্লাউড SQL এন্টারপ্রাইজ প্লাস (GCP) ব্যবহার করুন। এগুলি সর্বনিম্ন অপারেশনাল ওভারহেড প্রদান করে।
• একক ক্লাউড, স্ব-পরিচালিত, সম্পূর্ণ MySQL নিয়ন্ত্রণ প্রয়োজন— ক্লাউড-নেটিভ স্টোরেজ ক্লাস সহ EKS/AKS/GKE-এ MySQL অপারেটর বা পারকোনা অপারেটর ব্যবহার করুন।
• মাল্টি-ক্লাউড বা হাইব্রিড ক্লাউড— PXC সহ Percona অপারেটর বা InnoDB ক্লাস্টার সহ MySQL অপারেটর ব্যবহার করুন। Kubernetes বিমূর্ততা স্তরটি আপনার MySQL স্থাপনাকে মেঘ জুড়ে বহনযোগ্য করে তোলে।
• বেয়ার মেটাল বা প্রান্ত— Rancher, Longhorn স্টোরেজ, MetalLB, এবং MySQL অপারেটর বা Percona অপারেটরের সাথে k3s ব্যবহার করুন।
• সর্বাধিক লেখার থ্রুপুট, বহু-প্রাথমিক প্রয়োজনীয়— Percona অপারেটরের সাথে Percona XtraDB ক্লাস্টার (Galera) ব্যবহার করুন। সমস্ত নোড সিঙ্ক্রোনাস সার্টিফিকেশন সহ লেখা গ্রহণ করে।
• দুর্যোগ পুনরুদ্ধারের সাথে বিশ্বব্যাপী বিতরণ— অঞ্চলগুলির মধ্যে অ্যাসিঙ্ক্রোনাস প্রতিলিপি সহ InnoDB ClusterSet ব্যবহার করুন। স্থানীয় লেখার লেটেন্সি সুবিধার জন্য অ্যাসিঙ্ক্রোনাস রেপ্লিকেশনের RPO ট্রেড-অফ গ্রহণ করুন।

অপারেশনাল চেকলিস্ট 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. পড অ্যান্টি-অ্যাফিনিটি অঞ্চল জুড়ে MySQL পড ছড়াচ্ছে।
8. ক্যাপাসিটি প্ল্যান— সঞ্চয়স্থানের ব্যবহার 70% এবং 85% এ সতর্কতার সাথে পর্যবেক্ষণ করা হয়েছে। ভলিউম সম্প্রসারণ পরীক্ষিত. উল্লম্ব এবং অনুভূমিক স্কেলিং পদ্ধতি নথিভুক্ত.
9. Runbooks— প্রাথমিক ফেইলওভার, নোড প্রতিস্থাপন, ব্যাকআপ পুনরুদ্ধার, সংস্করণ আপগ্রেড এবং জরুরী রিড-ওনলি মোডের জন্য নথিভুক্ত পদ্ধতি।
10. ক্যাওস টেস্টিং— স্থিতিস্থাপক অনুমান যাচাই করার জন্য নিয়মিত বিশৃঙ্খলা পরীক্ষাগুলি নির্ধারিত৷

উপসংহার

MySQL উৎপাদনে উচ্চ প্রাপ্যতা একক প্রযুক্তির পছন্দ নয় - এটি ইন্টারলকিং সিদ্ধান্তের একটি সিস্টেম যা রেপ্লিকেশন লেয়ার, অর্কেস্ট্রেশন প্ল্যাটফর্ম, স্টোরেজ সাবসিস্টেম, মনিটরিং স্ট্যাক এবং তাদের চারপাশে অপারেশনাল প্রক্রিয়াগুলিকে বিস্তৃত করে। গ্রুপ রেপ্লিকেশন সহ InnoDB ক্লাস্টার ফাউন্ডেশনাল HA আদিম প্রদান করে। Oracle এবং Percona থেকে Kubernetes অপারেটররা লাইফসাইকেল ম্যানেজমেন্টকে স্বয়ংক্রিয়ভাবে পরিচালনা করে যা অন্যথায় উল্লেখযোগ্য ইঞ্জিনিয়ারিং সময় ব্যয় করবে। সুবিধার জন্য ক্লাউড পরিচালিত পরিষেবা বাণিজ্য নিয়ন্ত্রণ। k3s, Rancher, এবং Longhorn-এর সাথে বেয়ার মেটাল ডিপ্লোয়মেন্ট প্রমাণ করে যে প্রোডাকশন-গ্রেড MySQL HA চালানোর জন্য আপনার ক্লাউড প্রদানকারীর প্রয়োজন নেই।

সবচেয়ে গুরুত্বপূর্ণ অন্তর্দৃষ্টি হল যে উচ্চ প্রাপ্যতা সমগ্র সিস্টেমের একটি সম্পত্তি, শুধু ডাটাবেস নয়। এতে আপনার অ্যাপ্লিকেশন কীভাবে সংযোগ ব্যর্থতা এবং পুনঃপ্রচারগুলি পরিচালনা করে, কীভাবে আপনার প্রক্সি স্তর ব্যর্থ নোডগুলির চারপাশে শনাক্ত করে এবং রুট করে, ব্যবহারকারীদের লক্ষ্য করার আগে কীভাবে আপনার পর্যবেক্ষণ সতর্কতা, কীভাবে আপনার ব্যাকআপ কৌশল এমন পরিস্থিতিগুলি থেকে পুনরুদ্ধার করতে সক্ষম করে যা HA একা পরিচালনা করতে পারে না এবং কীভাবে আপনার দল ব্যর্থতার পদ্ধতিগুলি অনুশীলন করে যাতে তারা একটি বাস্তব ঘটনার চাপের মধ্যে পরিষ্কারভাবে সম্পাদন করে।

এটিকে ইচ্ছাকৃতভাবে তৈরি করুন, এটি নিয়মিত পরীক্ষা করুন এবং আপনার রানবুকগুলিকে জীবন্ত নথি হিসাবে বিবেচনা করুন যা প্রতিটি ঘটনা এবং প্রতিটি বিশৃঙ্খলা পরীক্ষার সাথে বিকশিত হয়৷ এইভাবে MySQL উৎপাদনে একটি নির্ভরযোগ্য, অত্যন্ত উপলভ্য ডেটা প্ল্যাটফর্ম হিসাবে তার স্থান অর্জন করে।