یک روز ، یک جمله ...

امروز به هر کاری که قراره انجام بدی، باور داشته باش

25 اسفند

آموزش راهکارهای HA و DR در SQL Server - بخش ششم مطلب ویژه

در این بخش می خواهیم به شرح Database Mirroring بپردازیم. این راهکار به عنوان یک راهکار در جهت ایجاد یک DRP می باشد.

 آشنایی با Database Mirroring :

ساختار Mirroring یک ساختار بسیار محبوب می باشد. این ساختار با ساختار Failover Clustering و Log Shipping و امثال آنها همخوانی دارد. آشنایی با ویژگی DB Mirroring به شما کمک می کند تا با مفهوم جدید Always On نیز بهتر آشنا شوید.

این ساختار یک راهکار HA و DRP می باشد. در ساختار Mirroring تمام تجهیزات به صورت مجزا ایجاد می شوند و در نهایت دو نقطه به صورت همزمان با یکدیگر همسان سازی شده و در صورت بروز رخداد برای سرویس یا فایل دیتابیس می توان از نقطه مقابل سرویس دهی را ادامه داد.

این ساختار دارای 2 حالت زیر می باشد:

  • High Performance (Asynchronous Mirror)
  • High Safety (Synchronous Mirror)

حالت High Performance :

در این حالت هر تراکنشی که بر روی Log دیتابیس اصلی قرار داده شود، به سرعت بر روی Queue جهت ارسال به دیتابیس Mirror نیز قرار داده می شود و در نقطه مقابل نیز اعمال می شود. به این فرآیند Hardening گفته می شود.

در این حالت میزان استفاده از منابع در سرور اصلی در حداقل مقدار ممکن می باشد.

مشکل این حالت در این است که در صورت بروز رخداد، اطلاعات موجود در Queue که به سمت دیتابیس Mirror ارسال نشده است (به دلایلی مانند Latency در شبکه) از دست خواهد رفت.

حالت High Safety :

این حالت به منظور رفع مشکل حالت High Performance ایجاد شد، اما مشکل استفاده بیش از حد از منابع را دارد. در این حالت زمانیکه یک تراکنش ایجاد می شود، تا زمانیکه بر روی نقطه مقابل Commit نشود، نهایی نمی شود.

ایجاد Endpoint :

یک Endpoint در واقع یک پورت TCP می باشد که از طریق آن دو نقطه در ساختار Mirroring می توانند با یکدیگر ارتباط برقرار کنند. برای شروع کار ابتدا می بایست این Endpoint را ایجاد نماییم.

نکته: در صورتیکه سرورهای مربوط به سرویس های SQL در یک شبکه و عضو یک سرویس دامین باشند، جهت ایجاد Endpoint می بایست سرویس SQL را با یک حساب کاربری که دارای سطح دسترسی مناسب (مدیر سیستم محلی) باشد اجرا کنیم. در غیر این صورت در فرآیند ایجاد Mirroring به خطای 1418 مواجه می شویم.

برای ایجاد Endpoint کافی است از اسکریپت زیر استفاده نمایید:


CREATE ENDPOINT endpoint_mirroring
STATE = STARTED
AS TCP ( LISTENER_PORT = 5022 )
FOR DATABASE_MIRRORING (ROLE=PARTNER);

این اسکریپت را می بایست در هر دو نقطه اجرا نمایید.

نکته: در صورتیکه دو نقطه عضو یک دامین مشترک نمی باشند، باید از حساب های کاربری برای اتصال Endpoint به سرویس SQL استفاده نمایید که دارای دسترسی Connect باشد. برای این کار از دستور زیر در هر Node استفاده نمایید:

GRANT CONNECT ON ENDPOINT::endpoint_mirroring TO [Account Name]

بعد از ایجاد Endpoint می توانید اقدام به ایجاد Mirroring نمایید.

ایجاد Mirroring :

جهت ایجاد Mirroring دیتابیس می بایست در حالت Full Recovery قرار گیرد. سپس از دیتابیس یک نسخه Full Backup گرفته شود و در نقطه مقابل به صورت With NoRecovery بازگردانی شود. در این صورت پس از ایجاد دیتابیس، Transaction Log ها می توانند از نقطه اصلی به این نقطه اعمال شوند.

پس از بازگردانی دیتابیس، با دستور زیر می توانید ساختار Mirroring را ایجاد نمایید:


ALTER DATABASE ‘DATABASE NAME’
SET PARTNER = ‘TCP://’SERVER NAME’:5022’;

نکته: بسیار مهم است که بدانیم جهت برقراری Mirroring می بایست دستور بالا را ابتدا بر روی نقطه ای اجرا نماییم که به عنوان سرویس دهنده ثانویه لحاظ می شود سپس روی سرویس دهنده اصلی آنرا اجرا نماییم.

نکته: به صورت پیش فرض، حالت Mirroring بر روی High Safety تنظیم می شود.

در سناریو ما حالت انتخابی High Safety می باشد. در این حالت خواهیم داشت:

  • تراکنش ها از حافظه به Transaction Log منتقل می شوند.
  • تراکنش هایی که به Log منتقل شده اند به صورت اکتیو باقی مانده و به صف انتظار ارسال به نقطه مقابل منتقل می شوند.
  • از صف انتظار نقطه اصلی، به صف انتظار نقطه مقابل انتقال پیدا می کنند
  • از صف انتقال نقطه مقابل روی Transaction Log آن نوشته می شوند
  • یک تاییدیه از سمت صف انتقال Mirror به صف انتقال اصلی ارسال می شود تا فرآیند نوشتن تراکنش ها در Transaction Log اصلی پایان پذیرد.

نکته: پس از برقراری ساختار Mirroring به صورت High Safety هر دو نقطه به صورت کامل همسان می شوند مگر اینکه شرایط زیر ایجاد شود:

  • قطع شدن شبکه
  • معلق کردن ساختار Mirror به صورت دستی

در این صورت Log Record ها درون Send Queue باقی می مانند تا زمانیکه ارتباط بین دو نقطه برقرار شود.

باید توجه داشته باشید در این حالت در صورت قطع شدن ارتباط و در نهایت توقف همسان سازی تراکنش ها بین دو نقطه، حالت Failover Auto نیز امکانپذیز نخواهد بود.

نکته: حالت High Performance فقط در نسخه Enterprise وجود دارد.

جهت تغییر حالت به High Performance و به عبارتی جهت غیر فعال کردن Safety در ساختار Mirroring از دستور زیر استفاده می نماییم:

ALTER DATABASE ‘Database Name’ SET PARTNER SAFETY OFF;

نکته: در صورتیکه می خواهید به صورت دستی اقدام به Failover نمایید و در حالت High Performance می باشید، بهتر است ابتدا حالت را به High Safety تغییر دهید:

ALTER DATABASE ‘Database Name’ SET PARTNER SAFETY FULL;

سپس اقدام به Failover کردن نمایید:

ALTER DATABASE ‘Database Name’ SET PARTNER FAILOVER;

و سپس حالت را به High Performance تغییر دهید. با این کار احتمال از دست دادن تراکنش ها را به حداقل خواهید رساند.

نکته: موارد گفته شده در بالا بر روی سرور اصلی (Principal ) اجرا می شوند، اما اگر سرویس SQL مربوط به دیتابیس اصلی از دسترس خارج شود چگونه می توان عمل Failover را انجام داد؟

برای این کار می بایست دستور زیر را روی سرور Mirror و بر روی دیتابیس Master اجرا نمایید:

ALTER DATABASE ‘Database Name’
SET PARTNER FORCE_SERVICE_ALLOW_DATA_LOSS;

براساس موارد بالا می توان به نتیجه زیر رسید:

Asynchronous Mirror = Disaster Recovery
Synchronous Mirror = High Availability

استفاده از Witness در حالت High Safety :

سرور Witness به منظور ایجاد شرایط Auto Failover استفاده می شود. این سرور دارای سرویس SQL می باشد و با صحبت کردن با دو نقطه Mirror متوجه می شود که سرویس اصلی از کار افتاده است یا خیر.

به منظور فعال کردن این سرور ابتدا می بایست برای آن Endpoint ایجاد نمایید. اسکریپت ایجاد Endpoint که در بالا بیان شده است را برای این سرور نیز اجرا نمایید.

سپس با اسکریپت مربوط به دادن دسترسی، به حساب کاربری مورد نظر دسترسی Connect را بدهید.

در نهایت اسکریپت زیر را بر روی سرویس اصلی اجرا نمایید:

ALTER DATABASE ‘Database Name’
SET WITNESS = ‘TCP://’WITNESS NAME:5022’
GO

بعد از اجرای این دستور، گزینه مربوط به حالت High Safety With Automatic Failover نیز فعال می شود.

نکته : موارد گفته شده در بالا، تماما به صورت اسکریپت نویسی انجام شده اند، اما در صورت نیاز می توانید با راست کلیک کردن بر روی دیتابیس و انتخاب گزینه Properties و سپس Mirroring اقدام به انجام فرآیند مذکور به صورت Wizard نمایید.

نکته: باید توجه داشته باشید که بر خلاف ساختار Failover Cluster که یک آدرس منطقی برای تمام Node ها تعریف می شود، در ساختار Mirror هر سرور دارای آدرس مخصوص خود می باشد. بنابراین می بایست ساختار Connection String مربوط به Application را به صورت زیر تعریف نمایید:

Datasource=’DB Name’; failover partner=’Second DB’

عیب یابی Mirroring :

عیب یابی ساختار Mirroring در دسته بندی های زیر قرار داده می شوند:

  1. Instance Level Problems
  2. Performance Issues
  3. Connectivity and Failover
  4. Post Failover Issues

مشکلات مربوط به Instance به دلایل زیر رخ می دهند:

  • رشد فایل log
  • پر شدن Send Queue
  • بلاک کردن

مشکلات مربوط به Performance :

  • روش اول به منظور بررسی مشکلات مربوط به Performance استفاده از ابزاری به نام Database Mirroring Monitor در محیط SSMS می باشد. این ابزار در زیر مجموعه Tasks دیتابیس قرار دارد.
  • روش دوم استفاده از Performance Monitor سیستم عامل ویندوز می باشد.
  • روش سوم استفاده از Mirroring System Stored Procedures می باشد.

مشکلات مربوط به Connectivity and Failover :

در این بخش می خواهیم بدانیم که عمل Failover به چه دلیلی رخ داده و یا به چه دلیلی رخ نداده است. تصور کنید دو Node با یکدیگر Mirror شده اند و سرور Witness در حال رصد این دو می باشد. حال:

  • اگر اتصال بین دو Node قطع شود، عمل Failover رخ نخواهد داد و Node اصلی Log Record ها را در Send Queue خود نگه خواهد داشت.
  • اگر اتصال بین دو Node و اتصال Witness با Node اصلی قطع شود Auto Failover رخ خواهد داد.
  • اگر اتصال Witness به هر دو Node قطع شود Auto Failover رخ نخواهد داد.

نکته: دیتابیس در حالت Mirroring به صورت Restoring می باشد و قابلیت برقراری Connection توسط کاربر را نخواهد داشت. در صورت بروز رخدادی که مانع ایجاد Auto Failover شود می بایست به صورت دستی دیتابیس را از حالت Restoring به حالت Principal تغییر دهیم.

مشکلات مربوط به Post Failover :

مشکلات مربوط به Post Failover به دسته بندی های زیر تقسیم می شوند:

  • از دست دادن Object های یک Instance مانند Job ها
  • حذف یک حساب کاربری
  • اتصال غلط Application به یک مسیر اشتباه

یک سناریو Enterprise برای پیاده سازی HA و DRP :

DB Mirroing

رضا اردانه

مدیریت وب سایت آموزش دیجیتال

1 نظر

  • پیوند نظر منصور منصور 16/07/97

    سلام. خسته نباشید
    آقا وقتی دیتابیس رو با دستور force service به حالت principal در میاریم هنوز هم تو حالت restoring میمونه. توضیح میدید که چجوری میشه دسترسی پیدا کرد بهش؟
    ممنون

نظر دادن

خبرنامه

برای دریافت جدیدترین خبرهای سایت در خبرنامه عضو شوید