מידע על תמונות מצב של RDB

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

במאמר ניהול תמונות מצב של RDB מוסבר איך להפעיל, להשבית ולעקוב אחרי תמונות מצב של RDB.

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

מומלץ להשתמש ברמת השירות 'רגילה' כמנגנון העיקרי לזמינות גבוהה (HA). במסלול הרגיל יש מופע עם זמינות גבוהה עם כמה רפליקות, והוא מאפשר שחזור מהיר באמצעות מעבר אוטומטי לגיבוי אם השרת הראשי נכשל. בנוסף, הפעלת תמונות מצב של RDB במופעים של מסלול רגיל מספקת הגנה נוספת מפני כשלים בצמתים.

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

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

סקירה כללית של תמונות מצב של RDB

התכונה 'תמונות מצב של RDB' פועלת באופן הבא:

  • שומר תמונות מצב מלאות של נקודות זמן במרווחי זמן שצוינו על ידי המשתמש באחסון מתמיד.

  • אתם בוחרים את התדירות ואת לוח הזמנים של הצילומים השגרתיים. מרווח הזמן המינימלי בין תמונות הוא 1h והמקסימלי הוא 24h.

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

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

  • לא כרוך בעלות נוספת בחיוב של המופע.

התנהגות נוספת

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

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

מגבלות

  • זמין במכונות של Memorystore for Redis שמשתמשות ב-Redis בגרסה 5.0 ומעלה.

  • אם במופע שלכם יש הרבה מפתחות (כ-200 מיליון או יותר), יכול להיות שצילומי מצב של RDB ושחזורים יהיו איטיים. בנפח המקשים הזה, שרת Redis עצמו יכול להיות צוואר הבקבוק שמאט את הצילומים ואת השחזורים.

תזמון של תמונות מצב של RDB

כשמפעילים תמונות מצב של RDB במהלך יצירת מופע, צריך לציין מרווח זמן בין תמונות המצב. אפשר גם לציין שעת התחלה. ביחד הם מגדירים את התזמון היומי של תמונות המצב. המרווחים שאפשר להגדיר הם 1h,‏ 6h,‏ 12h ו-24h. לדוגמה, אם מגדירים את שעת ההתחלה ל-4:00 ואת המרווח לשעה אחת, הצילומים יתחילו ב-4:00 ביום שבו הם מופעלים, וימשיכו כל שעה לאחר מכן.

אם לא מציינים שעת התחלה, תמונת המצב הראשונה מצולמת בהקדם האפשרי, ומרווח הזמן נשמר. לדוגמה, אם לא מציינים שעת התחלה ומגדירים מרווח של שעה, תמונת המצב יכולה להתחיל ב-6:13 ולהמשיך ב-7:13, ב-8:13 וכן הלאה.

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

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

  • אם יצירת ה-snapshot נכשלת או נמשכת יותר זמן ממרווח הזמן שצוין ליצירת ה-snapshot, ה-snapshot הבא יתחיל מיד אחרי שה-snapshot הנוכחי יסתיים.

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

  • אם צילום מצב כבר מתבצע בזמן שמתאים ללוח הזמנים היומי, צילום המצב הזה יושלם וזמן צילום המצב הבא יחושב רק על סמך המרווח שחלף מאז תחילת צילום המצב האחרון שהושלם בהצלחה.

שינוי לוח זמנים קיים

יכול להיות שתיתקלו בתרחישים שבהם תרצו להשהות באופן זמני את יצירת התמונות של מסד הנתונים של Redis (RDB) לפרק זמן מסוים. יכול להיות שתרצו לעשות את זה כדי לוודא שלא יהיו השפעות על הביצועים במהלך אירועים קריטיים, או כדי להשבית זמנית את הצילומים כדי לפתור בעיות בביצועים.

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

מידע נוסף על שינוי לוחות הזמנים של תמונות המצב זמין במאמר בנושא שינוי לוחות הזמנים של תמונות המצב.

התנהגות השחזור

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

במכונות Redis במסלול הרגיל, המנגנון העיקרי לשחזור הוא מעבר אוטומטי לגיבוי (failover) לרפליקה, ולא טעינה מקובץ snapshot. מכונה במסלול רגיל משוחזרת מתמונת המצב אם השחזור מהרפליקה נכשל.

עקביות הנתונים בשחזור

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

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

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

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

זמן ההתאוששות

המופע לא זמין בזמן השחזור של המופע מתמונת מצב. זמן השחזור תלוי בגודל של תמונת המצב. כדי להבין את זמן ההתאוששות הצפוי, בודקים את המדד RDB recovery remaining time באמצעות Cloud Monitoring במסוף Google Cloud .

הפחתת הסיכון להאטה בהתאוששות

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

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

כשל ביצירת תמונת מצב וכשל בשחזור

התמונה במסגרת לא נשמרה

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

כשל בשחזור

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

שיטות מומלצות

כדי לקבל את התוצאות הכי טובות בגיבוי של המופע באמצעות תמונות מצב של RDB, מומלץ לפעול לפי השיטות המומלצות שמתוארות בהמשך:

ניהול זיכרון

תמונות מצב של RDB משתמשות בתהליך fork ובמנגנון'העתקה בעת כתיבה' כדי לצלם תמונת מצב של המופע. בהתאם לדפוס הכתיבה למופע, הזיכרון בשימוש של המופע יגדל ככל שהדפים שהכתיבה נוגעת בהם יועתקו. במקרה הגרוע ביותר, הזיכרון שבשימוש יכול להיות כפול מגודל הנתונים במופע.

כדי לוודא שלמופע יש מספיק זיכרון כדי להשלים את תמונת המצב, צריך להגדיר את maxmemory-gb ל-80% מהקיבולת של המופע, כך ש-20% יהיו שמורים לתקורה. מידע נוסף זמין במאמר בנושא שיטות מומלצות לניהול זיכרון. התקורה הזו של הזיכרון, בנוסף לתמונות המצב של המעקב, עוזרת לכם לנהל את עומס העבודה כדי ליצור תמונות מצב מוצלחות.

תמונות מצב לא עדכניות

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

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

כדי לעקוב אחרי תמונות מצב לא עדכניות, מגדירים התראה על מדדי תמונת המצב של RDB‏ last_status ושל RDB‏ last_success_age .

שחזור ממושך מתמונת מצב

מומלץ להגדיר התראה למדד redis.googleapis.com/server/uptime כדי לקבל הודעה אם המכונה שלכם לא תהיה זמינה.

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

ההשפעה של תמונות מצב של RDB על הביצועים

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

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

משתמשים בשעת ההתחלה ובמרווח הזמן כדי לתזמן את תמונות המצב לזמנים הנדרשים. לדוגמה, אם עומס העבודה נמוך מאוד בין השעות 1:00 ל-4:00, אפשר להגדיר את שעת ההתחלה ל-3:00 ואת מרווח הזמן ל-24 שעות.

אם המערכת שלכם נתונה לעומס קבוע ונדרשים בה צילומים תכופים של מצב המערכת, כדאי להעריך בקפידה את ההשפעה על הביצועים ולשקול את היתרונות של שימוש בצילומי מצב של RDB עבור עומס העבודה.

מעקב אחרי תמונות מצב

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

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

מעקב אחר ההשפעה על הביצועים

כדי לעקוב אחרי ההשפעה של תמונת מצב על הביצועים של מופע Memorystore, אפשר לעיין במדדים שזמינים דרך Cloud Monitoring, כמו שימוש במעבד, שימוש בזיכרון וכו'. אם הבחנתם בירידה בביצועים, תוכלו להשתמש במדד של תמונת מצב של RDB‏ in_progress כדי לקבוע אם תמונת מצב הייתה בתהליך כשזוהו בעיות בביצועים.

המאמרים הבאים