Upgrading Always On Availability Group Replica Instances
השבוע שלי התחיל בהקמת קלסטר לשרת ייצור והוספת 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:
Remove automatic failover on all synchronous-commit replicas
Upgrade all remote secondary replica instances running asynchronous-commit secondary replicas
Upgrade the all local replica secondary instances that are not currently running the primary replica
Manually fail over the availability group to a local synchronous-commit secondary replica
Upgrade or update the local replica instance that formerly hosted the primary replica
Configure automatic failover partners as desired
התחלתי עם 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 מחדש.
אך, כאשר חיפשתי אחר השגיאה השניה, גיליתי את התשובה הזאת –
מיד לאחר יישום הכתוב, (כמה דקות וחיוך שחזר לפנים) הכל חזר לעבודה תקינה.
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:
Remove automatic failover on all synchronous-commit replicas
Remove SSISDB, ReportServer, ReportServerTempdb from AG.
Upgrade all remote secondary replica instances running asynchronous-commit secondary replicas
Upgrade the all local replica secondary instances that are not currently running the primary replica
Manually fail over the availability group to a local synchronous-commit secondary replica
Upgrade or update the local replica instance that formerly hosted the primary replica
Configure automatic failover partners as desired
Join SSISDB, ReportServer, ReportServerTempdb to AG.
כעת המשכתי עם התקנת Cumulative Update 7 אשר עברה בצורה חלקה.
מה דעתכם?
האם נתקלתם בשגיאות כאלה בעת שדרוג?
קריאה בהרחבה:
