מידע על מעבר ידני לגיבוי (failover)

בדף הזה מופיעה סקירה כללית על מעבר ידני לגיבוי בעת כשל ב-Memorystore for Redis. כדי ללמוד איך לבצע יתירות כשל, ראה הפעלת יתירות כשל ידנית.

מהו מעבר ידני לגיבוי?

מכונה של Memorystore for Redis ברמה רגילה משתמשת בצומת משוכפל כדי לגבות את הצומת הראשי. יתירות כשל רגילה מתרחשת כשהצומת הראשי הופך ללא תקין, וכתוצאה מכך הרפליקה מוגדרת כראשי החדש. העברה ידנית לגיבוי שונה מהעברה רגילה לגיבוי כי אתם יוזמים אותה בעצמכם. מידע נוסף על אופן השכפול ב-Memorystore for Redis זמין במאמר בנושא זמינות גבוהה.

למה צריך להפעיל מעבר ידני לגיבוי?

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

מצב הגנה על נתונים (אופציונלי)

יש שני מצבים זמינים להגנה על נתונים:

• מצב limited-data-loss (ברירת מחדל).
• force-data-loss מצב.

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

gcloud redis instances failover INSTANCE_NAME --data-protection-mode=limited-data-loss

או

gcloud redis instances failover INSTANCE_NAME --data-protection-mode=force-data-loss

איך פועלים מצבי הגנה על נתונים

במצב limited-data-loss, המערכת מצמצמת את אובדן הנתונים על ידי בדיקה שההפרש בנתונים בין השרת הראשי לבין העותק המשוכפל קטן מ-30MB לפני הפעלת המעבר לגיבוי. ההיסט בשרת הראשי גדל בכל בייט של נתונים שצריך לסנכרן עם העותקים המשוכפלים שלו. במצב limited-data-loss, המעבר לגיבוי יבוטל אם ההפרש הגדול ביותר בהיסט בין השרת הראשי לבין כל עותק משוכפל הוא 30MB או יותר. אם אתם מוכנים לסבול אובדן נתונים גדול יותר ורוצים לבצע את המעבר לגיבוי באופן אגרסיבי, נסו להגדיר את מצב הגנת הנתונים לforce-data-loss.

מצב force-data-loss משתמש בשרשרת של אסטרטגיות יתירות כשל כדי לבצע את יתירות הכשל באופן אגרסיבי. הוא לא בודק את הדלתא של ההיסט בין השרת הראשי לבין הרפליקות לפני שהוא מתחיל את יתירות הכשל. יכול להיות שתאבדו יותר מ-30MB של שינויים בנתונים.

המדד Bytes pending replication

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

אפשר לגשת למדד הזה במסוף Google Cloud בדף פרטי המופע. כדי להציג את דף הפרטים של המופע, לוחצים על מזהה המופע בדף רשימת המופעים בפרויקט.

לחלופין, אפשר להיכנס אל Metrics Explorer של הפרויקט ולחפש את המדד redis.googlapis.com/replication/offset_diff.

מתי כדאי להפעיל מעבר ידני לגיבוי

מעבר ידני לגיבוי באמצעות מצב ההגנה limited-data-loss שמוגדר כברירת מחדל מצליח רק אם המדד bytes pending replication קטן מ-30MB. אם אתם רוצים להריץ מעבר לגיבוי ידני עם bytes pending replication גבוה מ-30MB, אתם צריכים להשתמש במצב ההגנה force-data-loss.

אם אתם מנסים לשמור כמה שיותר נתונים, כדאי להפסיק באופן זמני את הכתיבה של האפליקציה למופע Redis, ולהמתין עד שהמדד bytes pending replication יהיה נמוך ככל האפשר.

בעיות אפשריות שחוסמות מעבר ידני לגיבוי

• הפעלת מעבר ידני לגיבוי במקרים של כשל במופע ברמת Basic לא עובדת כי למופעים ברמת Basic אין רפליקות שאליהן המערכת יכולה לעבור במקרים של כשל.

• אם מופעלת במופע Redis שלכם פעולת מעבר ידנית לגיבוי עם אובדן נתונים מוגבל, והמופע לא תקין, הפעולה תיכשל כי היא נחסמת כדי למזער את אובדן הנתונים.

• אם מריצים סקריפט Lua שפועל ללא הגבלת זמן, צריך להשתמש ב-force-data-loss כדי להתחיל מעבר לגיבוי. במצב כזה, פעולת מעבר לגיבוי במקרה של כשל עם אובדן נתונים מוגבל לא תושלם בהצלחה.

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

חיבור לאפליקציית לקוח

כשצומת ראשי עובר אוטומטית לצומת משוכפל, החיבורים הקיימים ל-Memorystore for Redis נסגרים. עם זאת, כשמתחברים מחדש, האפליקציה מופנית אוטומטית לצומת הראשי החדש באמצעות אותו מחרוזת חיבור או כתובת IP.

אימות של מעבר ידני לגיבוי

כדי לוודא שפעולת מעבר ידנית לגיבוי הצליחה, אפשר להשתמש במסוףGoogle Cloud או ב-gcloud.

Google Cloud אימות במסוף

לפני שמתחילים בהעברה ידנית לגיבוי, עוברים אל דף רשימת המכונות של Memorystore for Redis ולוחצים על שם המכונה.

בכרטיסייה Configuration (הגדרה), לצד Primary Location (המיקום הראשי), אפשר לראות באיזה אזור נמצא הצומת הראשי. רושמים את האזור. אחרי שתשלימו את המעבר הידני לגיבוי, כדאי לחזור לדף הזה כדי לוודא שהצומת הראשי עבר לאזורים אחרים.

אימות ב-Cloud Monitoring

כדי לראות את המדדים של משאבים שבמעקב באמצעות Metrics Explorer:

1. נכנסים לדף  Metrics explorer במסוף Google Cloud :

   כניסה אל Metrics Explorer

   אם משתמשים בסרגל החיפוש כדי למצוא את הדף הזה, בוחרים בתוצאה שבה הכותרת המשנית היא Monitoring.

2. בסרגל הכלים של מסוף Google Cloud , בוחרים את Google Cloud הפרויקט. בהגדרות של מרכז האפליקציות, בוחרים את הפרויקט המארח של מרכז האפליקציות או את פרויקט הניהול של התיקייה לניהול אפליקציות.
3. ברכיב Metric, מרחיבים את התפריט Select a metric, כותבים Node role בשורת הסינון ומשתמשים בתפריטי המשנה כדי לבחור סוג ספציפי של משאב ומדד:
   1. בתפריט Active resources בוחרים באפשרות Cloud Memorystore Redis.
   2. בתפריט Active metric categories בוחרים באפשרות replication.
   3. בתפריט Active metrics בוחרים באפשרות Node role.
   4. לוחצים על אישור.

4. כדי להוסיף מסננים שמסירים סדרות זמן מתוצאות השאילתה, משתמשים ברכיב Filter.

5. כדי לשלב סדרות עיתיות, משתמשים בתפריטים ברכיב Aggregation. לדוגמה, כדי להציג את ניצול המעבד של המכונות הווירטואליות לפי האזור שלהן, מגדירים את התפריט הראשון ל-Mean ואת התפריט השני ל-zone.

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

6. כדי לראות מכסות ומדדים אחרים שמדווחים על דגימה אחת ליום:
   1. בחלונית Display, מגדירים את Widget type לאפשרות תרשים עמודות אופקי מוערם.
   2. מגדירים את התקופה לשבוע אחד לפחות.

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

gcloud אימות

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

gcloud redis instances describe [INSTANCE_ID] --region=[REGION]

הצומת הראשי נמצא באזור שמסומן בתווית currentLocationId. רושמים את האזור.

אחרי שמבצעים יתירות כשל ידנית, אפשר לוודא שהצומת הראשי עבר לתחום חדש על ידי הפעלת הפקודה gcloud redis instances describe שוב ובדיקה שתחומי currentLocationId השתנו.

בנוסף, התווית locationId מציינת את האזור שבו הקציתם במקור את הצומת הראשי. התווית alternativeLocationId מציינת את האזור שבו המערכת הקצתה במקור את צומת הרפליקה. בכל פעם שמתרחש מעבר לגיבוי, השרת הראשי והרפליקה עוברים בין שני האזורים האלה. עם זאת, האזורים שמשויכים ל-locationId ול-alternativeLocationId לא משתנים.