معرفی و تعریف
طراحی دسترسپذیری بالا و بازیابی پس از بحران پایگاه داده، مجموعه‌ای از دانش و مهارت‌ها برای طراحی، پیاده‌سازی و آزمودن سازوکارهایی است که در برابر خرابی اجزای زیرساخت، اختلال شبکه یا از دست رفتن محیط عملیاتی، تداوم سرویس یا بازیابی داده و سرویس را فراهم می‌کنند.
هسته این مهارت، انتخاب و آزمون Replication، Failover، نسخه پشتیبان و روش بازیابی بر اساس دو هدف کسب‌وکاری است: نقطه بازیابی هدف (Recovery Point Objective یا RPO)، یعنی حداکثر میزان از دست رفتن داده قابلقبول که معمولاً بر اساس بازه زمانی بیان میشود و زمان بازیابی هدف (Recovery Time Objective یا RTO)، یعنی حداکثر زمان مجاز برای بازگشت سرویس.
این مهارت با تهیه نسخه پشتیبان یکسان نیست. مدیر پایگاه داده باید بداند در چه سناریویی نسخه پشتیبان کافی است، چه زمانی به Replica آماده نیاز دارد، Failover چگونه انجام میشود و پس از بازگشت سرویس چگونه از سازگاری داده و سلامت Replicaها اطمینان پیدا کند. مدیران پایگاه داده، مهندسان دواپس و مهندسان زیرساخت معمولاً از این توانمندی استفاده می‌کنند.
در محیط‌های ایرانی نیز این مهارت برای سامانه‌هایی اهمیت عملی دارد که داده تراکنشی یا عملیاتی خود را در زیرساخت داخلی، مرکز داده یا محیط ابری نگه می‌دارند؛ مانند سامانه‌های پرداخت، تجارت الکترونیک و شرکت‌های محصولی. انتخاب محل Replica و نسخه پشتیبان باید با محدودیت اتصال بین سایت‌ها، دسترسی عملیاتی تیم و امکان بازیابی واقعی از محل نگهداری نسخه‌ها هماهنگ شود.
مدت رسیدن به سطح کاربردی در این مهارت به دانش قبلی در زمینه پایگاه داده، موتور انتخابی، پیچیدگی معماری، تجربه کار با زیرساخت و میزان تمرین عملی بستگی دارد. برای یادگیری مؤثر، بهتر است به‌جای یک زمان ثابت، پیشرفت بر اساس توانایی طراحی سناریوهای HA و DR، اجرای Failover و Restore و آزمون RPO و RTO ارزیابی شود.
این مهارت را با نام‌های دیگری نیز می‌شناسند:
- دسترسپذیری بالا و بازیابی بحران دیتابیس
- طراحی HA و DR پایگاه داده
- طراحی تداوم سرویس و بازیابی بحران پایگاه داده
- Database HA/DR
- Database High Availability and Disaster Recovery
- Database Replication, Failover and Disaster Recovery
اهمیت و کاربردها
چرا این مهارت مهم است؟
قطع یا از دست رفتن داده در سامانه‌های عملیاتی میتواند ثبت سفارش، پرداخت، احراز هویت، گزارش‌گیری و پشتیبانی مشتری را متوقف کند. به همین دلیل، سازمان‌هایی که سرویس‌های حساس یا داده‌های عملیاتی مهم دارند، صرفاً به داشتن فایل پشتیبان اکتفا نمی‌کنند و برای تداوم سرویس و بازگشت کنترلشده برنامه می‌خواهند.
این مهارت در نقش‌هایی مانند مدیر پایگاه داده، مهندس دواپس و مهندس زیرساخت کاربرد پیدا میکند، اما میزان نیاز به آن به موتور پایگاه داده، حجم داده، معماری سرویس و مسئولیت عملیاتی تیم بستگی دارد. برای نمونه، تیمی که سامانه تراکنشی حساس را در مرکز داده خود نگه می‌دارد، ممکن است برای رسیدن به RTO و RPO موردنظر به Replica و سازوکار Failover نیاز داشته باشد، در حالی که برای یک سامانه کم‌حساسیت، Restore آزموده‌شده از نسخه پشتیبان میتواند کافی باشد.
در شرکت‌های محصولی، تجارت الکترونیک، پرداخت و سازمان‌های دارای زیرساخت داخلی در ایران، تصمیم درباره محل نگهداری نسخه پشتیبان و Replica فقط انتخاب ابزار نیست. تیم باید بررسی کند که نسخه‌ها واقعاً خارج از محل خرابی نگهداری می‌شوند، اتصال میان سایت‌ها برای Replication مناسب است و هنگام رخداد چه کسی دسترسی اجرای Runbook را دارد.
ارزش واقعی این مهارت زمانی مشخص میشود که بتوانید طرح خود را با سناریوی خرابی تمرین کنید، زمان بازیابی را ثبت کنید، میزان داده ازدست‌رفته را بسنجید و محدودیت‌های طرح را شفاف توضیح دهید. این توانمندی نیازمند همکاری با تیم‌های نرم‌افزار، شبکه و عملیات است؛ زیرا انتخاب RPO و RTO تصمیمی صرفاً فنی نیست و باید با هزینه زیرساخت، حساسیت داده و میزان توقف قابلقبول کسبوکار هماهنگ شود.
کاربردها
-
راه‌اندازی Replica برای پایگاه داده عملیاتی
ایجاد و پایش Replica برای کاهش وابستگی سرویس به یک نمونه اصلی و آماده‌سازی مسیر جایگزین در زمان خرابی.
-
طراحی Failover برای سامانه‌های تراکنشی
تعریف فرایند تشخیص خرابی، تغییر مقصد اتصال برنامه و انتقال نقش نمونه اصلی با حداقل ابهام عملیاتی.
-
بازیابی از حذف یا تغییر اشتباه داده
استفاده از نسخه‌های پشتیبان و قابلیت‌های بازیابی تا نقطه زمانی مناسب برای بازگرداندن داده پیش از خطای انسانی، در صورتی که موتور پایگاه داده و راهکار پشتیبان‌گیری از این قابلیت پشتیبانی کنند.
-
بازیابی پس از از دست رفتن سرور یا سایت
طراحی سناریوی بازگشت سرویس از محیط یا منطقه جایگزین، همراه با بررسی داده، اتصال برنامه و وضعیت Replicaها.
-
آزمون دوره‌ای طرح تداوم سرویس
شبیه‌سازی خرابی کنترلشده، اجرای Runbook، اندازه‌گیری زمان بازگشت و اصلاح مرحله‌های مبهم یا پرخطر.
-
پایش تأخیر Replication و آمادگی بازیابی
تنظیم شاخص‌ها و هشدارها برای تشخیص عقب‌ماندگی Replica، خطای پشتیبان‌گیری و کمبود ظرفیت ذخیره‌سازی.
ابزارهای مرتبط
پیش‌نیازها
پیش از شروع، بهتر است با موارد زیر آشنا باشید.
- مهارت پایگاه داده و SQL Databases and SQL
- مهارت مدیریت و راهبری پایگاه داده Database Administration
- مهارت پشتیبان‌گیری و بازیابی پس از بحران Backup and Disaster Recovery
- مهارت مدیریت سیستم‌های لینوکس Linux System Administration
- مهارت پایش و مشاهده‌پذیری سامانهها Monitoring and Observability
- دسترسی به یک محیط آزمایشگاهی ایزوله با حداقل دو نمونه پایگاه داده
- توانایی خواندن مستندات رسمی موتور پایگاه داده منتخب
مسیر یادگیری طراحی دسترسپذیری بالا و بازیابی پس از بحران پایگاه داده
-
۲۰ ساعت
تعریف اهداف تداوم سرویس برای یک سامانه
مفهوم خرابی، تداوم سرویس، نقطه بازیابی هدف (RPO) و زمان بازیابی هدف (RTO) را یاد بگیرید. برای یک سامانه فرضی مانند فروشگاه آنلاین، مشخص کنید کدام دادهها حساس‌ترند، چه میزان از دست رفتن داده قابلقبول است و چه مدت توقف سرویس قابل‌تحمل است.
بین دسترسپذیری بالا، بازیابی پس از بحران و پشتیبان‌گیری تمایز بگذارید. خروجی این گام باید یک جدول سناریوهای خرابی و هدف بازیابی هر سناریو باشد.
-
۳۰ ساعت
مبانی پشتیبان‌گیری و بازیابی قابلاعتماد را اجرا کنید
انواع نسخه پشتیبان، نگهداری نسخه‌ها، بررسی یکپارچگی فایل پشتیبان و بازیابی کامل را در یک موتور پایگاه داده تمرین کنید. سپس یک حذف اشتباه داده را شبیه‌سازی و مسیر بازیابی مناسب را انتخاب کنید.
برای PostgreSQL، بخش پشتیبان‌گیری و بازیابی در مستندات رسمی PostgreSQL و برای MySQL، بخش بازیابی تا یک نقطه زمانی در مستندات رسمی MySQL را بخوانید. برای هر نسخه پشتیبان، محل نگهداری، مسئول اجرا، روش اعتبارسنجی و مراحل Restore را مستند کنید. داشتن فایل Backup بدون آزمون Restore، اثبات بازیابی‌پذیری نیست.
-
۴۰ ساعت
Replication و سازگاری داده را پیکربندی کنید
مدل‌های اصلی Replication، تفاوت همگام و ناهمگام، تأخیر Replica و خطر داده‌های تأییدنشده را مطالعه کنید. با PostgreSQL، MySQL، Microsoft SQL Server یا Oracle Database یک محیط شامل نمونه اصلی و Replica بسازید.
Replication همگام میتواند برای سناریوهایی مناسب باشد که کاهش احتمال از دست رفتن تراکنش‌های تأییدشده اهمیت زیادی دارد، اما انتخاب آن باید اثر تأخیر شبکه، کارایی نوشتن، فاصله میان سایت‌ها و قابلیت‌های موتور پایگاه داده را نیز در نظر بگیرد. Replication ناهمگام میتواند برای فاصله جغرافیایی بیشتر یا بار نوشتن بالاتر مناسب باشد، اما باید مقدار احتمالی داده ازدست‌رفته در زمان Failover را با RPO مقایسه کنید. قابلیت‌های دقیق، روش تنظیم و محدودیت‌ها را فقط از مستندات موتور منتخب بررسی کنید؛ برای PostgreSQL، بخش High Availability، Load Balancing و Replication و برای MySQL، بخش Replication در مستندات رسمی MySQL نقطه شروع مناسبی هستند.
نوشتن داده روی نمونه اصلی، مشاهده رسیدن داده به Replica و ثبت تأخیر Replication را تمرین کنید. خروجی تمرین باید شامل مقدار تأخیر ثبت‌شده، RPO اندازه‌گیری‌شده در یک خرابی آزمایشی و نتیجه کنترل سازگاری داده میان نمونه‌ها باشد.
-
۳۵ ساعت
Failover و بازگشت نقش‌ها را عملیاتی کنید
فرایند Failover دستی و خودکار، تشخیص سلامت، تغییر اتصال برنامه و خطر Split-brain را بشناسید. در محیط آزمایش، خرابی نمونه اصلی را شبیه‌سازی کنید و سرویس را به نمونه جایگزین منتقل کنید.
Failover خودکار به سازوکار قابلاعتماد تشخیص سلامت، هماهنگی میان اجزای معماری برای جلوگیری از فعال‌شدن هم‌زمان چند نمونه اصلی و آماده‌بودن مسیر اتصال برنامه وابسته است. اگر برنامه امکان تغییر سریع مقصد اتصال، پراکسی یا DNS را ندارد، Failover ممکن است RTO موردنظر را برآورده نکند. Failover دستی میتواند در معماری‌هایی که خودکارسازی Failover مناسب یا در دسترس نیست استفاده شود، اما زمان تشخیص رخداد، تصمیم‌گیری و اجرای عملیات باید در محاسبه RTO واقعی در نظر گرفته شود.
پس از بازگشت نمونه قبلی، مراحل همگام‌سازی و بازگرداندن نقش‌ها را اجرا کنید. Runbook باید شامل فرمان‌های لازم، نقطه‌های تصمیم‌گیری، مسئول هر اقدام و روش بازبینی صحت داده باشد. خروجی تمرین باید زمان واقعی Failover، نتیجه کنترل سازگاری، وضعیت نمونه قبلی پس از بازپیوند و شواهدی از جلوگیری از Split-brain را ثبت کند.
-
۳۰ ساعت
سناریوی بازیابی پس از بحران را طراحی کنید
سناریوهایی مانند خرابی کامل سرور، حذف ناخواسته داده، خرابی ذخیره‌سازی و قطع ارتباط شبکه را تحلیل کنید. برای هر سناریو تصمیم بگیرید که Restore، Failover یا ساخت مجدد Replica راه‌حل مناسب‌تری است.
Restore زمانی مناسب است که داده به نقطه زمانی پیش از خطا برگردد یا Replica سالمی در دسترس نباشد؛ اما زمان انتقال و بازیابی حجم بالای داده باید با RTO سنجیده شود. Failover زمانی معنا دارد که Replica به‌اندازه کافی به‌روز و مسیر اتصال برنامه آماده باشد. ساخت مجدد Replica معمولاً پس از خرابی یا عقب‌ماندگی شدید آن لازم است و به حجم داده، پهنای باند، زمان نگهداری لاگ‌ها و روش همگام‌سازی موتور پایگاه داده وابسته است.
وابستگی‌های بیرون از پایگاه داده را نیز در نظر بگیرید؛ مانند DNS، تنظیمات اتصال برنامه، دسترسی کاربران، فضای ذخیره‌سازی و مانیتورینگ. در زیرساخت‌های داخلی یا چندسایتی، محل نگهداری نسخه پشتیبان و امکان دسترسی به آن در زمان از دست رفتن سایت اصلی را جداگانه آزمون کنید. خروجی این گام باید برای هر سناریو شامل تصمیم فنی، RPO و RTO هدف، RPO و RTO اندازه‌گیری‌شده، مسئول اجرا و معیار اعلام بازگشت سرویس باشد.
-
۲۵ ساعت
طرح را با تمرین خرابی و پایش ارزیابی کنید
برای تأخیر Replication، خطای Backup، فضای ذخیره‌سازی، در دسترس بودن Replica و زمان بازیابی، شاخص و هشدار تعریف کنید. با Prometheus، Grafana و Alertmanager یا ابزارهای معادل، وضعیت محیط آزمایش را مشاهده‌پذیر کنید.
حداقل چند سناریوی خرابی را زمان‌گیری کنید، داده‌های از دست‌رفته یا ناسازگار را بررسی کنید و نتیجه را با RPO و RTO هدف مقایسه کنید. سپس Runbook و طراحی را بر اساس یافته‌ها اصلاح کنید.
زمان تقریبی یادگیری
برآورد مجموع زمان آموزش، مطالعه و تمرین تا رسیدن به سطح کاربردی؛ بسته به پیش‌زمینه شما میتواند کمتر یا بیشتر باشد.
پروژه‌های تمرینی
برای آشنایی بهتر با این مهارت، توجه به موارد زیر میتواند مفید باشد.
-
آزمایشگاه Primary و Replica با PostgreSQL
توضیح پروژه: با Docker یک نمونه اصلی و یک Replica در PostgreSQL ایجاد کنید، داده آزمایشی وارد کنید، وضعیت و تأخیر Replication را بررسی کنید و راهنمای راه‌اندازی و بازیابی محیط را بنویسید.
-
Runbook بازیابی حذف اشتباه داده
توضیح پروژه: یک حذف جدول یا رکورد را شبیه‌سازی کنید و مراحل بازیابی تا نقطه زمانی مناسب، کنترل صحت داده و اعلام پایان رخداد را مستند کنید.
-
تمرین Failover کنترلشده
توضیح پروژه: خرابی نمونه اصلی را در محیط آزمایش ایجاد کنید، Failover را اجرا کنید، زمان بازگشت سرویس را اندازه بگیرید و مراحل بازگشت نمونه قبلی را ثبت کنید.
-
داشبورد آمادگی بازیابی پایگاه داده
توضیح پروژه: داشبوردی برای نمایش وضعیت Replica، تأخیر Replication، آخرین اجرای موفق Backup و ظرفیت ذخیره‌سازی طراحی کنید و آستانه هشدارها را توضیح دهید.
پرسش‌های پرتکرار
در این بخش، به تعدادی از پرسش‌های رایج درباره این مهارت پاسخ داده شده است.
تفاوت دسترسپذیری بالا با بازیابی پس از بحران چیست؟
دسترسپذیری بالا بر کاهش توقف سرویس هنگام خرابی اجزای سیستم، مانند از کار افتادن یک سرور یا مؤلفه زیرساختی، تمرکز دارد. بازیابی پس از بحران برای بازگرداندن سرویس و داده پس از رخدادهای گستردهتر، مانند از دست رفتن یک محیط یا منطقه عملیاتی، طراحی میشود. این دو میتوانند در یک معماری تداوم کسبوکار در کنار یکدیگر استفاده شوند. یک طرح خوب معمولاً هر دو را پوشش میدهد.
آیا داشتن نسخه پشتیبان برای بازیابی پس از بحران کافی است؟
همیشه نه. نسخه پشتیبان برای بازگرداندن داده ضروری است، اما Restore ممکن است با RTO موردنیاز سرویس سازگار نباشد. همچنین باید محل نگهداری نسخه‌ها، دسترسی‌ها، وابستگی‌های سرویس و آزمون واقعی بازیابی را در نظر بگیرید.
RPO و RTO را چگونه تعیین کنیم؟
این دو هدف باید با صاحبان کسبوکار و تیم فنی تعیین شوند. ابتدا مشخص کنید از دست رفتن چه مقدار داده و توقف چه مدت سرویس برای هر فرایند قابلقبول است. سپس راهکار فنی را با توجه به هزینه، پیچیدگی و محدودیت زیرساخت انتخاب کنید.
برای یادگیری این مهارت کدام پایگاه داده را انتخاب کنم؟
یک موتور را برای تمرین عمیق انتخاب کنید و مفاهیم را روی آن اجرا کنید. PostgreSQL و MySQL برای ساخت آزمایشگاه شخصی گزینه‌های مناسبی هستند، اما مفاهیم HA و DR در هر موتور با ابزارها و معماری‌های متفاوت پیاده‌سازی می‌شوند. اگر هدف شما آمادگی برای یک محیط کاری مشخص است، بهتر است تمرین عملی را روی همان موتور انجام دهید. اگر محیط کاری شما Microsoft SQL Server یا Oracle Database است، تمرکز روی همان موتور عملی‌تر خواهد بود.
چگونه ثابت کنم طرح بازیابی من واقعاً کار میکند؟
سناریوی خرابی کنترلشده اجرا کنید، زمان شروع تا بازگشت سرویس را ثبت کنید، دادهها را بررسی کنید و نتیجه را با RPO و RTO هدف بسنجید. مستندات Runbook، گزارش آزمون و داشبورد پایش، شواهد قابلارائه مهارت شما هستند.
Failover خودکار همیشه بهتر از Failover دستی است؟
خیر. Failover خودکار میتواند زمان واکنش را کم کند، اما به تشخیص سلامت قابلاعتماد و کنترل خطرهایی مانند Split-brain نیاز دارد. در برخی سامانهها، Failover دستی با تأیید مسئول فنی ریسک کمتری دارد.
برای زیرساخت داخلی در ایران، نسخه پشتیبان را کجا نگه داریم؟
نسخه پشتیبان نباید فقط روی همان سرور یا همان محل خرابی نگهداری شود. محل دوم باید از نظر دسترسی، ظرفیت، امنیت و امکان Restore واقعی آزمون شود. انتخاب مرکز داده، سایت جایگزین یا فضای ذخیره‌سازی ابری به سیاست سازمان، حساسیت داده و محدودیت اتصال بستگی دارد.
