Control Plane ی DBaaS Enterprise و موتورهای پایگاه داده روی سکوهای جدا.

DATABASE LIFECYCLE CONTROL PLANE

DBaaS EnterpriseDatabase Operations, not just Provisioning

DBaaS Enterprise ده موتور دیتابیس را زیر یک Control Plane مشترک اما Engine-aware اداره می‌کند. Provision، Scale، Backup/Restore، Upgrade، Failover/Recovery، Stable Endpoint و Runtime Verification در یک چرخه‌ی عملیاتی یکپارچه قرار می‌گیرند.

MySQLPostgreSQLRedis OSSValkeyMariaDBMongoDBClickHouseOpenSearchScyllaDBQdrant

دانلود بروشور فنی۱۲ صفحه · Engine Topology · Durable Workflow · HA/DR · Action Catalog

اجزای DBaaS Enterprise: یک Control Plane و ده موتور دیتابیس

۱Control Planeپذیرش درخواست، RBAC و عملیات ماندگار برای همه‌ی موتورها؛ Manager عضو مسیر داده‌ی سرویس نیست.
۲وضعیت ماندگار عملیاتهر عملیات پذیرفته‌شده پیش از اجرا در PostgreSQL ثبت می‌شود و از طریق Transactional Outbox به Worker می‌رسد.
۳Worker و اتوماسیونWorker با Execution Lease و Source Manifest Fence اجرا را قفل می‌کند و Ansible را روی نودهای دیتابیس اجرا می‌کند.
۴MySQLInnoDB ReplicaSet برای ۱ و ۲ نود و InnoDB Cluster / Group Replication در ۳ نود؛ MySQL Router روی نودهای دیتابیس.
۵PostgreSQLPatroni با Streaming Replication و etcd؛ PgBouncer و HAProxy در کنار نودهای دیتابیس.
۶MariaDBGalera چندنویسنده (Multi-primary) با HAProxy؛ سه عضو حدنصاب HA را فراهم می‌کنند.
۷Redis OSSReplication، Sentinel و HAProxy؛ Failover خودکار دو نودی عمداً غیرفعال است.
۸Valkeyهمان مدل Replication + Sentinel + HAProxy با شناسه‌ی پایدار FQDN برای کلاینت.
۹MongoDBپایگاه داده‌ی سندمحور؛ توپولوژی و HA با semantics بومی همین موتور، زیر همان Control Plane.
۱۰ClickHouseپایگاه داده‌ی ستونی برای تحلیل؛ توپولوژی و HA با semantics بومی همین موتور، زیر همان Control Plane.
۱۱OpenSearchجست‌وجو و تحلیل لاگ؛ توپولوژی و HA با semantics بومی همین موتور، زیر همان Control Plane.
۱۲ScyllaDBپایگاه داده‌ی Wide-column؛ توپولوژی و HA با semantics بومی همین موتور، زیر همان Control Plane.
۱۳Qdrantپایگاه داده‌ی برداری؛ توپولوژی و HA با semantics بومی همین موتور، زیر همان Control Plane.

۰۱PROBLEM & OUTCOME

مسئله‌ی محصول

راه‌اندازی کردن دیتابیس ساده است؛ اداره‌کردن آن سخت است.

Replication، Quorum، Backup، Restore، Upgrade و Failover در هر موتور رفتار متفاوتی دارند. DBaaS این تفاوت‌ها را به فرایندهای روشن تبدیل می‌کند تا اپراتور به‌جای حفظ دستورالعمل‌های عملیاتی پراکنده، یک مسیر عملیاتی واحد داشته باشد.

۰۱DAY-2 OPERATIONS

روز دوم مهم‌تر از روز اول

ساخت سرویس فقط نقطه‌ی شروع است؛ تغییر ظرفیت، نگه‌داری و بازیابی باید همان‌قدر ساده و کنترل‌شده باشند.

۰۲ENGINE SEMANTICS

هر موتور منطق خودش را دارد

موتورها با یک abstraction مصنوعی یکسان نمی‌شوند؛ تفاوت واقعی Replication، Quorum و Failover حفظ می‌شود.

۰۳FAILURE

خرابی یک حالت طراحی‌شده است

Promotion، Fencing، Quorum و بازیابی از قبل در مدل محصول جای دارند و در زمان حادثه اختراع نمی‌شوند.

۰۴TRUTH

موفقیت از خود محیط اجرا خوانده می‌شود

پذیرفته‌شدن درخواست کافی نیست؛ عضویت، Replication، Endpoint و خواندن/نوشتن باید نتیجه را تأیید کنند.

۰۲CAPABILITY SNAPSHOT

نمای قابلیت‌ها

از ساخت سرویس تا بازیابی، یک سطح عملیاتی واحد.

قابلیت‌ها حول چرخه‌ی عمر واقعی سرویس سازمان‌دهی شده‌اند، نه حول منوهای فنی هر موتور.

۰۱PROVISION

ساخت سرویس دیتابیس

انتخاب موتور، نسخه، توپولوژی و نودها همراه با Preflight قبل از تغییر.

۰۲SCALE

مقیاس‌دهی متناسب با توپولوژی

افزودن عضو با آماده‌سازی، عضویت، همگام‌سازی و بررسی سلامت پس از هر مرحله.

۰۳BACKUP / RESTORE

پشتیبان‌گیری و بازیابی

بررسی سازگاری، Integrity و بازگردانی تا تأیید کامل سرویس.

۰۴UPGRADE

ارتقای کنترل‌شده

مسیر نسخه‌ی مجاز، Backup، Health Gate و بازخوانی وضعیت نسخه‌ی محیط اجرا.

۰۵FAILOVER

Failover و Promotion

رفتار متناسب با موتور و توپولوژی با حفاظت از Quorum.

۰۶ENDPOINT

Endpoint پایدار

نام سرویس ثابت می‌ماند و Routing محلی نودها تغییر Primary را پوشش می‌دهد.

۰۷OBSERVABILITY

مانیتورینگ واقعی

Host و DB Metrics از منبع واقعی خوانده می‌شوند و نبود داده جعل نمی‌شود.

۰۸SECURITY

TLS، RBAC و Audit

دسترسی و عملیات در Control Plane کنترل و قابل‌ردیابی می‌مانند.

۰۳TOPOLOGY / DEPLOYMENT MODEL

مدل استقرار

Topology متناسب با معماری هر موتور.

پروفایل‌های رابطه‌ای و Key-value (MySQL، PostgreSQL، Redis، Valkey و MariaDB) از ۱ نود شروع می‌شوند و همان سرویس می‌تواند به ۲ و ۳ نود رشد کند. توپولوژی ۲ نود عمداً HA تلقی نمی‌شود: در MySQL، PostgreSQL، Redis و Valkey مسیر Primary/Mirror با Promotion صریح است و در MariaDB دو عضو Galera اکثریت لازم برای Failover خودکار ندارند. HA خودکار در توپولوژی سه‌نودی و با quorum/election بومی همان موتور فعال می‌شود.

اندازه	موتورها	رفتار خرابی	مدل عملیاتی
۱ نود	MySQL · PostgreSQL · Redis · Valkey · MariaDB	Non-HA / single-member service	Runtime بومی موتور با Stable Endpoint و Local Router/Proxy؛ بدون ادعای افزونگی.
۲ نود	MySQL · PostgreSQL · Redis · Valkey · MariaDB	Automatic failover disabled	MySQL/PostgreSQL/Redis/Valkey: Primary + Mirror با Promotion صریح؛ MariaDB: Galera دو عضوی بدون quorum اکثریت.
۳ نود	MySQL · PostgreSQL · Redis · Valkey · MariaDB	Automatic HA	InnoDB Cluster، Patroni/etcd، Sentinel یا Galera quorum بر اساس semantics بومی همان موتور.

۰۴ARCHITECTURE

معماری

Control Plane از Data Plane جدا می‌ماند.

درخواست ابتدا Admit و Persist می‌شود، سپس Worker عملیات مخصوص هر موتور را اجرا می‌کند و در پایان نتیجه از محیط اجرا خوانده و به شواهد تبدیل می‌شود.

ENTRYPanel / APITenant، Project، موتور، توپولوژی و Permission.

↓

DURABLE STATEمرجع عملیات و JobOperation پیش از هر تغییر Persist می‌شود و وضعیت، Lock و Correlation دارد.

↓

EXECUTIONموتور AutomationAction مخصوص موتور روی نودهای همان سرویس اجرا می‌شود.

↓

DATA PLANEنودهای دیتابیس + Local Proxy/Routerخود دیتابیس، Replication، Routing محلیِ موتور و Endpoint behavior.

مرز	قرارداد فنی	اثر عملیاتی
Manager	Control Plane only	عضو DB، quorum، witness، Router/Proxy مستقل یا Failover target نیست.
Stable endpoint	Tenant FQDN	Client با یک نام پایدار به سرویس می‌رسد؛ تغییر topology نام سرویس را عوض نمی‌کند.
Routing	Router/Proxy روی همان DB nodes	Stale DNS همچنان به یک DB node می‌رسد و Routing محلی مسیر درست را حفظ می‌کند.
Coordination	Engine-native quorum/election	etcd، Sentinel، Group Replication و Galera روی خود DB nodeها اجرا می‌شوند؛ witness خارجی وجود ندارد.

TECH

Execution Pipeline. در DBaaS پذیرش درخواست با موفقیت عملیات یکی نیست؛ مسیر mutation تا زمانی که Runtime read-back و Evidence کامل نشوند به پایان نمی‌رسد.

مرحله	Authority / Component	قرارداد فنی
Admission	Panel / Product API	Engine، topology، permission و confirmation بررسی می‌شوند؛ درخواست صرفاً Admit می‌شود.
Durable state	PostgreSQL	Operation و Job پیش از mutation پایدار می‌شوند؛ هر tenant فقط یک mutation فعال دارد و درخواست دوم به‌جای قرارگرفتن در صف رد می‌شود.
Dispatch	Transactional Outbox → RabbitMQ → Celery Worker	انتشار کار از state تراکنشی جدا نمی‌شود و Worker اجرای serialized را می‌گیرد.
Execution fence	Execution lease + signed source manifest	Runtime tree باید با release identity مورد انتظار هم‌خوان باشد؛ drift اجرای playbook را متوقف می‌کند.
Engine execution	Project-local Ansible	Playbook بومی همان Engine فقط روی DB nodeهای tenant اجرا می‌شود؛ Manager وارد Data Plane نمی‌شود.
Verification	Engine runtime + stable endpoint	Membership/quorum، replication، DNS/TLS و client read/write از محیط واقعی دوباره خوانده می‌شوند.
Evidence	Job-scoped evidence	نتیجه و correlation با همان Operation نگه‌داری می‌شود؛ HTTP acceptance به completion تبدیل نمی‌شود.

۰۵LIFECYCLE

چرخه‌ی عمر

چرخه‌ی عمر دیتابیس باید تکرارپذیر باشد.

هر مرحله ورودی، محدودیت، Health Gate و بازخوانی وضعیت خودش را دارد؛ از اولین Preflight تا بازیابی.

۰۱ساختپیش‌بررسی، موتور، نسخه، توپولوژی

۰۲مقیاس‌دهیآماده‌سازی، عضویت، همگام‌سازی

۰۳پشتیبان‌گیریArtifact و Integrity

۰۴بازیابی Restoreپیش‌بررسی، بازگردانی، تأیید

۰۵ارتقاEdge، مرحله‌بندی، read-back

۰۶FailoverFence، Promote یا Reconcile

۰۷Rejoinهمگرایی عضویت

۰۸خروج عضوحذف امن عضو

۰۶ENGINE PROFILES

پروفایل موتور

ده موتور، هر کدام با semantics بومی خودش، زیر یک Control Plane.

Control Plane مشترک است، اما Replication، Election/Quorum، Local Routing، Backup و Failover/Recovery هر موتور با معماری Native خودش مدل می‌شود.

مسیر DBaaS Enterprise برای ده موتور دیتابیس: نیازسنجی، انتخاب موتور، ساخت توپولوژی، عملیات و پایش، پشتیبان‌گیری و بازیابی، مقیاس و Failover.

Engine	Native topology / routing	۱ نود	۲ نود	۳ نود	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 و Data Protection با semantics بومی همان موتور، زیر همان Control Plane و چرخه‌ی عمر.
ClickHouse	ستونی و تحلیلی (Columnar / OLAP)	توپولوژی، HA و Data Protection با semantics بومی همان موتور، زیر همان Control Plane و چرخه‌ی عمر.
OpenSearch	جست‌وجو و تحلیل لاگ (Search)	توپولوژی، HA و Data Protection با semantics بومی همان موتور، زیر همان Control Plane و چرخه‌ی عمر.
ScyllaDB	Wide-column	توپولوژی، HA و Data Protection با semantics بومی همان موتور، زیر همان Control Plane و چرخه‌ی عمر.
Qdrant	برداری (Vector)	توپولوژی، HA و Data Protection با semantics بومی همان موتور، زیر همان Control Plane و چرخه‌ی عمر.

۰۷ACTION & WORKFLOW CONTRACT

فلو و State Machine

پذیرش درخواست، موفقیت عملیات نیست.

هر mutation به Job پایدار تبدیل می‌شود؛ عملیات یک tenant با هم overlap نمی‌کنند و موفقیت فقط پس از read-back از Engine، endpoint و client path ثبت می‌شود.

۰۱AdmissionENGINE · TOPOLOGY · RBAC

۰۲PersistDURABLE OPERATION

۰۳QueuedQUEUED

۰۴ExecuteRUNNING

۰۵Read-backVERIFYING

۰۶TerminalSUCCEEDED / FAILED

FAILOVER PATH

Failover با Fencing و Quorum

Stable Endpoint فقط پس از اثبات نقش جدید جابه‌جا می‌شود.

STABLE ENDPOINT

↓

PRIMARY

⇄

REPLICA

↓

QUORUM
+ FENCE

Failure → membership read-back → fence → promotion → route update → client verify

RECOVERY FORK

Restore: Promote یا Abort

Recovery point پیش از ورود به serving path باید verify شود.

BACKUP + CHECKSUM

↓

RESTORE
VALID?

↓

PROMOTE
RESTORED

↙ ↘

ABORT
ISOLATE

Compatibility · ownership · disk · engine health · client read/write

RECONCILIATION LOOP

Rejoin / Replace Loop

Observed membership تعیین می‌کند عضو باید Rejoin شود یا Replace.

DESIRED
MEMBERS

→

RECONCILE

↓

READ
BACK

↑

OBSERVED
MEMBERS

←

DRIFT /
FAILED NODE

Rejoin eligibility → re-seed if needed → membership sync → endpoint verify

FLOW 01

Provision Service

ساخت سرویس از intent تا read-back واقعی.

01Engine / Version02Topology / Nodes03Preflight04Persist Job05Engine Automation06Runtime Verify

Failure / Recoveryاگر membership، endpoint یا client I/O تأیید نشود، Job موفق نمی‌شود.

FLOW 02

Scale 1→2→3

رشد topology بدون تبدیل دو نود به HA ساختگی.

01Capacity Gate02Prepare Node03Join / Replicate04Sync05Quorum Check06Endpoint Verify

Failure / Recoveryعضو نیمه‌کاره reconcile می‌شود؛ retained nodes بی‌دلیل sanitize نمی‌شوند.

FLOW 03

Backup → Restore

Data protection فقط با restore verification کامل می‌شود.

01Backup Admit02Engine-native Backup03Integrity04Restore Preflight05Restore06Client Read/Write

Failure / RecoveryBackup ناقص یا checksum نامعتبر هرگز recovery point معتبر نیست.

FLOW 04

Upgrade

ارتقا به‌صورت مرحله‌ای و engine-aware.

01Upgrade Edge02Backup Gate03Health Gate04Stage Upgrade05Version Read-back06Post-check

Failure / RecoveryUnsupported edge یا health failure قبل از ادامه‌ی rollout متوقف می‌شود.

FLOW 05

Failover / Recovery

Quorum و fencing قبل از promotion قرار دارند.

01Detect Failure02Read Membership03Fence / Quorum04Promote / Reconcile05Route Update06Client Verify

Failure / RecoveryMinority partition force-promote نمی‌شود؛ rejoin مسیر recovery جدا دارد.

ADDITIONAL OPERATIONAL FLOWS

فلوهای عملیاتی تکمیلی

دو مسیر Day‑2 که در عملیات واقعی به‌اندازه‌ی Provision مهم‌اند.

FLOW 06

Rejoin Member

بازگرداندن عضو پس از خرابی بدون شکستن Membership موجود.

01Detect Drift02Fence / Classify03Rejoin Eligibility04Re-seed if Needed05Join Membership06Catch-up07Endpoint Verify

Failure / Recoveryاگر Identity یا Replication Position برای Rejoin امن نباشد، Node به‌جای Force-Join به مسیر Replace می‌رود.

FLOW 07

Remove / Replace Node

خروج عضو یا جایگزینی سخت‌افزار با حفظ Quorum و اعضای سالم.

01Change Intent02Quorum Gate03Drain / Fence04Remove Member05Prepare Replacement06Join / Sync07Runtime Verify

Failure / RecoveryRetained members پاک‌سازی نمی‌شوند و Identity نود قدیمی فقط پس از Removal قطعی آزاد می‌شود.

Action / Flow	Admission / Preconditions	Execution / Lock	Success Criterion	Failure / Recovery
Create Database Service	Tenant/Project، Engine/Version، topology و node inventory معتبر	Job serialization؛ Ansible فقط روی DB nodeهای همان tenant	Membership/quorum، Stable Endpoint، DNS/TLS و client read/write تأیید شوند	Failure با Job/Evidence حفظ می‌شود؛ قبل از retry وضعیت runtime دوباره خوانده می‌شود
Scale 1→2→3	Cluster سالم، member count فعلی و عضو جدید دقیقاً شناخته‌شده	عضو جدید قبل از membership mutation آماده می‌شود؛ retained nodeها sanitize نمی‌شوند	تعداد دقیق اعضا، replication/quorum و هم‌خوانی endpoint تأیید شوند	در failure عضویت نیمه‌کاره reconcile می‌شود؛ عملیات متداخل پذیرفته نمی‌شود
Backup	Engine/version و مقصد/فضا قابل‌استفاده؛ Job متداخل وجود ندارد	Backup بومی موتور با metadata و integrity evidence	Artifact/metadata و integrity قابل‌خواندن و قابل‌ردیابی باشند	Backup ناقص success تلقی نمی‌شود و مبنای Restore قرار نمی‌گیرد
Restore	Backup checksum، ownership/mode، free disk، compatibility و maintenance state بررسی شده	Restore تحت cluster lock و مسیر مخصوص Engine	Service + membership/replication + endpoint + DNS/TLS + client read/write	Outcome نامعلوم نیازمند reconcile است؛ completion از صرف خروج ابزار استنتاج نمی‌شود
Upgrade	Upgrade edge صریح، backup تأییدشده و health gate اولیه	مرحله‌ای با lock؛ نسخه در هر مرحله read-back می‌شود	Exact runtime version و health و client read/write بعد از upgrade	Unsupported/downgrade edge رد می‌شود؛ failure در همان مرحله متوقف و بازیابی می‌شود
Failover / Recovery	Topology باید اجازه دهد؛ fencing/quorum قبل از mutation بررسی می‌شود	Promotion برای Primary-based engines یا routing/quorum reconciliation برای Galera	Primary/route/quorum جدید + Stable Endpoint + client I/O از runtime تأیید شود	Minority partition force-promote نمی‌شود؛ rejoin/reconcile مسیر مستقل recovery است

۰۸OPERATIONS CATALOG

کاتالوگ عملیات

عملیات مهم، همان‌جایی که اپراتور انتظار دارد.

کاتالوگ عملیات حول هدف کاربر سازمان‌دهی می‌شود، نه دستورهای داخلی موتور.

Create Database Serviceساخت سرویس با موتور، Version و توپولوژی مشخص.

Scaleافزودن عضو و همگام‌سازی بدون دست‌کاری نودهای Retained.

BackupBackup زمان‌بندی‌شده با Retention و Verify؛ همراه با Metadata و Integrity قابل‌بررسی.

Restoreبازگردانی همراه با Endpoint و Client Read/Write verification.

Upgradeحرکت روی مسیرهای Version مجاز با کنترل‌های مرحله‌ای.

FailoverSwitchover برنامه‌ریزی‌شده و Failover؛ Promotion/Fencing برای موتورهای Primary-based و quorum و Routing reconciliation برای Galera.

بازیابیRejoin، Reconcile و بازگرداندن سرویس به حالت پایدار.

Observeسلامت نود، موتور، Replication، Endpoint و Metrics.

کاربر و دیتابیسساخت، دسترسی، چرخش رمز و حذف کاربر و دیتابیس از همان مسیر Job.

TLSوضعیت، تمدید و صدور دوباره‌ی گواهی‌ها و چرخش CA محصول.

Tuningاعمال پروفایل پیکربندی متناسب با منابع نود، با ری‌استارت ترتیب‌دار و امن.

MCP

Remote MCP بدون authority موازی. OAuth 2.1 با Authorization Code + PKCE در Panel نقش Authorization Server را دارد و MCP Addon نقش Resource Server؛ grant نهایی به همان mcp_clients، RBAC، scope و rate-limit موجود متصل می‌شود و یک سیستم دسترسی دوم نمی‌سازد.

دیتابیس را به‌عنوان یک سرویس اداره کنید، نه یک مجموعه دستورالعمل عملیاتی.

DBaaS Enterprise فاصله‌ی میان دانش موتور و عملیات تکرارپذیر را کم می‌کند.

بازگشت به محصولات 4SO ←