توفر MySQL بدرجة عالية في الإنتاج: مجموعة InnoDB، والنسخ المتماثل للمجموعة، ومشغلي Kubernetes

يعد تشغيل MySQL في الإنتاج أمرًا مألوفًا لمعظم الفرق الهندسية. إن تشغيله بتوفر عالي حقيقي - حيث لا يؤدي فشل العقدة، أو قسم الشبكة، أو منطقة التوفر بأكملها إلى الظلام إلى التوقف عن العمل أو فقدان البيانات - يتطلب بنية متعمدة. يتجول هذا الدليل عبر كل طبقة من تلك البنية: بدءًا من أساسيات النسخ المتماثل داخل MySQL نفسها، مروراً بمشغلي Kubernetes الذين يقومون بأتمتة إدارة دورة الحياة، وعبر الخيارات المدارة والمدارة ذاتيًا في كل مزود سحابي رئيسي، وصولاً إلى مجموعات k3s المعدنية العارية التي تديرها Rancher.

بحلول نهاية هذه المقالة، سيكون لديك نموذج ذهني كامل لاختيار وتشغيل MySQL HA في الإنتاج، إلى جانب أمثلة التكوين الملموسة التي يمكنك التكيف مع بيئتك الخاصة.

MySQL InnoDB البنية العنقودية

InnoDB Cluster هو حل Oracle المتكامل عالي التوفر لـ MySQL. فهو يجمع بين ثلاثة مكونات: MySQL Group Replication لمزامنة البيانات، وMySQL Shell لإدارة المجموعة، وMySQL Router لتوجيه الاتصال الشفاف وتجاوز الفشل التلقائي. ويشكلون معًا مجموعة ذاتية الإصلاح يمكنها تحمل فشل العقد دون تدخل يدوي.

التصميم أنيق في بساطته. تتصل التطبيقات بجهاز التوجيه MySQL، الذي يحافظ على الوعي بطوبولوجيا المجموعة من خلال الاستعلام عن مخطط البيانات الوصفية InnoDB Cluster. عندما يفشل الإجراء الأساسي، يختار النسخ المتماثل للمجموعة أساسيًا جديدًا من المرتبات الثانوية المتبقية، ويقوم جهاز التوجيه MySQL تلقائيًا بإعادة توجيه حركة مرور الكتابة إلى الأساسي الجديد - عادةً في غضون ثوانٍ. يمكن توزيع حركة القراءة عبر جميع المرتبات الثانوية لقياس القراءة الأفقي.

أساسيات النسخ المتماثل للمجموعة

MySQL Group Replication هو أساس مجموعة InnoDB. ويستخدم بروتوكول إجماع قائم على Paxos لضمان تكرار كل معاملة يتم تنفيذها على المستوى الأساسي إلى غالبية العقد قبل أن يتم الاعتراف بها. يوفر هذا النسخ المتزامن الظاهري لـ- وهو ضمان بوجود البيانات الملتزم بها على أغلبية أعضاء المجموعة على الأقل في وقت الالتزام.

في وضعين:

• الوضع الأساسي الفردي- تقبل عقدة واحدة الكتابة (الأساسية)؛ جميع الآخرين هم المرتبات الثانوية للقراءة فقط. هذا هو الوضع الموصى به والافتراضي. إنه يتجنب تعارضات الكتابة تمامًا لأن عقدة واحدة فقط يمكنها إنشاء المعاملات.
• الوضع الأساسي المتعدد- تقبل جميع العقد الكتابة في وقت واحد. يوفر هذا إنتاجية كتابة أعلى لأحمال العمل التي يتم تقسيمها بشكل نظيف عبر جداول أو مساحات مفاتيح مختلفة، ولكنه يقدم إمكانية حدوث تعارضات في الشهادات عندما تقوم المعاملات المتزامنة بتعديل نفس الصفوف. يتم إرجاع المعاملات المتضاربة إلى عقدة واحدة. استخدم الأساسيات المتعددة فقط عندما يكون تطبيقك مصممًا للتعامل مع حالات فشل الشهادات وإعادة محاولة المنطق.

إعداد مجموعة InnoDB باستخدام MySQL Shell

MySQL Shell 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 Clone Plugin لإجراء نسخة كاملة من البيانات من الأساسي إلى العضو المنضم، وهو أسرع بكثير من الاسترداد المتزايد من السجلات الثنائية لمجموعات البيانات الكبيرة.

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 ClusterSet على توسيع مجموعة InnoDB لدعم النسخ المتماثل غير المتزامن بين المجموعة الأساسية وواحدة أو أكثر من مجموعات النسخ المتماثلة في مناطق مختلفة.

InnoDB ClusterSet مع مجموعة أساسية واحدة تعالج جميع عمليات الكتابة، ومجموعة واحدة أو أكثر من المجموعات المتماثلة التي تتلقى التغييرات بشكل غير متزامن. في سيناريو الكوارث، يمكن ترقية مجموعة النسخة المتماثلة إلى المجموعة الأساسية عبر MySQL Shell.

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

MySQL على Kubernetes — نمط المشغل

يتطلب تشغيل MySQL على Kubernetes حل العديد من التحديات التي لا تنطبق على أحمال العمل عديمة الحالة: هويات الشبكة المستقرة، والتخزين المستمر، وبدء التشغيل وإيقاف التشغيل المطلوب، والفحوصات الصحية المدركة للمجموعة. يقوم مشغلو Kubernetes بتشفير هذه المعرفة التشغيلية الخاصة بالمجال في وحدة تحكم تراقب الموارد المخصصة وتقوم بتسوية الحالة الفعلية لـ MySQL مع الحالة المطلوبة المعلنة في YAML.

MySQL لـ Kubernetes (Oracle)

يقوم مشغل MySQL من Oracle لـ Kubernetes بنشر مثيلات InnoDB Cluster وإدارتها محليًا على Kubernetes. فهو يقوم بإنشاء StatefulSets لكبسولات خادم 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)

Percona لـ MySQL بنشر Percona XtraDB Cluster (PXC)، وهو حل نسخ متزامن متعدد الأساسيات يعتمد على Galera. تختلف PXC عن InnoDB Cluster حيث أن كل عقدة يمكنها قبول عمليات الكتابة (أساسية متعددة حقيقية)، ويكون النسخ متزامنًا على مستوى الشهادة باستخدام 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

يعالج مشغل Percona عمليات النسخ الاحتياطي التلقائي إلى S3، والاسترداد في الوقت المناسب، والترقيات المتجددة، وProxySQL أو HAProxy لتوجيه الاتصال. يوفر النسخ المتماثل القائم على Galera في PXC عمليات كتابة حقيقية ومتزامنة ومتعددة الأولية - حيث يتم ضمان وجود كل معاملة ملتزم بها على جميع العقد.

: جهاز التوجيه MySQL مقابل ProxySQL

يعمل كل من جهاز التوجيه MySQL وProxySQL كوكلاء لقاعدة البيانات، لكن لديهم نقاط قوة مختلفة.

MySQL Routerخصيصًا لمجموعة 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 Multi-AZ مقابل Aurora مقابل الإدارة الذاتية على EKS

يوفر Amazon RDS Multi-AZتجاوز الفشل تلقائيًا بين المثيل الأساسي والمثيل الاحتياطي في مناطق توافر مختلفة. يستغرق تجاوز الفشل عادةً من 60 إلى 120 ثانية. يستخدم النسخ المتماثل الفعلي في وضع الاستعداد. يمكن إضافة النسخ المتماثلة للقراءة لقياس القراءة ولكنها تستخدم النسخ المتماثل غير المتزامن. يتعامل RDS مع النسخ الاحتياطية والتصحيح والمراقبة ولكنه يحد من تحكمك في تكوين MySQL واختيار الإصدار.

Amazon Aurora MySQLعبارة عن إعادة كتابة سحابية أصلية لمحرك التخزين MySQL. فهو يفصل بين الحوسبة والتخزين - طبقة التخزين عبارة عن نظام موزع ومتسامح مع الأخطاء ويقوم بنسخ البيانات بستة طرق عبر ثلاث مناطق توافر خدمات. توفر Aurora تجاوزًا للفشل خلال أقل من 10 ثوانٍ، وما يصل إلى 15 نسخة متماثلة للقراءة مع الحد الأدنى من تأخر النسخ المتماثل، وتوسيع نطاق التخزين التلقائي حتى 128 تيرابايت. يضيف الإصدار الثاني من Aurora Serverless مقياسًا حسابيًا تلقائيًا لأحمال العمل غير المتوقعة. المقايضة هي التكلفة (Aurora أغلى بنسبة 20-40٪ من RDS) وانخفاض التوافق مع بعض ميزات 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

Azure لخادم MySQL المرنHA زائدة عن الحاجة للمنطقة مع تجاوز الفشل التلقائي، ونسخ متماثلة للقراءة في نفس المنطقة، وما يصل إلى 16 تيرابايت من التخزين. وهو يدعم نوافذ الصيانة القابلة للتكوين، والقدرة على إيقاف/بدء تشغيل المثيلات (مفيدة لتوفير تكاليف التطوير/الاختبار)، والتكامل مع Azure Private Link لعزل الشبكة. توفر طبقة Business Critical أفضل أداء مع تخزين SSD المحلي.

تتم إدارته ذاتيًا على AKS يستخدمالأقراص المدارة Azure (يوصى بـ Premium SSD v2 لأحمال عمل قاعدة البيانات) مع مشغل MySQL أو مشغل Percona. توفر AKS دعمًا لمناطق التوافر وAzure CNI لتكامل VNET على مستوى الكبسولة.

# 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 Cloud: Cloud SQL مقابل الإدارة الذاتية على GKE

يوفر Google Cloud SQL لـ MySQLمثيلات إقليمية مع تجاوز الفشل التلقائي عبر المناطق، وقراءة النسخ المتماثلة (بما في ذلك عبر المناطق)، والنسخ الاحتياطي الآلي مع الاسترداد في نقطة زمنية معينة. يوفر Cloud SQL أعلى مستوى من الراحة المُدارة من خلال التكامل مع نظام Google IAM وVPC ونظام المراقبة. تضيف طبقة Enterprise Plus صيانة قريبة من الصفر وذاكرة تخزين مؤقت للبيانات لتحسين أداء القراءة.

مُدار ذاتيًا على GKE يستخدمالقرص الثابت SSD أو Hyperdisk للتخزين. يعمل GKE Autopilot على تبسيط إدارة العقد ويمكنه تشغيل مشغل 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 + Rancher + Longhorn

لا ينتمي كل عبء عمل إلى السحابة العامة. بالنسبة لسيادة البيانات أو الامتثال أو تحسين التكلفة أو متطلبات زمن الوصول، توفر مجموعات Kubernetes المعدنية العارية التي تعمل بـ k3s مع إدارة Rancher وتخزين Longhorn منصة على مستوى الإنتاج لـ 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

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 بسد هذه الفجوة عن طريق تعيين عناوين IP خارجية لخدمات Kubernetes من النوع LoadBalancer باستخدام إما وضع الطبقة الثانية (ARP) أو BGP.

# 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

يُنتجmysqldumpنسخًا احتياطية بتنسيق SQL تكون محمولة ويمكن قراءتها بواسطة الإنسان. بالنسبة لقواعد البيانات التي يقل حجمها عن 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

السجل الثنائي (binlog) استرداد النقطة في الوقت المناسب

كل معاملة لتعديل البيانات. وبدمجها مع النسخ الاحتياطي الكامل، فإنها تتيح إمكانية الاسترداد في نقطة زمنية (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 النسخ الاحتياطي CronJob

في Kubernetes، يجب تشغيل النسخ الاحتياطية كأوامر CronJobs بدلاً من الأوامر المخصصة. ويضمن ذلك إجراء عمليات النسخ الاحتياطي تلقائيًا ومراقبتها ويمكن تنبيهك في حالة فشلها.

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

مع مراقبة وإدارة Percona (PMM)

Percona Monitoring and Management (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 Buffer Pool

تجمع المخزن المؤقت InnoDB هو المكان الذي يقوم فيه MySQL بتخزين بيانات الجدول والفهرس في الذاكرة. إنها معلمة التكوين الأكثر تأثيرًا. بالنسبة لخادم MySQL مخصص، اضبطه على 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_redo_log_capacityبدلاً منinnodb_log_file_sizeالأقدم.

[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. تتم كتابة سجل الإعادة في ذاكرة التخزين المؤقت لنظام التشغيل لكل التزام ولكن يتم مسحه على القرص مرة واحدة فقط في الثانية. يمكن فقدان ما يصل إلى ثانية واحدة من المعاملات عند تعطل نظام التشغيل (لا يزال تعطل MySQL آمنًا).
• أقصى أداء(غير موصى به للإنتاج):innodb_flush_log_at_trx_commit=0+sync_binlog=0. تتم عمليات الكتابة على دفعات ومسحها بشكل دوري. خطر خسارة ما يصل إلى ثانية واحدة من المعاملات عند حدوث أي حادث.

[mysqld]
# Production durability settings
innodb_flush_log_at_trx_commit = 1
sync_binlog = 1
innodb_doublewrite = ON
innodb_checksum_algorithm = crc32

تكوين الإدخال/الإخراج

[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 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 صفرًا للمعاملات الملتزم بها. مع النسخ المتماثل غير المتزامن (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. قم بتحديث خطة السعة الخاصة بك: التشغيل باستخدام عقدتين يعني أنه ليس لديك أي تسامح مع الأخطاء حتى تتم استعادة الثالثة

تقوية الأمان

العديد من المخاوف الأمنية بما يتجاوز المصادقة الأساسية.

أثناء النقل وفي حالة الراحة

[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)، أو Elastic Server Business Critical (Azure)، أو Cloud SQL Enterprise Plus (GCP). هذه توفر أقل النفقات التشغيلية.
• تحتاج السحابة الواحدة، المُدارة ذاتيًا، إلى التحكم الكامل في MySQL- استخدم مشغل MySQL أو مشغل Percona على EKS/AKS/GKE مع فئات التخزين السحابية الأصلية.
• سحابة متعددة السحابة أو هجينة- استخدم مشغل Percona مع مشغل PXC أو MySQL مع مجموعة InnoDB. تعمل طبقة التجريد Kubernetes على جعل نشر MySQL الخاص بك قابلاً للحمل عبر السحابة.
• المعدن العاري أو الحافة— استخدم k3s مع Rancher، وتخزين Longhorn، وMetalLB، وإما مشغل MySQL أو مشغل Percona.
• الحد الأقصى لإنتاجية الكتابة، مطلوب متعدد أساسي— استخدم Percona XtraDB Cluster (Galera) مع مشغل Percona. تقبل جميع العقد الكتابة بشهادة متزامنة.
• التوزيع العالمي مع التعافي من الكوارث- استخدم InnoDB ClusterSet مع النسخ المتماثل غير المتزامن بين المناطق. اقبل مقايضة RPO للنسخ المتماثل غير المتزامن للحصول على فوائد زمن الوصول للكتابة المحلية.

لإنتاج MySQL HA

قبل الإعلان عن جاهزية نشر MySQL HA للإنتاج، تحقق من صحة كل عنصر في قائمة التحقق هذه.

1. صحة المجموعة— يبلغ جميع الأعضاء عن حالة الاتصال بالإنترنت. النسخ المتماثل للمجموعة لا يظهر أية أخطاء.
2. النسخ الاحتياطية التلقائية— CronJob أو النسخ الاحتياطية التي يديرها المشغل تعمل في الموعد المحدد. تم التحقق من النسخ الاحتياطية عن طريق اختبارات الاستعادة الدورية.
مراقبة
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. Runbooks— إجراءات موثقة لتجاوز الفشل الأساسي، واستبدال العقدة، واستعادة النسخة الاحتياطية، وترقية الإصدار، ووضع القراءة فقط في حالات الطوارئ.
10. اختبار الفوضى- تمت جدولة تجارب الفوضى المنتظمة للتحقق من صحة افتراضات المرونة.

MySQL لا يعد التوفر العالي في الإنتاج خيارًا تكنولوجيًا واحدًا - بل هو نظام من القرارات المتشابكة التي تمتد عبر طبقة النسخ المتماثل، ومنصة التنسيق، ونظام التخزين الفرعي، ومكدس المراقبة، والعمليات التشغيلية المحيطة بها. توفر مجموعة InnoDB مع النسخ المتماثل للمجموعة HA الأساسي. يقوم مشغلو Kubernetes من Oracle وPercona بأتمتة إدارة دورة الحياة التي قد تستهلك وقتًا هندسيًا كبيرًا. التحكم في تجارة الخدمات السحابية المُدارة من أجل الراحة. تثبت عمليات النشر المعدنية العارية مع k3s وRancher وLonghorn أنك لا تحتاج إلى موفر سحابي لتشغيل MySQL HA على مستوى الإنتاج.

الفكرة الأكثر أهمية هي أن التوفر العالي هو خاصية النظام بأكمله، وليس قاعدة البيانات فقط. يتضمن كيفية تعامل تطبيقك مع حالات فشل الاتصال وإعادة المحاولة، وكيف تكتشف طبقة الوكيل الخاصة بك العقد الفاشلة وتتجول حولها، وكيف تنبهك المراقبة قبل أن يلاحظ المستخدمون، وكيف تتيح إستراتيجية النسخ الاحتياطي الخاصة بك الاسترداد من السيناريوهات التي لا يستطيع HA وحده التعامل معها، وكيف يمارس فريقك إجراءات تجاوز الفشل بحيث يتم تنفيذها بشكل نظيف تحت ضغط حادث حقيقي.

قم بتصميمه بشكل متعمد، واختبره بانتظام، وتعامل مع دفاتر التشغيل الخاصة بك كمستندات حية تتطور مع كل حادثة وكل تجربة فوضى. هذه هي الطريقة التي تكتسب بها MySQL مكانتها كمنصة بيانات موثوقة ومتاحة للغاية في الإنتاج.