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

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

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

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

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

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

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

התחלת מעבר ידני לגיבוי מאפשרת לכם לבדוק איך האפליקציה מגיבה למעבר לגיבוי. הידע הזה יכול להבטיח תהליך מעבר לגיבוי (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 מציין כמה בייטים נשארו להעתקה ברפליקה לפני שהגיבוי של השרת הראשי יסתיים. יכול להיות שתבחינו בעלייה בבייטים שממתינים להעתקה, כי המערכת מעתיקה את הנתונים מהשרת הראשי לרפליקה במהלך יתירות כשל. אם יתירות הכשל מופעלת בגלל שגיאת חומרה, יכול להיות שתראו ערך ריק ב-in bytes pending replication (בייטים בהמתנה לרפליקציה) כי לא ניתן היה לקבל את ערך ההיסט עד שהשגיאה במארח תוקנה והרפליקה של העותק החדש תוקנה משגיאת המארח.

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

אפשר גם להיכנס ל-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 יהיה נמוך ככל האפשר.

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

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

• אם מופע 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. כדי לשלב סדרות זמן, משתמשים בתפריטים ברכיב הצבירה. לדוגמה, כדי להציג את ניצול המעבד (CPU) של המכונות הווירטואליות לפי האזור שלהן, מגדירים את התפריט הראשון ל-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 מציינת את האזור שבו המערכת הקצתה במקור את צומת הרפליקה. בכל פעם שמתרחש מעבר לגיבוי (failover), השרת הראשי והרפליקה עוברים בין שני האזורים האלה. עם זאת, האזורים שמשויכים ל-locationId ול-alternativeLocationId לא משתנים.