מעבר לגיבוי (Failover)
אם אשכול Bigtable לא מגיב, השכפול מאפשר לתנועה הנכנסת לעבור לאשכול אחר באותו מופע. המעבר לגיבוי יכול להיות ידני או אוטומטי, בהתאם לפרופיל האפליקציה שבו האפליקציה משתמשת ולאופן שבו פרופיל האפליקציה מוגדר.
בדף הזה מוסבר איך מתבצע מעבר אוטומטי לגיבוי (failover) ואיך מתבצע מעבר ידני לגיבוי במופע שמשתמש בשכפול. איך מנהלים מעבר לגיבוי
לפני שקוראים את הדף הזה, מומלץ לעיין בסקירה הכללית על השכפול ב-Bigtable. מומלץ גם להכיר את אפשרויות הניתוב שזמינות.
מעבר ידני לגיבוי
אם פרופיל אפליקציה משתמש בניתוב לאשכול יחיד כדי להפנות את כל הבקשות לאשכול אחד, אתם צריכים להפעיל שיקול דעת כדי להחליט מתי להתחיל לבצע מעבר לגיבוי לאשכול אחר.
ריכזנו כאן כמה אותות שיכולים להצביע על כך שכדאי לבצע מעבר לגיבוי ולשימוש באשכול אחר:
- האשכול מתחיל להחזיר מספר גדול של שגיאות מערכת זמניות.
- מספר גדול של בקשות מתחילות לחרוג מהזמן שהוקצב להן.
- זמן האחזור הממוצע של התגובה עולה לרמה לא מקובלת.
האותות האלה יכולים להופיע מסיבות שונות, ולכן מעבר אוטומטי לאשכול אחר לא מבטיח פתרון של הבעיה הבסיסית. עוקבים אחרי המופע לפני המעבר לגיבוי ולאחריו כדי לוודא שהמדדים השתפרו.
הוראות להשלמת מעבר ידני לגיבוי זמינות במאמר בנושא השלמת מעבר ידני לגיבוי.
מעבר אוטומטי לגיבוי (failover)
אם פרופיל האפליקציה משתמש בניתוב מרובה אשכולות, Bigtable מטפל במעבר לגיבוי אוטומטית. אם האשכול הקרוב ביותר לא יכול לטפל בבקשה, Bigtable מנתב את התנועה לאשכול הקרוב ביותר שזמין.
מעבר אוטומטי לגיבוי יכול לקרות גם אם אשכול לא זמין לפרק זמן קצר מאוד. לדוגמה, אם Bigtable מעביר בקשה לאחד מהאשכולות, והתגובה מהאשכול הזה איטית מדי או שהוא מחזיר שגיאה זמנית, בדרך כלל Bigtable ינסה שוב את הבקשה באשכול אחר.
אם משתמשים בניתוב בין כמה אשכולות ושולחים בקשה עם מועד אחרון, Bigtable מבצע אוטומטית מעבר לגיבוי בעת הצורך כדי לעמוד במועד האחרון. אם מועד היעד מתקרב והאשכול הראשוני לא שלח תגובה, Bigtable מעביר את הבקשה לאשכול הקרוב הבא. המועד האחרון שאתם מגדירים משפיע על המהירות שבה זה קורה: מועד אחרון קצר יותר מפעיל מעבר לגיבוי מוקדם יותר, בעוד שמועד אחרון ארוך יותר מאפשר יותר זמן לפני המעבר לגיבוי.
חשוב לוודא שהמועד האחרון מאפשר להשלים את בקשת המעבר לגיבוי (failover) בהצלחה באשכול הבא, במיוחד אם האשכול הבא נמצא באזור אחר.
ב-Bigtable נעשה שימוש באלגוריתם פנימי מסוג last write wins כדי לטפל בכל התנגשויות הנתונים שעלולות להתרחש כתוצאה ממעבר לגיבוי (failover) לפני שהשכפול הושלם. פרטים נוספים מופיעים במאמר בנושא פתרון קונפליקטים.
אם אתם משתמשים בשכפול עם ניתוב מרובה אשכולות כדי להשיג זמינות גבוהה (HA) לאפליקציה שלכם, כדאי למקם את שרתי הלקוח או את המכונות הווירטואליות באזור אחד או יותר Google Cloud . ההמלצה הזו רלוונטית גם אם שרת האפליקציות שלכם לא מתארח ב- Google Cloud, כי הנתונים שלכם נכנסים לרשת של Google Cloud דרך האזור Google Cloudהכי קרוב לשרת האפליקציות. כמו בכל בקשה, יתירות כשל מושלם מהר יותר למרחקים קצרים יותר.
הרבה מעברים אוטומטיים לגיבוי הם קצרים כל כך שלא תשימו לב אליהם. אפשר לבדוק את התרשים Automatic Failovers במסוף Google Cloud כדי לראות את מספר הבקשות שהניתוב שלהן השתנה באופן אוטומטי במהלך תקופה מסוימת: פותחים את רשימת המופעים, לוחצים על שם המופע ואז על System insights.