Upgrading Always On Availability Group Replica Instances

February 2, 2017

 

השבוע שלי התחיל בהקמת קלסטר לשרת ייצור והוספת Node נוסף בכדי להקים Always On בין 2 השרתים - SQL Server 2012 Enterprise.

התקנתי את הNode החדש ומראש, גלגלתי את ההתקנות האחרנות שייצאו לMicrosoft.

כאשר סיימתי עם ההתקנות ולאחר מספר אתחולים, השרת היה עם

 SQL Server 2012 - Service Pack 3 – Cumulative Update 7.

הקמתי Always On בין השרתים, ביצעתי בדיקות והכל עבר תקין.

 

המטרה החדשה הייתה לעדכן את הNode הראשון אשר היה

שרת מסוג SQL Server 2012 - Service Pack 1, תחילה פעלתי לפי הכתוב –

Before an upgrade, you should:

  • Perform a full backup of every database

  • Try a manual failover. Make sure the AG fails over a Synchronous replicas and that the synchronization state of the replicas is SYNCHRONIZED

  • Disable automatic backups on Secondary while they are being upgraded

  • Disable automatic backups on Primary before the upgrade of Primary

  • Do not upgrade Primary before any or all of the Secondary or.

 

Then here is the Rolling Upgrade Process:

  1. Remove automatic failover on all synchronous-commit replicas

  2. Upgrade all remote secondary replica instances running asynchronous-commit secondary replicas

  3. Upgrade the all local replica secondary instances that are not currently running the primary replica

  4. Manually fail over the availability group to a local synchronous-commit secondary replica

  5. Upgrade or update the local replica instance that formerly hosted the primary replica

  6. Configure automatic failover partners as desired

http://dba.stackexchange.com/questions/130752/apply-sp3-on-sql-server-2012-alwayson-aags

 

התחלתי עם Service Pack 3 ובסיום ההתקנה קיבלתי את השגיאות הבאות

Cannot recover the master database. SQL Server is unable to run. Restore master from a full backup, repair it, or rebuild it. For more information about how to rebuild the master database.

 

Script level upgrade for database 'master' failed because upgrade step 'SSIS_hotfix_install.sql' encountered error 922, state 1, severity 25. This is a serious error condition which might interfere with regular operation and the database will be taken offline. If the error happened during upgrade of the 'master' database, it will prevent the entire SQL Server instance from starting. Examine the previous errorlog entries for errors, take the appropriate corrective actions and re-start the database so that the script upgrade steps run to completion.

 

תחילה, ניסיתי להבין איך אני מחזיר את הNode לעבודה ומרים את הServices בחזרה,

מקריאה בכל מיני פורומים בעקבות השגיאה הראשונה הבנתי שאני אצטרך לבנות את הmaster מחדש.

אך, כאשר חיפשתי אחר השגיאה השניה, גיליתי את התשובה הזאת –

https://social.msdn.microsoft.com/Forums/sqlserver/en-US/69c1590c-92a7-42ae-a6bd-aaa17744b4c5/after-update-windows-including-sql-2012-sp2-unable-to-start-sql-serviceinstance?forum=ssdt

 

מיד לאחר יישום הכתוב, (כמה דקות וחיוך שחזר לפנים) הכל חזר לעבודה תקינה.

TF902

Bypasses execution of database upgrade script when installing a Cumulative Update or Service Pack. If you encounter an error during script upgrade mode, it is recommended to contact Microsoft SQL Customer Service and Support (CSS) for further guidance. For more information, see this Microsoft Support article.

WARNING: This trace flag is meant for troubleshooting of failed updates during script upgrade mode, and it is not supported to run it continuously in a production environment. Database upgrade scripts needs to execute successfully for a complete install of Cumulative Updates and Service Packs. Not doing so can cause unexpected issues with your SQL Server instance.

Scope: global only

 

לא המשכתי עם ההתקנה של ה Cumulative Update 7, כעת הכוונה הייתה להבין מה השתבש ע"מ שזה לא יקרה שוב.

 

דעה אישית – לא מצאתי הסתמכות מהרשת או מיקרוסופט.

  • כאשר אנו באים לעדכן שרת שנמצא תחת Always On או Mirror הרפליקה/מסדי הנתונים שנמצאים תחת אותה רפליקה שאותה נרצה לעדכן יהיה ניתנים במקרה הטוב ביותר רק לקריאה בלבד.

  • מיקרוסופט מוציאה עדכונים שלרוב מומלץ להתקין Cumulative Update/ Service Pack כאחד – ניתן לקרוא בהרחבה –

  • חלק מהעדכונים מכילים עדכונים ל 2 מוצרי (Out of the box)  נוספים כמו SSRS וSSIS. כאשר, SSIS מכיל User database בשם SSISDB, וSSRS המכיל User databases ReportServer, ReportServerTempdb.

  • בהנחה שחלק מהתיקונים שנמצאים בCombinative Update/ Service Pack, מכילים סקריפטים לשינוי סכמה או תוכן לאחד ממסדי הנתונים בסעיף הקודם ואותם מסדי נתונים נמצאים תחת Always On או Mirror, ההמלצה שלי היא להוציא אותם זמנית לטובת השדרוג מהמערך. כלומר, במקרה שלי לנתק את SSISDB מה Availability Group.

 

 

הנוהל החדש(גזור ושמור)

Before an upgrade, you should:

  • Perform a full backup of every database

  • Try a manual failover. Make sure the AG fails over a Synchronous replicas and that the synchronization state of the replicas is SYNCHRONIZED

  • Disable automatic backups on Secondary while they are being upgraded

  • Disable automatic backups on Primary before the upgrade of Primary

  • Do not upgrade Primary before any or all of the Secondary or.

 

Then here is the Rolling Upgrade Process:

  1. Remove automatic failover on all synchronous-commit replicas

  2. Remove SSISDB, ReportServer, ReportServerTempdb from AG.

  3. Upgrade all remote secondary replica instances running asynchronous-commit secondary replicas

  4. Upgrade the all local replica secondary instances that are not currently running the primary replica

  5. Manually fail over the availability group to a local synchronous-commit secondary replica

  6. Upgrade or update the local replica instance that formerly hosted the primary replica

  7. Configure automatic failover partners as desired

  8. Join SSISDB, ReportServer, ReportServerTempdb to AG.

 

 

 

כעת המשכתי עם התקנת Cumulative Update 7 אשר עברה בצורה חלקה.

 

מה דעתכם?

האם נתקלתם בשגיאות כאלה בעת שדרוג?

 

קריאה בהרחבה:

The Hard Truth About Patching SQL Server Availability Groups (Hotfixes, Cumulative Updates, and Service Packs)

Please reload

Featured Posts

I'm busy working on my blog posts. Watch this space!

Please reload

Recent Posts

October 31, 2017

October 29, 2017

Please reload

Archive
Please reload

Search By Tags