مختبر 4SOدورة حياة بعد الإنشاء
Scale وBackup وRestore وUpgrade وRecovery إجراءات من الدرجة الأولى.
DATABASE LIFECYCLE CONTROL PLANE
DBaaS Enterpriseعمليات قواعد بيانات واعية بالمحرك، لا Provision فقط
Control Plane لدورة حياة عشرة محركات قواعد بيانات مع طوبولوجيا 1/2/3 عقد ودلالات HA أصلية للمحرك وBackup/Restore وUpgrade والتحقق من Runtime.
MySQLPostgreSQLRedis OSSValkeyMariaDBMongoDBClickHouseOpenSearchScyllaDBQdrant
مكوّنات DBaaS Enterprise: مستوى تحكم واحد وعشرة محركات قواعد بيانات
- 1Control Planeقبول الطلبات وRBAC والعمليات الدائمة لكل المحركات؛ لا يدخل Manager مسار بيانات الخدمة.
- 2حالة العملية الدائمةتُسجَّل كل عملية مقبولة في PostgreSQL قبل التنفيذ وتُسلَّم إلى العمّال عبر Transactional Outbox.
- 3العمّال والأتمتةيحجز العامل Execution Lease وSource Manifest Fence ثم يشغّل Ansible على عقد قاعدة البيانات.
- 4MySQLInnoDB ReplicaSet لعقدة أو عقدتين وInnoDB Cluster / Group Replication عند ثلاث؛ ويعمل MySQL Router على عقد القاعدة.
- 5PostgreSQLPatroni مع Streaming Replication وetcd؛ ويعمل PgBouncer وHAProxy بجوار عقد القاعدة.
- 6MariaDBGalera متعدد الكتابة (Multi-primary) مع HAProxy؛ ثلاثة أعضاء يوفّرون نصاب HA.
- 7Redis OSSReplication وSentinel وHAProxy؛ تجاوز الفشل التلقائي بعقدتين معطّل عمدًا.
- 8Valkeyنفس نموذج Replication + Sentinel + HAProxy خلف FQDN ثابت للعميل.
- 9MongoDBقاعدة بيانات مستندية؛ الطوبولوجيا وHA وفق دلالاته الأصلية تحت Control Plane نفسه.
- 10ClickHouseقاعدة بيانات عمودية للتحليل؛ الطوبولوجيا وHA وفق دلالاته الأصلية تحت Control Plane نفسه.
- 11OpenSearchالبحث وتحليل السجلات؛ الطوبولوجيا وHA وفق دلالاته الأصلية تحت Control Plane نفسه.
- 12ScyllaDBقاعدة بيانات Wide-column؛ الطوبولوجيا وHA وفق دلالاته الأصلية تحت Control Plane نفسه.
- 13Qdrantقاعدة بيانات متجهية؛ الطوبولوجيا وHA وفق دلالاته الأصلية تحت Control Plane نفسه.
01PROBLEM & OUTCOME
مشكلة المنتج
Provisioning هو الجزء السهل؛ تشغيل قاعدة البيانات هو المنتج.
Replication وQuorum وBackup وRestore وUpgrade وFailover تختلف بين المحركات. يحافظ DBaaS على هذه الاختلافات ويعرض سطح تشغيل موحداً ودائماً.
لا abstraction مزيفة
تبقى InnoDB وPatroni وSentinel وGalera بدلالاتها الأصلية.
استعادة مصممة مسبقاً
Promotion وFencing وRejoin لها قواعد قبل الحادثة.
نجاح مُلاحظ
Membership وEndpoint وClient I/O يجب أن تؤكد النتيجة.
02CAPABILITY SNAPSHOT
القدرات
سطح تشغيلي واحد مع آليات خاصة بكل Engine.
يرى المشغل دورة حياة متسقة بينما يحتفظ كل محرك بنموذج التنسيق الحقيقي الذي يحتاجه.
إنشاء الخدمة
Engine وVersion وTopology وNodes مع Preflight.
1 → 2 → 3
إضافة أعضاء من دون اعتبار عقدتين HA تلقائياً.
حماية واستعادة
نسخ أصلي للمحرك مع Integrity evidence وتحقق بعد Restore.
تغيير مضبوط
Version edge مدعوم وBackup Gate وRuntime read-back.
Promotion / Routing
Promotion واعٍ بالمحرك أو Galera routing reconciliation.
هوية عميل مستقرة
Tenant FQDN يبقى ثابتاً عبر تغييرات الطوبولوجيا.
إشارات حقيقية
Host/DB telemetry وservice-level probes.
TLS وRBAC وAudit
الوصول وكل عملية مضبوطة وقابلة للتتبع في Control Plane.
03TOPOLOGY / DEPLOYMENT MODEL
نموذج النشر
الطوبولوجيا تتبع المحرك، لا خيار HA عام.
ملفات المحركات العلائقية وKey-value (MySQL وPostgreSQL وRedis وValkey وMariaDB) تبدأ بعقدة واحدة، تمر بعقدتين من دون Failover تلقائي، وتصل إلى HA تلقائي عند ثلاث عقد وفق نموذج التنسيق الأصلي.
| الملف | المحركات | سلوك الفشل | الآلية الأصلية |
|---|---|---|---|
| 1 node | MySQL · PostgreSQL · Redis · Valkey · MariaDB | Non-HA | Single member + stable endpoint |
| 2 nodes | MySQL · PostgreSQL · Redis · Valkey · MariaDB | Automatic failover disabled | Primary/Mirror أو Galera بعقدتين بلا أغلبية |
| 3 nodes | MySQL · PostgreSQL · Redis · Valkey · MariaDB | Automatic HA | InnoDB Cluster · Patroni/etcd · Sentinel · Galera quorum |
04ARCHITECTURE
المعمارية
Control Plane يبقى خارج مسار بيانات Tenant.
القصد وحالة Job الدائمة في Manager؛ أما Runtime وMembership وRouting المحلي فتبقى على عقد قاعدة البيانات.
ENTRYPanel / Product APITenant وProject وEngine وTopology وPermission وConfirmation.
DURABLE STATEPostgreSQL operationsOperation وLock وCorrelation وAudit تُحفظ قبل Mutation.
EXECUTIONOutbox → RabbitMQ/Celery → Ansibleتنفيذ متسلسل خاص بالمحرك على عقد Tenant.
RUNTIMEDatabase nodes + local router/proxyالنظام الخادم يملك حقيقة Replication وRouting.
| الحد | الآلية | العقد التشغيلي |
|---|---|---|
| Manager | Control plane only | ليس DB member أو witness أو quorum voter أو failover target. |
| Stable endpoint | Tenant FQDN | هوية العميل لا تتغير مع topology. |
| Routing | Local Router/HAProxy على DB nodes | الوصول لأي عقدة خدمة يمكن أن يقود للدور الصحيح. |
| Coordination | Engine-native quorum/election | لا witness خارجي لاختراع HA. |
| المرحلة | Authority / Component | العقد التقني |
|---|---|---|
| Admission | Panel / Product API | يتم فحص Engine وTopology وPermission وConfirmation؛ قبول الطلب لا يعني اكتماله. |
| Durable state | PostgreSQL | تُحفظ Operation وJob قبل أي Mutation؛ ولا يُسمح إلا بعملية Mutation نشطة واحدة لكل Tenant، وتُرفض العملية الثانية بدل وضعها في الطابور. |
| Dispatch | Transactional Outbox → RabbitMQ → Celery Worker | نشر العمل مرتبط بالحالة التراكنشية ويستلم Worker تنفيذاً serialized. |
| Execution fence | Execution lease + signed source manifest | يجب أن تطابق شجرة Runtime هوية Release المتوقعة؛ أي Drift يوقف تنفيذ Playbook. |
| Engine execution | Project-local Ansible | يعمل Playbook الأصلي للمحرك فقط على DB nodes الخاصة بالـ Tenant؛ Manager لا يدخل Data Plane. |
| Verification | Engine runtime + stable endpoint | تُقرأ Membership/Quorum وReplication وDNS/TLS وClient read/write من Runtime الحقيقي. |
| Evidence | Job-scoped evidence | النتيجة وCorrelation تبقيان مع نفس Operation؛ HTTP acceptance لا تتحول وحدها إلى Completion. |
05LIFECYCLE
دورة الحياة
دورة الحياة حلقة دائمة واحدة.
كل mutation تُقبل وتُحفظ وتُنفذ وتُقرأ من Runtime ثم تُتحقق أو تنتقل إلى حالة استعادة صريحة.
01Createengine · version · topology
02Scaleprepare · join · sync
03Backupartifact · integrity
04Restorepreflight · restore · verify
05Upgradeedge · stage · read-back
06Failoverfence · promote / reconcile
07Rejoinmembership convergence
08Removesafe member removal
06ENGINE PROFILES
ملفات المحركات
عشرة محركات، لكل منها دلالاته الأصلية، تحت Control Plane واحد.
الـ Control Plane مشترك، لكن Replication وElection/Quorum وLocal Routing وBackup وFailover/Recovery تتبع المعمارية الأصلية لكل Engine.
| Engine | Native topology / routing | 1 node | 2 nodes | 3 nodes | Data protection |
|---|---|---|---|---|---|
| MySQL | InnoDB ReplicaSet (1–2) · InnoDB Cluster / Group Replication (3) · MySQL Router على DB nodes | Non-HA | Manual promotion | Automatic HA | XtraBackup |
| PostgreSQL | Patroni + Streaming Replication · etcd + PgBouncer + HAProxy على DB nodes | Non-HA | Manual promotion | Patroni automatic HA | pg_basebackup |
| Redis OSS | Replication + Sentinel + HAProxy؛ تبقى Sentinel والـ Proxy على DB nodes | Non-HA | Manual promotion | Sentinel automatic HA | RDB / AOF |
| Valkey | Replication + Sentinel + HAProxy؛ محرك مستقل وليس alias لـ Redis | Non-HA | Manual promotion | Sentinel automatic HA | RDB / AOF |
| MariaDB | Galera (wsrep) + HAProxy؛ Multi-primary cluster مع Write Target تحت Routing المنتج | Single-member Galera | No automatic failover | Galera quorum HA | MariaBackup / Logical Dump |
| MongoDB | مستندية (Document) | الطوبولوجيا وHA وحماية البيانات وفق الدلالات الأصلية للمحرك نفسه، تحت Control Plane ودورة الحياة نفسيهما. | |||
| ClickHouse | عمودية تحليلية (Columnar / OLAP) | الطوبولوجيا وHA وحماية البيانات وفق الدلالات الأصلية للمحرك نفسه، تحت Control Plane ودورة الحياة نفسيهما. | |||
| OpenSearch | البحث وتحليل السجلات (Search) | الطوبولوجيا وHA وحماية البيانات وفق الدلالات الأصلية للمحرك نفسه، تحت Control Plane ودورة الحياة نفسيهما. | |||
| ScyllaDB | Wide-column | الطوبولوجيا وHA وحماية البيانات وفق الدلالات الأصلية للمحرك نفسه، تحت Control Plane ودورة الحياة نفسيهما. | |||
| Qdrant | متجهية (Vector) | الطوبولوجيا وHA وحماية البيانات وفق الدلالات الأصلية للمحرك نفسه، تحت Control Plane ودورة الحياة نفسيهما. | |||
07ACTION & WORKFLOW CONTRACT
الحالة والتدفقات
Accepted لا تساوي Succeeded.
Mutation واحدة نشطة لكل Tenant تمنع تغييرات طوبولوجيا متداخلة؛ Runtime evidence يغلق Job.
01AdmissionENGINE · TOPOLOGY · RBAC
02PersistDURABLE OPERATION
03QueueQUEUED
04ExecuteRUNNING
05Read-backVERIFYING
06TerminalSUCCEEDED / FAILED
FAILOVER PATH
Failover مع Fencing وQuorum
لا ينتقل Stable Endpoint إلا بعد إثبات دور Serving الجديد.
STABLE ENDPOINT
↓
PRIMARY
⇄
REPLICA
↓
QUORUM
+ FENCE
+ FENCE
Failure → membership read-back → fence → promotion → route update → client verify
RECOVERY FORK
Restore: Promote أو Abort
يجب التحقق من Recovery Point قبل دخولها إلى Serving Path.
BACKUP + CHECKSUM
↓
RESTORE
VALID?
VALID?
↓
PROMOTE
RESTORED
RESTORED
↙ ↘
ABORT
ISOLATE
ISOLATE
Compatibility · ownership · disk · engine health · client read/write
RECONCILIATION LOOP
حلقة Rejoin / Replace
Observed Membership تحدد هل يمكن Rejoin أم يجب Replace.
DESIRED
MEMBERS
MEMBERS
→
RECONCILE
↓
READ
BACK
BACK
↑
OBSERVED
MEMBERS
MEMBERS
←
DRIFT /
FAILED NODE
FAILED NODE
Rejoin eligibility → re-seed if needed → membership sync → endpoint verify
Provision Service
من Intent إلى Service-level read-back.
01Engine / Version02Topology / Nodes03Preflight04Persist Job05Engine Automation06Runtime Verify
Failure / Recoveryغياب دليل Membership أو Endpoint أو Client I/O يمنع Success.
Scale 1→2→3
النمو من دون اختراع HA بعقدتين.
01Capacity Gate02Prepare Node03Join / Replicate04Sync05Quorum Check06Endpoint Verify
Failure / RecoveryPartial membership يُصالح قبل أي Mutation أخرى.
Backup → Restore
الحماية تكتمل فقط باستعادة قابلة للتحقق.
01Backup Admit02Native Backup03Integrity04Restore Preflight05Restore06Client I/O
Failure / RecoveryBackup ناقص أو فاسد لا يُقبل كنقطة استعادة.
Upgrade
تغيير الإصدار staged ويُقرأ من Runtime.
01Upgrade Edge02Backup Gate03Health Gate04Stage05Version Read-back06Post-check
Failure / RecoveryUnsupported edge أو degraded health يوقف الاستمرار.
Failover / Recovery
Fencing وQuorum قبل Promotion.
01Detect02Read Membership03Fence / Quorum04Promote / Reconcile05Route Update06Client Verify
Failure / RecoveryMinority partition لا تُجبر على Promotion.
ADDITIONAL OPERATIONAL FLOWS
تدفقات تشغيلية إضافية
مساران من عمليات Day‑2 لا يقلان أهمية عن Provision الأولي.
Rejoin Member
إعادة العضو المتعافي من دون إفساد Membership الحالية.
01Detect Drift02Fence / Classify03Rejoin Eligibility04Re-seed if Needed05Join Membership06Catch-up07Endpoint Verify
Failure / Recoveryإذا كانت Identity أو Replication Position غير آمنة، تنتقل العقدة إلى Replace بدلاً من Force-Join.
Remove / Replace Node
إزالة أو استبدال Hardware مع حماية Quorum والأعضاء السليمة.
01Change Intent02Quorum Gate03Drain / Fence04Remove Member05Prepare Replacement06Join / Sync07Runtime Verify
Failure / Recoveryلا يتم Sanitization للأعضاء المحتفظ بها، ولا تُحرر هوية العقدة القديمة قبل Removal مؤكد.
| الإجراء | شروط القبول | مالك التنفيذ | معيار النجاح | الفشل / الاستعادة |
|---|---|---|---|---|
| Create Service | Tenant/Project صالحان + Engine/Version + Nodes | DBaaS worker + engine playbook | Membership + endpoint + client I/O | Failed job يحتفظ بالدليل؛ reconcile قبل retry |
| Scale | Cluster صحي + عقدة جديدة محددة | Serialized tenant mutation | Exact member count + replication/quorum | Partial join يُصالح |
| Backup | Engine compatible + destination | Engine-native backup | Artifact + integrity metadata | Incomplete backup invalid |
| Restore | Verified backup + compatibility + maintenance gate | Cluster-locked restore | Service + replication + endpoint + I/O | Unknown outcome يحتاج read-back |
| Upgrade | Supported edge + backup + health | Staged engine-aware upgrade | Exact version + health + client I/O | يُرفض edge غير المدعوم/downgrade؛ التوقف والاستعادة عند المرحلة الفاشلة |
| Failover | Eligible topology + fencing/quorum | Promotion أو Galera routing reconcile | Serving role جديد + stable endpoint | Rejoin/reconcile منفصلان |
08OPERATIONS CATALOG
سطح المشغل
عمليات DB تصبح Actions صريحة.
المشغل يعمل مع نية دورة الحياة بدلاً من تسلسلات Shell محفوظة.
إنشاء خدمة DB
Deployment واعٍ بالمحرك مع Preflight وVerification.
إضافة عضو
Prepare ثم Join وSync وVerify.
إنشاء Recovery Artifact
Backup مجدول مع Retention وVerify؛ وNative backup مع Integrity evidence.
استعادة الخدمة
Compatibility وService-level verification.
تغيير إصدار
Supported edge وRuntime read-back.
نقل Serving role
Switchover مخطط وFailover مع Promotion واعٍ بالـ quorum/fencing.
إصلاح Membership
إعادة العقدة إلى عضوية صحيحة.
فحص الخدمة
Topology وReplication وEndpoint وTelemetry.
المستخدمون وقواعد البيانات
إنشاء ومنح صلاحيات وتدوير كلمات المرور وحذف عبر مسار Job نفسه.
دورة حياة الشهادات
حالة الشهادات وتجديدها وإعادة إصدارها وتدوير CA المنتج.
تطبيق ملف Tuning
ملفات إعداد مناسبة لموارد العقدة تُطبَّق بإعادة تشغيل مرتّبة وآمنة.
MCP
Remote MCP بلا سلطة موازية. OAuth 2.1 مع Authorization Code + PKCE: الـ Panel هو Authorization Server وMCP Addon هو Resource Server؛ ويرتبط الـ grant بـ mcp_clients وRBAC وscope وrate-limit القائمة دون نظام وصول ثانٍ.
دورة حياة قاعدة البيانات كمنتج، لا Runbook.
يبقى Control Plane متسقاً ويحتفظ كل Engine بطوبولوجيته ودلالات فشله الحقيقية.