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

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

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

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

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

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

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

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

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

• מצב 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 (בייטים בהמתנה לשכפול) מראה כמה בייטים נשארו לשכפול לפני שהגיבוי של השרת הראשי יסתיים. יכול להיות שתבחינו בעלייה בבייטים שממתינים להעתקה, כי המערכת מעתיקה את הנתונים מהשרת הראשי לשרת המשני במהלך מעבר לגיבוי. אם הגיבוי האוטומטי מופעל בגלל שגיאת חומרה, יכול להיות שתראו ערך ריק ב-in 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 הפרויקט. בהגדרות של App Hub, בוחרים את הפרויקט המארח של App Hub או את פרויקט הניהול של התיקייה שמוגדרת לניהול אפליקציות.
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 לאפשרות Stacked bar chart.
   2. מגדירים את התקופה לשבוע אחד לפחות.

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

gcloud אימות

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

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

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

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

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