خاطرات فنی من

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

سعی می کنم مطالب برای دیگران هم قابل استفاده باشند اما به دلیل کمی وقت نمی توانم زیاد نگران نگارش و چینش متن باشم

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]

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>‘
به جای SuspectModeDB<GUID> نام دیتابیس خودتان را بزنید

حالا دیتابیس شما قابل استفاده است اما دیگر نه AlwaysOn دارید و نه Windows Cluster که هر دو را می توانید از نو بسازید.

نظرات  (۰)

هیچ نظری هنوز ثبت نشده است

ارسال نظر

ارسال نظر آزاد است، اما اگر قبلا در بیان ثبت نام کرده اید می توانید ابتدا وارد شوید.
شما میتوانید از این تگهای html استفاده کنید:
<b> یا <strong>، <em> یا <i>، <u>، <strike> یا <s>، <sup>، <sub>، <blockquote>، <code>، <pre>، <hr>، <br>، <p>، <a href="" title="">، <span style="">، <div align="">
تجدید کد امنیتی