أساسيات السحابة: خدمات AWS الأساسية

RDS وقواعد البيانات المُدارة

18 دقيقة الدرس 6 من 30

RDS وقواعد البيانات المُدارة

تتولى خدمة Amazon RDS (Relational Database Service) المهام الثقيلة غير المُميَّزة لعمليات قواعد البيانات — تصحيح نظام التشغيل، وتوفير التخزين، وإعداد النسخ المتطابقة، والنسخ الاحتياطية، والتعافي من الأعطال — لتتركز طاقة فريقك على تصميم المخطط وأداء الاستعلامات. لكن "مُدارة" لا تعني "سحرية". للتشغيل الآمن على نطاق إنتاجي، تحتاج إلى فهم آليات RDS الداخلية: أي محرك تختار، وكيف يعمل التعافي التلقائي في Multi-AZ فعلياً، ومتى تفيد نسخ القراءة (ومتى لا تفيد)، وكيف تُمكّنك مجموعات المعاملات من ضبط المحرك دون الحاجة إلى صلاحيات SSH.

المحركات المدعومة

تدعم RDS ستة محركات لقواعد البيانات. كل محرك على RDS هو الثنائي الأصلي مفتوح المصدر أو التجاري — وليس نسخة مُعدَّلة — لذا تنتقل خبرتك الحالية وبروتوكولاتك وأطر عملك دون أي تعديل.

MySQL — الخيار الافتراضي لتطبيقات الويب. تدعم RDS MySQL الإصدارين 5.7 و8.0. اختر 8.0 للحصول على دوال النوافذ (window functions) وتعبيرات CTE وإعدادات InnoDB المحسّنة.
PostgreSQL — المُفضَّل في كبرى شركات التقنية لامتثاله الصارم لمعيار SQL وفهرسة JSONB والنسخ المنطقي والإضافات. تدعم RDS الإصدارات pg 13–16. استخدم pg_stat_statements وauto_explain عبر مجموعات المعاملات لتشخيص الاستعلامات البطيئة دون صلاحيات shell.
MariaDB — نسخة مشتقة من MySQL. يجعل نموذج thread-pool الخاص بها مناسباً لأحمال العمل عالية التزامن التي تُربك نموذج MySQL ذا الخيط الواحد لكل اتصال.
Oracle وSQL Server — متاحان لسيناريوهات نقل تراخيص المؤسسات (BYOL أو License Included). تجنّبهما للمشاريع الجديدة؛ إذ تتأخر ميزات الإدارة فيهما مقارنةً بالمحركات مفتوحة المصدر.
Amazon Aurora — محرك AWS السحابي الأصيل بنقاط نهاية متوافقة مع MySQL وPostgreSQL. يستبدل طبقة التخزين على القرص بوحدة تخزين موزعة تُعالج نفسها ذاتياً بستة نسخ موزعة عبر ثلاث مناطق توافر (AZs). يُقلّص Aurora وقت الاسترداد من دقائق إلى أقل من 30 ثانية ويلغي تأخير النسخ المتطابقة للقراءات.

للخدمات الإنتاجية الجديدة على نطاق واسع، افترض استخدام Aurora PostgreSQL. يجمع بين أغنى مجموعة ميزات SQL (PostgreSQL) وبنية تخزين Aurora: لا نسخ متطابقة مبنية على binlog، ولا إشكاليات حدود التخزين، وزمن تعافٍ شبه صفري. ارجع إلى RDS PostgreSQL القياسية فقط عندما تحتاج إضافات لا تدعمها Aurora مثل TimescaleDB.

Multi-AZ مقابل نسخ القراءة

كثيراً ما يختلط هذان المفهومان لأن كليهما يتضمن نسخة ثانية من قاعدة البيانات. في الحقيقة، يحلّان مشكلتين مختلفتين تماماً.

Multi-AZ آلية توافر عالٍ. يُوفّر AWS نسخة احتياطية متزامنة (standby) في منطقة توافر مختلفة. كل عملية كتابة على الخادم الأساسي تُودَع بشكل متزامن على الخادم الاحتياطي قبل أن تعود العملية بنجاح للتطبيق. إذا فشل الخادم الأساسي — عطل عتاد، أو انقطاع منطقة التوافر، أو تعطل نظام التشغيل — يُحدّث RDS سجل CNAME الخاص بنقطة النهاية ليشير إلى الخادم الاحتياطي خلال 60–120 ثانية. يُعيد تطبيقك الاتصال بنفس اسم المضيف ويستأنف عمله. الخادم الاحتياطي غير مرئي لتطبيقك في التشغيل الاعتيادي ولا يُستخدم للقراءة أبداً. تدفع ثمنه كاملاً ليبقى خاملاً جاهزاً للاستلام — وهي المقايضة الصحيحة للإنتاج: الموثوقية على حساب التكلفة.

نسخ القراءة (Read Replicas) آلية توسيع نطاق القراءة. تستخدم RDS النسخ غير المتزامن (السجل الثنائي لـ MySQL/MariaDB، والنسخ التدفقي لـ PostgreSQL) لنقل عمليات الكتابة من الخادم الأساسي إلى نسخة أو أكثر. لكل نسخة نقطة نهاية DNS خاصة بها ويمكنها خدمة استعلامات SELECT، مُخفِّفةً الضغط عن الخادم الأساسي. النسخ غير متزامن، لذا قد تتأخر النسخ عن الخادم الأساسي بميلي ثوانٍ إلى ثوانٍ تحت حمل كتابة ثقيل. القراءات من النسخة متسقة في نهاية المطاف وليست متسقة قوياً. نسخ القراءة ليست أهدافاً تلقائية للتعافي من الأعطال بشكل افتراضي — يجب عليك الترقية اليدوية لأحدها وتحديث سلاسل الاتصال. يمكنك إنشاء حتى 5 نسخ قراءة لكل مثيل RDS (15 لـ Aurora).

الخادم الاحتياطي Multi-AZ (متزامن، لا حركة مرور) إلى جانب نسختَي قراءة (غير متزامنتان، حركة SELECT) على نفس الخادم الأساسي.

خطأ شائع في الإنتاج: توجيه استعلامات التقارير إلى نسخة القراءة بافتراض أن البيانات متسقة تماماً. الحقيقة أنها ليست كذلك. كتابة اكتملت على الخادم الأساسي قبل ثانية قد لا تكون مرئية بعد على النسخة. أي مسار في الكود يتطلب اتساقاً فورياً بعد الكتابة — مثل عرض سجل لحظة إنشائه — يجب أن يقرأ دائماً من نقطة نهاية الخادم الأساسي.

النسخ الاحتياطية التلقائية واللقطات اليدوية

توفر RDS آليتَي نسخ احتياطي مختلفتين. فهم الفرق بينهما ضروري لتحديد RTO وRPO الخاصين بك.

النسخ الاحتياطية التلقائية مفعَّلة بشكل افتراضي (مدة الاحتفاظ 1–35 يوماً). تأخذ RDS لقطة يومية لوحدة تخزين البيانات خلال نافذة النسخ الاحتياطي المُعدَّة، وتُؤرشف سجلات المعاملات بصفة مستمرة في S3. يتيح هذا التركيب الاسترداد إلى نقطة زمنية (PITR): يمكنك استعادة قاعدة بياناتك إلى أي ثانية ضمن مدة الاحتفاظ. الاستعادة تُنشئ مثيلاً جديداً — لا تُعيد الضبط في المكان.

اللقطات اليدوية تُنشأ صراحةً عبر وحدة التحكم أو CLI أو الأتمتة. تبقى حتى تحذفها، وتصمد حتى بعد حذف المثيل. استخدمها قبل هجرات المخطط، وترقيات الإصدار الكبرى، وأي عملية تدميرية. لا تُمكِّن PITR — فهي لقطة كاملة لوحدة التخزين في نقطة زمنية واحدة.

# إنشاء لقطة يدوية قبل هجرة خطيرة
aws rds create-db-snapshot \
  --db-instance-identifier prod-postgres \
  --db-snapshot-identifier prod-postgres-pre-migration-2025-07-01

# عرض جميع اللقطات لمثيل معين
aws rds describe-db-snapshots \
  --db-instance-identifier prod-postgres \
  --query 'DBSnapshots[*].{ID:DBSnapshotIdentifier,Status:Status,Time:SnapshotCreateTime}' \
  --output table

# الاستعادة إلى نقطة زمنية — ينشئ مثيلاً جديداً دائماً
aws rds restore-db-instance-to-point-in-time \
  --source-db-instance-identifier prod-postgres \
  --target-db-instance-identifier prod-postgres-restored \
  --restore-time 2025-07-01T03:00:00Z \
  --db-instance-class db.r7g.xlarge \
  --multi-az

# بعد الاستعادة: تحقق من البيانات، ثم حوّل نقطة النهاية عبر Route 53 CNAME

اضبط مدة احتفاظ النسخ الاحتياطية التلقائية على 7 أيام على الأقل في الإنتاج، واختبر PITR ربع سنوياً. كثير من الفرق تكتشف خلال حادثة حقيقية أن إجراء الاستعادة معطل أو يستغرق وقتاً أطول بكثير مما يسمح به RTO. تدريبات الاستعادة بالغة الأهمية بقدر النسخ الاحتياطية ذاتها.

مجموعات المعاملات: ضبط المحرك دون صلاحيات Shell

مجموعة المعاملات (Parameter Group) هي مجموعة من متغيرات إعداد المحرك (مكافئ ملف my.cnf أو postgresql.conf) تربطها بمثيل RDS أو مجموعة. نظراً لانعدام صلاحيات الوصول إلى نظام التشغيل في RDS، تُعدّ مجموعات المعاملات الطريقة الوحيدة لضبط محرك قاعدة البيانات.

تنقسم المعاملات إلى نوعين. المعاملات الثابتة (Static) تتطلب إعادة تشغيل المثيل لتُطبَّق مثل max_connections وshared_buffers. المعاملات الديناميكية (Dynamic) تُطبَّق فوراً دون إعادة تشغيل مثل log_min_duration_statement وwork_mem. تشحن RDS بمجموعة معاملات افتراضية لكل إصدار محرك؛ هذه المجموعة غير قابلة للتعديل — يجب إنشاء مجموعة مخصصة لتغيير أي شيء.

# إنشاء مجموعة معاملات مخصصة لـ PostgreSQL 16
aws rds create-db-parameter-group \
  --db-parameter-group-name prod-pg16-custom \
  --db-parameter-group-family postgres16 \
  --description "Production PostgreSQL 16 tuning"

# تطبيق معاملات ضبط ديناميكية (لا تتطلب إعادة تشغيل)
aws rds modify-db-parameter-group \
  --db-parameter-group-name prod-pg16-custom \
  --parameters \
    "ParameterName=log_min_duration_statement,ParameterValue=1000,ApplyMethod=immediate" \
    "ParameterName=work_mem,ParameterValue=65536,ApplyMethod=immediate" \
    "ParameterName=random_page_cost,ParameterValue=1.1,ApplyMethod=immediate"

# تطبيق معامل ثابت (يتطلب إعادة تشغيل)
aws rds modify-db-parameter-group \
  --db-parameter-group-name prod-pg16-custom \
  --parameters \
    "ParameterName=shared_buffers,ParameterValue={DBInstanceClassMemory/4},ApplyMethod=pending-reboot"

# ربط مجموعة المعاملات بالمثيل
aws rds modify-db-instance \
  --db-instance-identifier prod-postgres \
  --db-parameter-group-name prod-pg16-custom \
  --apply-immediately

# التحقق من المعاملات المعلّقة لإعادة التشغيل
aws rds describe-db-parameters \
  --db-parameter-group-name prod-pg16-custom \
  --source user \
  --query 'Parameters[*].{Name:ParameterName,Value:ParameterValue,Apply:ApplyType}'

أبرز المعاملات التي يستحق ضبطها في بيئات PostgreSQL الإنتاجية:

shared_buffers — صيغة RDS {DBInstanceClassMemory/4} تضبطه على 25% من الذاكرة، نقطة البداية المعيارية. ثابت؛ يتطلب إعادة تشغيل.
work_mem — الذاكرة لكل عملية فرز أو تجزئة. القيمة الافتراضية 4 ميجابايت منخفضة عادةً للاستعلامات التحليلية. ارفعها بحذر: تتضاعف بعدد الاستعلامات المتزامنة. ديناميكي.
log_min_duration_statement — تسجيل أي استعلام يتجاوز N ميلي ثانية. ابدأ بـ1000، وخفّضه إلى 200 بعد معالجة الاستعلامات البطيئة الواضحة. ديناميكي.
random_page_cost — اضبطه على 1.1 لتخزين SSD (gp3/io1). القيمة الافتراضية 4.0 مصممة للأقراص الدوّارة وتجعل مُخطِّط الاستعلام يُفضّل المسح التسلسلي بشكل مفرط على SSDs. ديناميكي.
max_connections — ثابت. على المثيلات الكبيرة، استخدم PgBouncer أو RDS Proxy أمام RDS بدلاً من رفع هذه القيمة؛ تكلفة الاتصالات في PostgreSQL مرتفعة.

تغييرات مجموعات المعاملات على المعاملات الثابتة تضع المثيل في حالة "إعادة تشغيل معلّقة". يستمر المثيل في العمل بالقيم القديمة حتى تُعيد تشغيله. جدوِل إعادة التشغيل خلال نافذة الصيانة، وتحقق من تطبيق التغيير بـSHOW shared_buffers; بعد إعادة التشغيل — لا تفترض أن التغيير طُبِّق.

التخزين: gp3 مقابل io1 مقابل io2

أداء تخزين RDS يؤثر مباشرةً على زمن استجابة قاعدة البيانات. اختر بناءً على متطلبات IOPS والإنتاجية، لا حجم المثيل وحده.

gp3 — SSD متعدد الأغراض. خط أساس 3,000 IOPS و125 ميجابايت/ث، قابل للترقية إلى 16,000 IOPS و1,000 ميجابايت/ث بصرف النظر عن حجم التخزين. الافتراضي الصحيح لمعظم أحمال الإنتاج.
io2 — SSD ذو IOPS مُوفَّر. حتى 256,000 IOPS مع ضمان توافر 99.999%. استخدمه لأحمال OLTP المطلوبة حيث يجب أن يكون زمن الاستجابة أقل من ميلي ثانية.
Aurora — التخزين مُدار بصورة منفصلة؛ لا تُوفِّر IOPS. يتوسع تلقائياً حتى 128 تيرابايت ويتولى I/O بنفسه، وهو من أقوى مزايا Aurora.

لتوفير التكاليف: انقل مثيلات RDS الحالية من gp2 إلى gp3. في gp2، يتناسب IOPS خطياً مع حجم التخزين (3 IOPS/جيجابايت)، مما يدفع الفرق لزيادة التخزين بشكل مفرط لتحقيق هدف IOPS. مع gp3 تُوفِّر IOPS باستقلالية — بتوفير 40–50% عادةً لنفس الأداء. نفّذ aws rds describe-db-instances --query 'DBInstances[*].{ID:DBInstanceIdentifier,Storage:StorageType}' لتدقيق أسطولك.

التوفير عبر CLI: مثال شامل من البداية للنهاية

ما يلي ينشئ مثيل PostgreSQL Multi-AZ جاهزاً للإنتاج مع مجموعة معاملات مخصصة ونسخ احتياطية تلقائية مُعدَّة مسبقاً.

# 1. إنشاء مجموعة شبكات فرعية مخصصة لقاعدة البيانات (تمتد عبر منطقتَي توافر على الأقل)
aws rds create-db-subnet-group \
  --db-subnet-group-name prod-db-subnets \
  --db-subnet-group-description "Private subnets for RDS" \
  --subnet-ids subnet-0abc1234 subnet-0def5678

# 2. إنشاء المثيل
aws rds create-db-instance \
  --db-instance-identifier prod-postgres \
  --db-instance-class db.r7g.xlarge \
  --engine postgres \
  --engine-version 16.2 \
  --master-username dbadmin \
  --master-user-password "$(aws secretsmanager get-secret-value \
      --secret-id prod/rds/master-password --query SecretString --output text)" \
  --allocated-storage 200 \
  --storage-type gp3 \
  --iops 6000 \
  --storage-encrypted \
  --kms-key-id alias/prod-rds \
  --multi-az \
  --db-subnet-group-name prod-db-subnets \
  --vpc-security-group-ids sg-0123456789abcdef0 \
  --db-parameter-group-name prod-pg16-custom \
  --backup-retention-period 14 \
  --preferred-backup-window "02:00-03:00" \
  --preferred-maintenance-window "sun:04:00-sun:05:00" \
  --enable-performance-insights \
  --performance-insights-retention-period 7 \
  --deletion-protection \
  --no-publicly-accessible \
  --tags Key=Environment,Value=prod Key=Team,Value=platform

# 3. إنشاء نسخة قراءة في منطقة ثانية للتعافي من الكوارث
aws rds create-db-instance-read-replica \
  --db-instance-identifier prod-postgres-replica-us-west-2 \
  --source-db-instance-identifier arn:aws:rds:us-east-1:123456789012:db:prod-postgres \
  --db-instance-class db.r7g.large \
  --region us-west-2 \
  --storage-encrypted \
  --kms-key-id alias/prod-rds-west

أبرز الخيارات المهمة: --storage-encrypted يُفعِّل التشفير بـ AES-256 في حالة الراحة (إلزامي للامتثال)؛ --deletion-protection يمنع الحذف العرضي للمثيل؛ --no-publicly-accessible يضمن عدم وجود IP عام ويجعل المثيل متاحاً فقط داخل VPC؛ --enable-performance-insights يوفر لوحة بيانات أداء استعلام مجانية لمدة 7 أيام.

لا تُضمِّن كلمات مرور قواعد البيانات في أوامر CLI أو ملفات إعداد التطبيق. خزِّن بيانات الاعتماد في AWS Secrets Manager وادِر تدويرها تلقائياً. استخدم ميزة تدوير كلمات مرور RDS الأصلية مع Secrets Manager — تتولى AWS Lambda الخاصة بالتدوير، وإنشاء كلمة المرور الجديدة، والتبديل الذري لبيانات الاعتماد دون توقف الخدمة.