קביעת תצורה של קבוצות זמינות גבוהה הפועלות תמיד ב- SQL Server

במאמר זה, נדריך אותך במדריך שלב אחר שלב כיצד להתקין ולקבוע את התצורה של קבוצות זמינות תמיד ב- SQL Server הפועלות ב- Windows Server 2019, נדון בתרחישי מעבר לגיבוי בעת כשל וכמה נושאים קשורים אחרים.

קבוצות זמינות תמיד פועלות מספקות זמינות גבוהה ב- MIcrosoft SQL Server. Always On הופיע במהדורת MSSQL 2012.

תכונות של קבוצות זמינות תמיד ב- SQL Server

לשם מה ניתן להשתמש בקבוצות זמינות של SQL Server?

• MS SQL זמינות גבוהה ומעבר אוטומטי לגיבוי בעת כשל;

• איזון עומסים של שאילתות SELECT בין צמתים (עותקים משוכפלים משניים עשויים להיות קריאים);

• גיבוי מהעתקים משניים;

• יתירות נתונים. כל עותק משוכפל שומר עותקים של מסד הנתונים של קבוצת הזמינות.

Always On מבוסס על אשכול מעבר לגיבוי בעת כשל של Windows Server (WSFC). WSFC מנטר צמתים של קבוצות זמינות ומספק מעבר אוטומטי לגיבוי בעת כשל. החל מ- MS SQL Server 2017, ניתן להשתמש ב- Always On גם ללא WSFC וגם במארחי Linux. בעת בניית אשכול מבוסס לינוקס, ניתן להשתמש בקוצב לב במקום ב- WSFC.

Always On זמין במהדורת Standard, אך יש לו כמה מגבלות:

• הוא מוגבל לשני עותקים משוכפלים (ראשוניים ומשניים);

• לא ניתן להשתמש בעותק המשני לקריאת נתונים;

• לא ניתן להשתמש בעותק המשני לגיבוי MS SQL;

• רק מסד נתונים אחד לכל קבוצת זמינות נתמך.

אין הגבלות במהדורת Enterprise.
בואו נבחן את התנאים.

• קבוצת הזמינות Always On היא קבוצה של עותקים משוכפלים ומסדי נתונים;

• עותק משוכפל הוא מופע של SQL Server בקבוצת הזמינות. העתק עשוי להיות ראשוני או משני. כל עותק משוכפל עשוי להכיל מסד נתונים אחד או יותר.

Always On מבוסס על WSFC. כל צומת קבוצת זמינות חייב להיות חבר באשכול מעבר לגיבוי בעת כשל של Windows. לכל מופע של SQL Server יכולות להיות קבוצות זמינות מרובות. כל קבוצת זמינות עשויה לכלול עד 8 עותקים משוכפלים משניים.

אם עותק משוכפל ראשי נכשל, האשכול יצביע עבור עותק ראשי חדש, ו- Always On יהפוך את אחד העותקים המשוכפלים המשניים לעותק ראשי. מכיוון שמשתמשים מתחברים למאזין (כתובת IP מיוחדת של אשכול ושם ה- DNS המתאים) בעת עבודה עם Always On, ניתן יהיה להפעיל שוב שאילתות כתיבה. המאזין אחראי גם על איזון שאילתות SELECT בין עותקים משוכפלים משניים.

קביעת תצורה של אשכול מעבר לגיבוי בעת כשל של Windows עבור הקבוצה 'זמינות תמידית'

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

הנה התצורה שלי:

• 2 מחשבים וירטואליים שבהם פועל Windows Server 2019

• 2 מופעים של SQL Server 2019 Enterprise

• שמות המארחים של הצמתים הם testnode1 ו- testnode2. שמות המופעים של SQL Server הם node1 ו- node2.

הוסף את התפקיד קיבוץ באשכולות של מעבר לגיבוי בעת כשל באמצעות מנהל השרת או התקן אותו באמצעות PowerShell:

Install-WindowsFeature -Name Failover-Clustering -IncludeManagementTools

ההתקנה היא אוטומטית, ואתה לא צריך להגדיר שום דבר עדיין. הפעל את יישום ה- Snap-in 'מנהל אשכולות מעבר לגיבוי בעת כשל' (

FailoverClusters.SnapInHelper.msc

) וליצור אשכול חדש.

הוסף את שמות המארחים שברצונך לצרף לאשכול שלך.

לאחר מכן האשף מציע לקחת כמה בדיקות. לשם כך, בחר את הפריט הראשון.

ציין את שם האשכול, בחר רשת וכתובת IP של אשכול. שם האשכול יופיע ב- DNS באופן אוטומטי; אין צורך ליצור רשומת DNS באופן ידני. במקרה שלי, שם האשכול הוא ClusterAG.

בטל את סימון האפשרויות הוסף את כל שטח האחסון הזכאי לאשכול מכיוון שנוכל להוסיף דיסקים מאוחר יותר.

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

בחר באפשרות המניין החוקי.

לאחר מכן בחר את סוג העד: עד לשיתוף קבצים.

ציין נתיב UNC לתיקיה המשותפת. צור את הספרייה בעצמך. הוא חייב להיות קיים בשרת מחוץ לאשכול מעבר לגיבוי בעת כשל.

בעת קביעת התצורה של האשכול, ייתכן שתראה את השגיאה הבאה:

There was an error configuring the file share witness. Unable to save property changes for File Share Witness. The system cannot find the file specified.

סביר להניח שלחשבון משתמש, שתחתיו פועל האשכול, אין הרשאות NTFS כדי לגשת לתיקיה המשותפת. כברירת מחדל, האשכול פועל תחת חשבון משתמש מקומי. באפשרותך להעניק הרשאות בתיקיה לכל מחשבי האשכולות או לשנות את החשבון עבור שירות האשכולות ולהעניק לו את ההרשאות הרלוונטיות.

תצורת האשכול הבסיסית של מעבר לגיבוי בעת כשל של Windows הסתיימה.

קביעת תצורה של הקבוצה 'זמינות תמיד' ב- MS SQL Server

לאחר התקנת מופע טיפוסית של SQL Server, באפשרותך להפוך קבוצות זמינות תמיד לזמינות ולקבוע את תצורתן. הפוך אותם לזמינים במאפייני המופע של SQL Server Configuration Manager. כפי שניתן לראות בצילום המסך, SQL Server כבר זיהה שהוא שייך לאשכול WSFC. סמן את הפוך קבוצות זמינות תמיד לזמינות והפעל מחדש את שירות המופעים של MSSQL. בצע את אותו הדבר עבור המופע השני.

הפעל את SQL Server Management Studio, התחבר למחשב המארח שלך, לחץ על תמיד בזמינות גבוהה והפעל את אשף קבוצת זמינות חדשה.

ציין שם עבור קבוצת הזמינות 'פועל תמיד' ובחר זיהוי תקינות ברמת מסד הנתונים. באמצעות אפשרות זו, Always On יוכל לזהות מתי מסד נתונים אינו תקין.

בחר מסדי נתונים של SQL Server כדי להוסיף לקבוצת הזמינות 'תמיד פועל'.

לחץ על הוסף עותק משוכפל וחבר את שרת SQL השני. כך ניתן להוסיף עד 8 שרתים.

• תפקיד ראשוני הוא תפקיד משוכפל עד ליצירת קבוצה. זה יכול להיות ראשי או משני;

• מעבר אוטומטי לגיבוי בעת כשל - אם מסד נתונים הופך ללא זמין, Always On יעביר את התפקיד הראשי לעותק משוכפל אחר. בדוק פריט זה;

• מצב זמינות מאפשר בחירה באפשרות Synchronous Commit או Asynchronous Commit. אם תבחר במצב סינכרוני, הטרנזקציות המגיעות לעותק המשוכפל הראשי יישלחו לכל שאר העותקים המשוכפלים המשניים עם המצב הסינכרוני. העותק המשוכפל הראשי מסיים את העסקה רק לאחר שעותקים משוכפלים אחרים כתבו אותה בדיסק. לפיכך, אובדן נתונים מסולק אם ההעתק הראשי נכשל. במצב אסינכרוני, העותק המשוכפל הראשי כותב שינויים באופן מיידי מבלי להמתין לתגובה של עותקים משוכפלים אחרים.

• משני קריא הוא פרמטר המאפשר להפעיל שאילתות SELECT כנגד עותקים משוכפלים משניים. אם הערך הוא כן, לקוחות יוכלו לקבל גישה לקריאה בלבד גם אם הם מתחברים ללא

  ApplicationIntent=readonly

• משניות מסונכרנות נדרשות לביצוע הוא מספר העותקים המשוכפלים המשניים המסונכרנים לסיום העסקה. הגדר אותו בהתאם למספר המשוכפלים, אני אגדיר אותו ל -1.

אל תערוך דבר בכרטיסיה נקודת קצה.

בכרטיסיה העדפות גיבוי, באפשרותך לבחור מהיכן יבוצעו הגיבויים. השאר את הגדרות ברירת המחדל כאן: מעדיף משני.

ציין את השם, היציאה וכתובת ה- IP של מאזין קבוצת הזמינות.

השאר את הגדרות הניתוב לקריאה בלבד ללא שינוי.

בחר את סוג הסינכרון המשוכפל. אני משאיר את הפריט הראשון (זריעה אוטומטית) מסומן.

לאחר מכן יש לאמת את ההגדרות שלך. אם אין שגיאות, לחץ על סיום כדי להחיל את השינויים.

במקרה שלי, כל הבדיקות היו מוצלחות, אבל בשלב התוצאות לאחר ההתקנה, האשף הראה שגיאה של יצירת מאזין קבוצת זמינות. השגיאה EVENTID 1194 הופיעה ביומני האירועים של האשכול:

Cluster network name resource failed to create its associated computer object in the domain.

משמעות הדבר היא שלאשכול אין מספיק הרשאות ליצירת מאזין. התיעוד מציין כי זה מספיק כדי להעניק הרשאה ליצור אובייקטים מסוג מחשב לאובייקט של אשכול שלך. קל יותר לעשות זאת באמצעות הקצאת הרשאות ב- AD (או מהירה, אך הגרסה הלא מאובטחת היא הוספה זמנית של אובייקט CLUSTERAG$לקבוצה Domain Admins).

מכיוון שיצרתי את קבוצת הזמינות, אך לא את המאזין, הוספתי אותה ידנית. פתחו את התפריט תלוי ההקשר של קבוצת הזמינות שלכם ולחצו על 'הוסף מאזין'.

ציין את כתובת ה- IP, היציאה ושם ה- DNS של המאזין.

ודא שהמאזין הופיע במקטע מאזינים של קבוצת זמינות בקבוצה תמיד פועל.

לפיכך, השלמת את התצורה הבסיסית של קבוצת זמינות תמיד פועל.

SQL Server פועל תמיד: בדיקת יכולת הפעלה ומעבר לגיבוי בעת כשל

בואו נסתכל על לוח המחוונים של קבוצת הזמינות (הצג לוח מחוונים).

זה בסדר, הקבוצה נוצרה ועובדת.

בוא ננסה להפוך את node2 למופע ראשי באופן ידני. לחץ באמצעות לחצן העכבר הימני על קבוצת הזמינות ובחר מעבר לגיבוי בעת כשל.

שים לב לערך במוכנות למעבר לגיבוי בעת כשל. המשמעות של היעדר אובדן נתונים היא שלא יאבדו נתונים.

התחבר לצומת2.

לחץ על סיום.

ודא ש- node2 הפך לעותק המשוכפל הראשי (מופע ראשי) בקבוצת הזמינות.

ודא שהמאזין פועל כראוי. ציין את שם ה- DNS של המאזין ואת היציאה כשהם מופרדים באמצעות פסיק ב- SSMS:

ag1-listener-1,1445

הפעל פשוט הוספה, בחירה ועדכון של שאילתות SQL למסד הנתונים שלך.

לאחר מכן בדוק את מעבר לגיבוי בעת כשל אוטומטי של העותק המשוכפל הראשי. פשוט להרוג את התהליך sqlservr.exe על TESTNODE2.

בדוק את מצב קבוצת הזמינות בצומת הנותר: TESTNODE1\NODE1.

האשכול שינה באופן אוטומטי את המצב testnode1\node1 לראשי מאז testnode2\node2 הפך ללא זמין.

בדוק את מצב המאזין כאשר לקוחות ישתמשו בו כדי להתחבר.

במקרה שלי, התחברתי למאזין בהצלחה, אבל כשניסיתי לגשת למסד הנתונים, קיבלתי את השגיאה הבאה:

Unable to access database 'TestDatabase' because it lacks a quorum of nodes for high availability. Try the operation again later.

השגיאה הופיעה עקב האפשרות נדרשים משניים מסונכרנים ל- Commit . מאחר שהגדרנו את הערך שלו ל- 1 בעת קביעת תצורתו, Always On אינו מאפשר לו להתחבר למסד הנתונים, מכיוון שנותר לנו רק עותק משוכפל ראשי אחד.

הגדר את הערך ל- 0 ונסה להפעיל שוב את השאילתה.

Testnode1 שמר על מצב המופע הראשי, בעוד testnode2 הפך למשני. הנתונים ששינינו ב- testnode1 כאשר testnode2 היה כבוי סונכרנו בהצלחה לאחר הפעלת המחשב.

לכן, וידאנו שהכל עובד כראוי והנתונים יהיו זמינים לקריאה/כתיבה במקרה של כשל קריטי.

באפשרותך להגדיר בקלות קבוצות זמינות של Always On. אם ברצונך לבנות פתרון מעבר לגיבוי בעת כשל מבוסס SQL Server, קבוצות הזמינות ינהלו אותו היטב.