בדף הזה מוסבר איך להשתמש ברפליקות לקריאה חוצות אזורים (רפליקות שנוצרו באזור שונה מהאזור של השרת הראשי) ואיך להעלות אותן בדרגה לצורך העברה אזורית או תוכנית התאוששות מאסון (DR).
סקירה כללית
יש שני תרחישים נפוצים לקידום רפליקות חוצות אזורים:
- העברה אזורית: ביצוע העברה מתוכננת של מסד נתונים לאזור אחר.
- תוכנית התאוששות מאסון (DR): מעבר אוטומטי של מסד נתונים לאזור אחר במקרה שהאזור הראשי לא זמין.
בשני תרחישי השימוש האלה צריך להגדיר שכפול בין אזורים ואז לקדם את הרפליקה. ההבדל העיקרי ביניהם הוא אם העלאה בדרגה של הרפליקה מתוכננת (במקרה של העברה אזורית) או לא מתוכננת (נדרש יתירות כשל לאזור של הרפליקה כדי להמשיך את הפעולות כי הראשי הפך ללא זמין).
העברה אזורית
אתם יכולים להשתמש ברפליקה באזור אחר כדי להעביר את מסד הנתונים לאזור אחר עם זמן השבתה מינימלי. הרעיון הכללי הוא ליצור רפליקה באזור אחר, לחכות עד שהרפליקציה תתעדכן, להעלות אותה בדרגה ואז להפנות את הלקוחות למופע החדש שהועלה בדרגה.
השלבים לקידום הם אותם שלבים שנדרשים להעלאה בדרגה של רפליקה באזור מסוים. צריך לפעול לפי ההוראות האלה כדי לוודא שלמופע החדש שהועלה בדרגה יש את כל העסקאות שאושרו במופע הראשי המקורי. אחרי שמעלים את העותק המשוכפל לרמת הפקה ומוודאים שהמופע החדש שקודם פועל, צריך לעדכן את כל לקוחות מסד הנתונים כדי להתחבר למופע החדש.
תוכנית התאוששות מאסון (DR)
אפשר להשתמש בעותקים משוכפלים באזורים שונים כחלק מתוכנית התאוששות מאסון. אתם יכולים לקדם רפליקה בין-אזורית לגיבוי במקרה של כשל באזור של המופע הראשי, אם האזור הזה לא יהיה זמין למשך תקופה ממושכת.
מידע נוסף על תוכנית התאוששות מאסון (DR) זמין במאמר מידע על תוכנית התאוששות מאסון (DR) ב-Cloud SQL.
תוכנית התאוששות מאסון (DR) מתקדמת
אם אתם משתמשים במהדורת Cloud SQL Enterprise Plus, אתם יכולים להגדיר רפליקה לקריאה חוצה אזורים כרפליקה להתאוששות מאסון (DR) לצורך התאוששות מתקדמת מאסון (DR). ב-DR מתקדם, מבצעים יתירות כשל של רפליקה כדי להחליף את המופע הראשי ברפליקת ה-DR המיועדת. המופע הראשי הישן הופך לרפליקה של הרפליקה של DR שקודמה. אפשר לבצע יתירות כשל של רפליקה רק לרפליקת ה-DR שמוגדרת. עדיין אפשר להעלות בדרגה רפליקות לקריאה אחרות בלי יתירות כשל.
כדי להחזיר את ה-Deployment למצב המקורי אחרי יתירות הכשל של הרפליקה ללא אובדן נתונים, אפשר לבצע מעבר גיבוי לשחזור. מכיוון שהמופע הראשי הישן הוא רפליקה של המופע הראשי החדש, אפשר להחליף שוב את התפקידים כדי לשחזר את המופע הראשי הישן.
מידע נוסף זמין במאמר בנושא התאוששות מתקדמת מאסון (DR).
אימות קריטריוני המעבר לגיבוי
מכיוון שהשכפול הוא אסינכרוני, כשמתרחש הפסקת שירות באזור ומנסים לבצע יתירות כשל, יכול להיות שחלק מהעסקאות האחרונות שאושרו בשרת הראשי יאבדו (לא ישוכפלו לרפליקה). בכל פעם שמופע ראשי הופך ללא זמין, השלבים הבאים מראים (1) איך לקבוע את כמות הנתונים, אם יש כאלה, שאולי אבדו במעבר ליתירות כשל בין אזורים, ו-(2) איך לוודא שהרפליקה שקודמה משקפת כמה שיותר פעולות כתיבה מהזמן האחרון.
קודם כל, בודקים את הערך Replication Lag של מופע הרפליקה בלוח הבקרה של המעקב. הערך הזה מציין את הפער בין הרפליקה לבין המופע הראשי שלה, בשניות. הערך של המדד הזה בזמן שקדם לזמן שבו השרת הראשי הפך ללא זמין מציין את חלון הזמן שבו יכול להיות שאבדו טרנזקציות שהועברו לשרת הראשי. לדוגמה, אם הערך של Replication Lag היה 5 שניות, יכול להיות שברפליקה לא יהיו נתונים של פעולות כתיבה שבוצעו בשרת הראשי ב-5 השניות שלפני שהשרת הראשי הפך ללא זמין.
(יכול להיות שנפח הנתונים שאבדו בפועל קטן יותר, כי Replication
Lag כולל גם עסקאות שהתקבלו בהצלחה על ידי הרפליקה אבל עדיין לא הוחלו).
לאחר מכן, מתחברים למופע המשוכפל באמצעות לקוח MySQL על ידי ביצוע ההוראות בדף סטטוס השכפול (בכרטיסייה לקוח MySQL). הוראות לגבי המדדים Master_Log_File, Read_Master_Log_Pos, Relay_Master_Log_File ו-Exec_Master_Log_Pos מוודאים שהרפליקה עיבדה את כל העסקאות שהיא קיבלה מהמקור. כך מוודאים שכאשר הרפליקה מקודמת, היא משקפת את כל העסקאות שהתקבלו לפני שהעותק הראשי הפך ללא זמין.
קידום של עותק לקריאה
אחרי שתקבעו שהקריטריונים למעבר לגיבוי (failover) מתקיימים, תוכלו להפוך אחת מהרפליקות למופע עצמאי שניתן לכתוב בו. לדוגמה, נבחן את התרחיש הבא:
- באזור א' (us-central1) יש מכונה ראשית (db-a-0) עם זמינות גבוהה
- באזור ב' (us-west1) יש רפליקה חוצת-אזורים בזמינות גבוהה (db-b-1) של db-a-0
- באזור C (us-east1) יש רפליקה חוצה-אזורים (db-c-1) של db-a-0
אפשר לקדם את db-b-1 באזור B כך שיהפוך למופע עצמאי עם הרשאות כתיבה.
הוראות מפורטות מופיעות במאמר בנושא קידום רפליקה.
מוודאים שסוג המכונה מתאים
כדי לוודא שסוג המכונה של המכונה החדשה שהועברה לרמת ייצור מתאים לעומס העבודה שלה, עוקבים אחרי מדדים במכונה, כמו שימוש במעבד (CPU) ושימוש בזיכרון. אם המופע החדש שודרג קטן יותר מהמופע הראשי הקודם, מומלץ לשנות את הגודל של המופע ששודרג כך שיתאים למופע הראשי הקודם, כדי שיוכל להתמודד עם אותה כמות של עומס.
הפעלת זמינות גבוהה למופע המקודם
להגדרת תוכנית התאוששות מאסון, מומלץ להגדיר את הרפליקה שרוצים להעלות בדרגה כרפליקה זמינה. לחלופין, אפשר להגדיר את המופע החדש שקודם לדרגה גבוהה כזמינות גבוהה. אם תבחרו שלא להגדיר את העותק לקריאה עם זמינות גבוהה, תוכלו גם להגדיר את המופע עם זמינות גבוהה אם וכאשר תקדמו אותו.
כשמשדרגים רפליקות לקריאה, הגיבויים מוגדרים אוטומטית. ההגדרה של רפליקה לקריאה לצורך זמינות גבוהה מתבצעת באותו אופן כמו בהגדרה של מופע ראשי. מידע נוסף מופיע במאמר בנושא הגדרת המופע לזמינות גבוהה.
יצירה מחדש של רפליקות נוספות
אם מקדמים רפליקה כדי שתהפוך למכונה ראשית, צריך ליצור מחדש את כל הרפליקות האחרות של המכונה הראשית הקודמת. לדוגמה, נניח את ההגדרה שמופיעה למעלה וחוזרת כאן:
- באזור א' (us-central1) יש מכונה ראשית (db-a-0) עם זמינות גבוהה
- באזור B (us-west1) יש רפליקה חוצת-אזורים (db-b-1) של db-a-0
- באזור C (us-east1) יש רפליקה חוצה-אזורים (db-c-1) של db-a-0
אם המופע הראשי (db-a-0) לא זמין, אפשר להעלות בדרגה את הרפליקה באזור ב' כמופע הראשי. כדי להוסיף שוב רפליקות באזורים א' ו-ג', צריך למחוק את המופעים הישנים (המופע הראשי הקודם באזור א' והרפליקה באזור ג') וליצור רפליקות חדשות לקריאה מהמופע הראשי החדש באזור ב'.
ההגדרה שתתקבל תהיה:
- באזור א' (us-central1) יש עכשיו רפליקה חוצת-אזורים (db-a-1)
- אזור ב' (us-west1) כולל עכשיו את המופע הראשי (db-b-1)
- באזור C (us-east1) יש עכשיו רפליקה חדשה חוצת-אזורים (db-c-2)