בדף הזה מוסבר איך להשתמש ברפליקות לקריאה בלבד באזורים שונים (רפליקות שנוצרו באזור שונה מזה של המכונה הראשית) ואיך להעלות אותן בדרגה, לצורך מיגרציה אזורית או תוכנית התאוששות מאסון (DR).
סקירה כללית
יש שני תרחישים נפוצים לקידום של רפליקות באזורים שונים:
- העברה אזורית: העברה מתוכננת של מסד נתונים לאזור אחר.
- תוכנית התאוששות מאסון (DR): העברת מסד נתונים לאזור אחר במקרה שהאזור הראשי לא זמין.
בשני תרחישי השימוש צריך להגדיר רפליקציה בין אזורים ואז לקדם את הרפליקה. ההבדל העיקרי ביניהם הוא אם קידום הרפליקה מתוכנן (במקרה של העברה אזורית) או לא מתוכנן (נדרשת יתירות כשל לאזור של הרפליקה כדי להמשיך בפעולות כי המכונה הראשית לא זמינה).
העברה אזורית
אתם יכולים להשתמש ברפליקה באזור אחר כדי להעביר את מסד הנתונים לאזור אחר עם זמן השבתה מינימלי. הרעיון הכללי הוא ליצור רפליקה באזור אחר, להמתין עד שהרפליקציה תתעדכן, לקדם אותה ואז להפנות את הלקוחות למכונה שקודמה.
השלבים לקידום זהים לקידום רפליקה באותו אזור. פועלים לפי ההוראות האלה כדי לוודא שבמכונה החדשה שקודמה יש את כל הטרנזקציות שבוצעו במכונה הראשית המקורית. אחרי שקידמתם את הרפליקה ואימתם שהמכונה החדשה שקודמה פועלת, עדכנו את כל לקוחות מסד הנתונים כדי להתחבר למכונה החדשה.
תוכנית התאוששות מאסון (DR)
אפשר להשתמש ברפליקות באזורים שונים כחלק מתוכנית התאוששות מאסון (DR). אתם יכולים לקדם רפליקה בין אזורים כדי להעביר את הגיבוי לאזור אחר, אם האזור של המכונה הראשית לא זמין למשך זמן רב.
מידע נוסף על תוכנית התאוששות מאסון (DR) מופיע במאמר מידע על תוכנית התאוששות מאסון (DR) ב-Cloud SQL.
תוכנית התאוששות מאסון (DR) מתקדמת
אם אתם משתמשים במהדורת Cloud SQL Enterprise Plus, אתם יכולים ליצור רפליקה מדורגת ולהשתמש בה כרפליקה של תוכנית התאוששות מאסון (DR) לתוכנית התאוששות מאסון מתקדמת. ב-DR מתקדם, מבצעים מעבר לגיבוי בעת כשל של רפליקה כדי להחליף את המכונה הראשית ברפליקת ה-DR הייעודית. המופע הראשי הישן הופך לרפליקה של הרפליקה של ה-DR שקודמה. אפשר לבצע מעבר לגיבוי בעת כשל של רפליקה רק לרפליקת ה-DR הייעודית. עדיין אפשר לקדם רפליקות לקריאה בלבד אחרות בלי יתירות כשל.
כדי להחזיר את הפריסה למצב המקורי אחרי יתירות כשל של רפליקה בלי לאבד נתונים, אתם יכולים לבצע מעבר. מכיוון שהמכונה הראשית הישנה היא רפליקה של המכונה הראשית החדשה, אפשר להחליף שוב את התפקידים כדי לשחזר את המכונה הראשית הישנה.
מידע נוסף זמין במאמר תוכנית התאוששות מאסון (DR) מתקדמת.
אימות הקריטריונים ליתירות כשל
מכיוון שהרפליקציה היא אסינכרונית, כשמתרחשת הפסקה זמנית בפעילות באזור ומנסים לבצע מעבר לגיבוי בעת כשל, יכול להיות שחלק מהעסקאות האחרונות שבוצעו בשרת הראשי יאבדו (לא תתבצע רפליקציה שלהן לרפליקה). בכל פעם שמכונה ראשית לא זמינה, השלבים הבאים מראים (1) איך לקבוע את כמות הנתונים, אם יש כאלה, שאולי אבדו במהלך יתירות הכשל בין האזורים, ו-(2) איך לוודא שהרפליקה שקודמה משקפת כמה שיותר פעולות כתיבה אחרונות.
לפני שבודקים את זמן האחזור של הרפליקציה או מקדמים רפליקה, צריך לוודא את סטטוס הרפליקציה של הרפליקה באמצעות בדיקת המדד Replication state (cloudsql.googleapis.com/database/replication/state) בדף Overview של מכונת הרפליקה במסוף Google Cloud :
- במהלך הפסקה ראשית: המדד עשוי לדווח על
ErrorאוStopped. זה מצביע על כך שהרפליקציה הופסקה בגלל ההפסקה. כל הטרנזקציות שבוצעו במכונה הראשית אחרי שהרפליקציה הופסקה יאבדו כשתקדמו את הרפליקה. - במהלך פעולות רגילות (העברה או יתירות כשל מתוכננת): מוודאים שהמדד מדווח על
Running. אם המצב הואErrorאוStopped, הרפליקה לא מקבלת עדכונים מהמכונה הראשית. קידום של רפליקה במצב הזה גורם לאובדן נתונים.
אתם יכולים לבדוק את סטטוס הרפליקציה של הרפליקה באמצעות לוח הבקרה Always On Availability Group ב-SQL Server Management Studio (SSMS), או באמצעות כלי אחר. למידע נוסף על השימוש ב-Transact-SQL:
- Always On Availability Groups Dynamic Management Views - Functions
- sys.dm_hadr_availability_group_states
- sys.dm_hadr_availability_replica_states
קידום של עותק לקריאה בלבד
אחרי שמוודאים שהקריטריונים ליתירות כשל מתקיימים, אפשר לקדם את אחת מהרפליקות למכונה עצמאית שניתן לכתוב בה. לצורך המחשה, נבחן את התרחיש הבא:
- באזור א' (us-central1) יש מכונה ראשית בזמינות גבוהה (db-a-0)
- באזור ב' (us-west1) יש רפליקה חוצת-אזורים בזמינות גבוהה (db-b-1) של db-a-0
- באזור ג' (us-east1) יש רפליקה חוצת-אזורים (db-c-1) של db-a-0
אתם יכולים לבחור לקדם את db-b-1 באזור B כדי שיהפוך למכונה עצמאית שניתן לכתוב בה.
הוראות מפורטות זמינות במאמר קידום רפליקה.
מוודאים שסוג המכונה מתאים
כדי לוודא שסוג המכונה של המכונה החדשה שקודמה מתאים לעומס העבודה שלה, עוקבים אחרי המדדים במכונה, כמו השימוש במעבד (CPU) והשימוש בזיכרון. אם המכונה החדשה שקודמה קטנה מהמכונה הראשית הקודמת, מומלץ לשנות את הגודל של המכונה שקודמה כך שיתאים למכונה הראשית הקודמת, כדי שהיא תוכל להתמודד עם אותו עומס.
הפעלת זמינות גבוהה למכונה שקודמה
במקרה של הגדרת תוכנית התאוששות מאסון (DR), מומלץ להגדיר את הרפליקה שאתם מתכוונים לקדם כרפליקה בזמינות גבוהה. לחלופין, מגדירים את המכונה שקודמה לאחרונה כזמינות גבוהה. אם לא תגדירו את העותק לקריאה בלבד עם זמינות גבוהה, תוכלו להגדיר את המכונה עם זמינות גבוהה אם וכאשר תקדמו אותה.
כשמקדמים עותקי Replica לקריאה בלבד, הם מוגדרים אוטומטית עם גיבויים. הגדרת רפליקה לקריאה בלבד לזמינות גבוהה מתבצעת באותו אופן כמו במכונה הראשית. מידע נוסף זמין במאמר הגדרת המכונה לזמינות גבוהה.
יצירה מחדש של רפליקות נוספות
אם אתם מקדמים רפליקה כדי שתהפוך למכונה ראשית, אתם צריכים ליצור מחדש את כל הרפליקות האחרות של המכונה הראשית הקודמת. לדוגמה, נניח שהגדרתם את התצורה שצוינה למעלה ומופיעה כאן שוב:
- באזור א' (us-central1) יש מכונה ראשית בזמינות גבוהה (db-a-0)
- באזור ב' (us-west1) יש רפליקה חוצת-אזורים (db-b-1) של db-a-0
- באזור ג' (us-east1) יש רפליקה חוצת-אזורים (db-c-1) של db-a-0
אם המכונה הראשית (db-a-0) לא זמינה, אפשר לקדם את הרפליקה באזור B כדי שתהפוך למכונה הראשית. כדי שיהיו שוב רפליקות נוספות באזורים A ו-C, צריך למחוק את המכונות הישנות (המכונה הראשית הקודמת ב-A והרפליקה ב-C) וליצור רפליקות חדשות לקריאה בלבד מהמכונה הראשית החדשה ב-B.
ההגדרות שיתקבלו:
- לאזור א' (us-central1) יש עכשיו רפליקה חוצת-אזורים (db-a-1)
- באזור ב' (us-west1) נמצא עכשיו המכונה הראשית (db-b-1)
- לאזור ג' (us-east1) יש עכשיו רפליקה חדשה בין אזורים (db-c-2)