AlwaysOn Availability Group: وقتی Primary Replica را از دست می دهید
شنبه, ۳۰ ارديبهشت ۱۳۹۶، ۱۰:۲۴ ق.ظ
AlwaysOn Availability Group در برابر سناریوهای زیادی مقاوم است اما فرض کنید همه سرورهای شما خاموش می شوند و بعد موقع روشن کردن می بینید که سروری که در آخرین لحظه Primary بوده حالا دیگر بالا نمی آید. شما یک یا چند secondary دارید که به تنهایی و بسادگی نمی توانند Primary شوند
در این متن فرض می کنم که کلا دو سرور A و B داشته ایم و در آخرین لحظات A در حالت Primary بوده است. حالا بعد از رویداد، فقط سرور B را داریم که قبل از رویداد، Secondary بوده است.
در این شرایط دیتابیس های شما در حالت Recovery Pending قرار خواهد داشت و خود AlwaysOn در حالت Resolving.
قبل از ادامه کار بهتر است اگر امکان گرفتن یک نسخه پشتیبان از دیتابیس موجود را دارید حتما این کار را انجام دهید. به هر حال خطر از دست رفتن داده ها را به هر شکلی که هست باید کم کرد.
حالا راه حل شما به این بر می گردد که از A (سروری که در آخرین لحظات قبل از رویداد، Primary بوده) نسخه پشتیبان دارید یا نه. مهم نیست که این نسخه پشتیبان مربوط به چه زمانی باشد فقط باید در لحظه تهیه نسخه پشتیبان A در حالت Primary باشد.
اگر چنین نسخه پشتیبانی دارید، آن را برگردانید.
حالت AlwaysOn طبیعی خواهد شد. اما دیتابیسها (حداقل در سرور B) در حالت Not Synchronizing خواهد بود. دقت کنید که حالا سرور A اطلاعات قدیمی و سرور B اطلاعات جدید را دارد.
حالا بصورت دستی Failover کنید.
هشدارهایی مبنی از دست رفتن داده دریافت می کنید. در موردی که من تست کردم اطلاعات از دست نرفت. حالا B در حالت Primary است. باز هم دیتابیس Not Synchronizing است.
دیتابیس را از AlwaysOn خارج کنید.
حالت دیتابیس در سرور B عادی و در A به Restoring تبدیل خواهد شد.
دیتابیس را در A ( سروری که حالا Secondary است) حذف کنید.
در B دیتابیس را دوباره به AlwaysOn اضافه کنید.
حالا همه چیز به حالت طبیعی خودش برگشته. حتی در این حالت ناگوار هم AlwaysOn جوابگو بود
اگر هیچ نسخه پشتیبان قابل استفاده ای از سرور A ندارید (نسخه پشتیبان باید در حالی تهیه شده باشد که A در وضعیت Primary بوده است)
این یعنی Windows Cluster شما کلا خراب شده.
به هر حال باید یک سرور دیگر برای جایگزینی A بسازید و آماده کنید. اما برای B که هنوز عضوی از یک Cluster خراب است چه باید کرد؟
پیشنهاد من این است که B را از Cluster سابق خارج کنید و بعد Cluster را کلا حذف کنید و از نو بسازید.
برای خروج B از Cluster باید روی B در PowerShell دستور زیر را بزنید و yes بزنید.
Clear-ClusterNodeحالا باید در SQLServer خود AlwaysOn را پاک کنید و بعد دیتابیس خود را به حالت عادی برگردانید
برای برگرداندن دیتابیس به حالت عادی از دستورات زیر در SQLServer استفاده کنید (کپی شده از این نشانی)
Use [master]به جای SuspectModeDB<GUID> نام دیتابیس خودتان را بزنید
EXEC sp_resetstatus “SuspectModeDB<GUID>”
ALTER DATABASE “SuspectModeDB<GUID>” SET EMERGENCY DBCC checkdb(‘SuspectModeDB<GUID>‘)
ALTER DATABASE “SuspectModeDB<GUID>” SET SINGLE_USER WITH ROLLBACK IMMEDIATE
DBCC CheckDB(‘SuspectModeDB<GUID>‘,REPAIR_ALLOW_DATA_LOSS)
ALTER DATABASE “SuspectModeDB<GUID>” SET MULTI_USER
EXEC sp_resetstatus ‘SuspectModeDB<GUID>‘
حالا دیتابیس شما قابل استفاده است اما دیگر نه AlwaysOn دارید و نه Windows Cluster که هر دو را می توانید از نو بسازید.