مقدمه

با توجه به نیاز روز افزون مشاغل و کاربران به برنامه های کاربردی حیاتی، همه شرکت ها باید نحوه ارائه و دسترسی (Availability) مشتریان به خدمات را به دقت برنامه ریزی کرده و بتوانند در صورت بروز هر گونه حادثه بد (Disaster)، مدت زمان وقفه برنامه ریزی شده را کوتاه کنند. SQL Server برای برطرف کردن این مسئله از چندین تکنیک High Availability و Disaster Recovery پشتیبانی می کند و بسیاری از متخصصان معتقدند که اجرای یک سیستم پایگاه داده بدون در نظر گرفتن HADR، همچون راه رفتن روی یک طناب باریک بدون چتر نجات است. از این رو بر آن شدیم تا در این مطلب به آشنایی با High Availability و Disaster Recovery در SQL Server بپردازیم. با ما همراه باشید.
بدترین اتفاقی که می تواند رخ دهد این است که تا تیم فناوری ریشه مشکل را در پایگاه داده بیابند و آن را برطرف کنند، شما هیچ پاسخی برای مشتری نداشته باشید. مشتریان در انتظار، کارمندان در انتظار و کسب و کارتان عملاً بسته خواهد بود.

آشنایی با Disaster Recovery در SQL Server

بازیابی از حادثه یا Disaster Recovery شامل پیاده سازی هر سیستم یا تکنیکی است که پس از بروز حادثه، به شما کمک کند داده های خود را بازگردانید. سیستمی که High Availability بالایی دارد، فقط داده ها را در دسترس قرار می دهد و لزوماً صحت داده ها را کنترل نمی کنند. تصور کنید که توسعه دهنده در شرح «UPDATE» یک عبارت «WHERE» را جا بیندازد و ناگهان کل اطلاعات جدول بپرد. در این سناریو هیچ راه حلی نه تنها کمک نمی کند، بلکه شرایط را وخیم تر خواد کرد. بنابراین لازم است که همیشه یک برنامه بازیابی از حادثه کاملاً مستند و به روز داشته باشیم.

آشنایی با High Availability در SQL Server

هدف اصلی High Availability یا دسترسی بالا این است که با به حداقل رساندن مدت زمان وقفه ناشی از اتفاقات برنامه ریزی شده یا نشده، از در دسترس بودن خدمات اطمینان حاصل شود. تقریباً همه تکنیک های High Availability، زیرساخت های خود را در یک مکان جغرافیایی واحد قرار می دهند و می توانند به طور خودکار بین این زیرساخت ها جا به جا شوند. برای آشنایی با High Availability و Disaster Recovery در SQL Server ابتدا باید با تکنیک های آن ها آشنا شویم:

Backup و Restore پایگاه داده

یکی از راه های ارائه دسترسی بالا (HR) و بازیابی از حادثه (DR) گرفتن یک نسخه پشتیبان (Backup) از SQL Server و کپی کردن آن در وبسایت یا سروری با قابلیت HA یا DR است. البته این تکنیگ بلادرنگ نیست و زمان و تلاش فراوانی می طلبد. فرایند بازیابی (Restore) به اندازه بکاپ گیری (Backup) حائز اهمیت است. هر چند وقت یک بار دیتابیس های انتخابی را در سرور های دیگر بازیابی کرده و صحت عملکرد آنها را بررسی کنید. می توانید این روند را به گونه ای مستند کنید که در مواقع بازیابی از حادثه (DR) واقعی، یک پروتکل اثبات شده حاضر و آماده داشته باشید.
البته در سناریوهای واقعی برای بازیابی از حادثه، باید (مجددا) یک سیستم SQL Server جدید ایجاد کنید تا نسخه پشتیبان بر روی آن بازیابی شود. گرفتن اسنپ شات از سرور مجازی می تواند در بازیابی سیستم موثر باشد، اما نمیتوان آن را جایگزین کامل نسخه بکاپ دیتابیس دانست.

آشنایی با High Availability: Log Shipping

در اولین گام آشنایی با High Availability و Disaster Recovery در SQL Server به بررسی Log Shipping می پردازیم.
Log Shipping از دو نوع پایگاه داده استفاده می کند، اولیه (مبدا) و ثانویه (مقصد). هرگونه ورود به سیستم به صورت برنامه ریزی شده پشتیبان گیری می شود (مثلاً هر 3 دقیقه یک بکاپ) و از دیتابیس اولیه به دیتابیس ثانویه منتقل می گردد. تکنیک Log Shipping در مرکز داده اصلی به عنوان یک راه حل High Availability و در سرتاسر مراکز داده که از لحاظ جغرافیایی پراکنده شده اند، یک راه حل Disaster Recovery در نظر گرفته می شود. به منظور نظارت و خودکارسازی کل فرآیند، می توان یک نمونه سرور سوم (اختیاری) را به عنوان بخشی از این معماری در نظر گرفت تا اطلاعات مربوط به سوابق و وضعیت پشتیبان گیری و بازیابی عملیات را ثبت کند.

Transactional Replication

این تکنیک یک راه حل high availability بلادرنگ است که در آن یک سرور اصلی معروف به Publisher تمام جداول پایگاه داده یا جداول انتخاب شده را در یک یا چند سرور ثانویه معروف به Subscriber، منتشر می کند. از این سرورهای ثانویه می توان در جهت اهداف گزارش گیری نیز استفاده کرد.

Transactional Replication با سه عامل کار می کند:

  •  SQL Server Snapshot Agent یک اسنپ شات حاوی آبجکت های پایگاه داده که باید کپی شوند را آماده می کند. می توان آن را به عنوان یک فایل پشتیبان کامل در نظر گرفت.
  •  The Distribution Agent مسئول کپی اسنپ شات در Subscriber ها است.
  •  The Log Reader Agent مسئول نظارت بر گزارش تراکنش های SQL Server در پایگاه داده Subscriber ها و کپی این تراکنش ها در پایگاه داده Publisher است، تا بعدها توسط Distribution Agent در سرور Subscriber ها کپی شود.

آشنایی با High Availability: Database Mirroring

میرور کردن پایگاه داده یا Database Mirroring تقریباً یک تکنیک منسوخ است که همچنان در برخی از نسخه های اخیر SQL Server مشاهده می شود. این تکنیک شامل حداقل دو سرور است. سرور اصلی SQL، معروف به سرور اصلی (Principal server) و سرور ثانویه معروف به سرور آینه (Mirror server). یک سرور دیگر نیز میتوان به طور اختیاری به عنوان سرور شاهد (Witness server) اضافه کرد. سرور شاهد ارتباط بین این دو سرور و در دسترس بودن آن ها را بررسی کرده و خرابی خودکار یا تغییر نقش بین این دو سرور را انجام می دهد. سرور شاهد ارتباط بین این دو سرور و در دسترس بودن آنها را بررسی کرده و خرابی خودکار یا تغییر نقش بین این دو سرور را انجام می دهد. حالت ایمنی بالا (High-safety)

  •  حالت ایمنی بالا – همزمان (High Safety Mode) – کوچکترین تغییر در پایگاه داده اصلی به صورت همزمان در پایگاه داده اصلی و میرور ارسال اعمال می شود. این حالت این تکنیک برای کاربردهای High Availability مناسب است.
  •  حالت عملکرد بالا – غیرهمزمان (High Performance Mode) – هرگونه تغییر در پایگاه داده اصلی در خود پایگاه داده اصلی انجام می شود و تغییرات به صورت غیرهمزمان به پایگاه داده میرور ارسال می شوند. این حالت این تکنیک برای کاربردهای Disaster Recovery مناسب است.

Always on Failover Cluster

در ادامه آشنایی با High Availability، باید بگوییم تکنیک Always on Failover Cluster یک راه حل دسترسی بالا است که بر اساس قابلیت خوشه بندی Windows Server Failover Clustering ساخته شده است. در این روش تعدادی سرور معروف به گره های خوشه ای با اجزای سخت افزاری و نرم افزاری مشترک وجود دارند که برای نمونه خوشه شکست خورده high availability را فراهم می کنند.
هنگامی که SQL Server Failover Cluster پیکربندی و راه اندازی می شود، هر یک از سرویس های SQL Server و گروه های منابع نظیر فضای ذخیره سازی مشترک، نام شبکه و IP های مجازی، در یک زمان مشخص می تواند فقط متعلق به یکی از گره های خوشه باشد. در صورت بروز هرگونه خرابی از جانب سیستم عامل، سخت افزار یا خرابی سرویس، در گره فعال که صاحب آن منبع است، مالکیت منابع به طور کامل به یک گره خوشه دیگر منتقل می شود. به عبارت دیگر در این تکنیک دیتابیس SQL Server در یک زمان معین فقط در یک گره قرار گرفته و آنلاین است و هیچ کپی از آن در دیگر گره ها وجود ندارد.

آشنایی با High Availability: Always on Availability Groups

آخرین تکنیکی که برای آشنایی با High Availability معرفی می کنیم، Always on Availability Groups است.
Always on Availability را می توان نسخه پیشرفته Database Mirroring دانست. در این تکنیک دسترسی بالای کاربر (high availability) به مجموعه ای از پایگاه های داده فراهم می شود که می توانند همه با هم خراب شوند.
همانطور که اشاره کردیم، در تکنیک Database Mirroring امکان خواندن داده از روی پایگاه داده میرور وجود ندارد، اما در این تکنیک تنظیماتی اضافه شده تا امکان خواندن و نوشتن بر روی سرور اصلی و امکان خواندن از روی سرور ثانویه وجود داشته باشد. همچنین سرورهای ثانویه با اجرای بکاپ گیری، حجم داده در سرور اصلی را سبک می کنند.
تنها مشکلی که در این روش وجود دارد، بالا بودن هزینه سخت افزارهای مورد نیاز و موارد دیگر است. هرچه تعداد کپی ها بیشتر باشد، هزینه بیشتر خواهد بود. البته در دنیای امروز می توان با استفاده از یک محیط ترکیبی، برخی از زیرساخت ها را در فضای ابری راه اندازی کرد و به این ترتیب هزینه ذخیره سازی را تا حد زیادی کاهش داد.

کلام آخر

امروزه کلیه کسب و کارهایی که از سخت افزار و نرم افزار یا بهتر بگوییم پایگاه داده استفاه می کنند، به یک برنامه High Availability و Disaster Recovery نیاز دارند تا بتوانند ضمن فراهم آوردن دسترسی بالای کاربر، زمان خرابی سیستم را به حداقل برسانند و عملاً به تداوم کسب و کار خود کمک کنند. بهترین راه حل های HA و DR باید با توجه به نوع کسب و کار شما و الزامات تجاری آن انتخاب شوند. امیدواریم در این مطلب علاوه بر آشنایی با High Availability و Disaster Recovery در SQL Server، درک بهتری از مفاهیم سطح بالای تکنیک های مختلف HA/DR به دست آورده باشید.

https://www.sqlshack.com/sql-server-transaction-log-and-high-availability-solutions/

https://dallasdbas.com/sql-server-hadr-overview/

https://www.red-gate.com/simple-talk/databases/sql-server/learn/sql-server-high-availability-and-disaster-recovery-plan/