ב-Standard Tier של Memorystore for Redis אפשר להרחיב את שאילתות הקריאה של האפליקציה באמצעות רפליקות לקריאה בלבד. אנחנו מניחים שאתם מכירים את היכולות השונות של רמות Redis ב-Memorystore.
רפליקות לקריאה בלבד מאפשרות להגדיל את עומס העבודה של הקריאה על ידי שליחת שאילתות לרפליקות. נקודת קצה לקריאה מסופקת כדי להקל על האפליקציות להפיץ שאילתות בין רפליקות. מידע נוסף זמין במאמר Scaling reads with read endpoint.
במאמר ניהול רפליקות לקריאה בלבד מוסבר איך לנהל מכונה של Redis עם רפליקות לקריאה בלבד.
תרחישים לדוגמה לשימוש ברפליקות לקריאה בלבד
מאגר סשנים, טבלת מובילים, מנוע המלצות ותרחישי שימוש אחרים דורשים שהמכונה תהיה עם זמינות גבוהה. בתרחישים האלה יש הרבה יותר קריאות מאשר כתיבות, ובדרך כלל אפשר לסבול בהם קריאות בעבר. במקרים כאלה, כדאי להשתמש ברפליקות לקריאה בלבד כדי לשפר את הזמינות ואת יכולת ההתאמה לעומס של המכונה.
התנהגות של עותק לקריאה בלבד
- עותקים לקריאה בלבד לא מופעלים כברירת מחדל במכונות במסלול Standard.
- כדי להגן על הנתונים ולספק רמה בסיסית של עמידות, תמונות המצב של RDB מופעלות כברירת מחדל כשיוצרים מכונה של Memorystore for Redis באמצעות מסוף Google Cloud .
- אחרי שמפעילים רפליקות לקריאה במכונה, אי אפשר להשבית אותן במכונה הזו.
- למכונות ברמת Standard יכולות להיות בין רפליקה אחת ל-5 רפליקות לקריאה בלבד.
- נקודת הקצה (endpoint) לקריאה מספקת נקודת קצה אחת להפצת שאילתות בין צומתי רפליקה.
- עותקי ה-Read replica מנוהלים באמצעות רפליקציה אסינכרונית של Redis.
אזהרות ומגבלות
- עותקים לקריאה בלבד נתמכים רק במכונות בגודל של צמתים בנפח של 5GB ומעלה.
- אפשר להפעיל עותקים לקריאה בלבד רק במכונות שמשתמשות בגרסה 5.0 ומעלה של Redis.
- אם אתם מגדירים אזור ואזור חלופי להקצאת צמתים, Memorystore משתמש באזורים האלה לצומת הראשון והשני במכונה. לאחר מכן, Memorystore בוחר את האזורים לכל שאר הצמתים שהוקצו למכונה.
- צריך להקצות למכונה טווח כתובות IP ב-CIDR של
/28או יותר. טווחים גדולים יותר כמו/27ו-/26הם תקינים. טווחים קטנים יותר, כמו/29, לא נתמכים בתכונה הזו.
ארכיטקטורה
כשמפעילים עותקים לקריאה בלבד, מציינים את מספר העותקים שרוצים במכונה. Memorystore מפיץ באופן אוטומטי את הצמתים של הרפליקה הראשית ושל הרפליקה לקריאה בלבד בין האזורים הזמינים.
לכל מכונה יש נקודת קצה ראשית ונקודת קצה לקריאה. נקודת הקצה הראשית תמיד מפנה את התנועה לצומת הראשי, ונקודת הקצה לקריאה מאזנת באופן אוטומטי את העומס של שאילתות הקריאה בין הרפליקות הזמינות. בתרשים, תנועת הקריאה והכתיבה לנקודת הקצה הראשית מוצגת בכחול, ותנועת הקריאה לנקודת הקצה לקריאה ולרפליקות מוצגת בירוק.
שירות המעקב אחרי תקינות המכונה ב-Memorystore for Redis עוקב אחרי המכונה, מזהה כשלים בצומת הראשי, בוחר רפליקה שתהיה הצומת הראשי החדש ומתחיל תהליך אוטומטי של יתירות כשל לצומת הראשי החדש.
מעבר למצב של יתירות כשל במכונות עם רפליקות לקריאה
אם המכונה הראשית נכשלת, שירות המעקב אחרי תקינות המכונה של Memorystore מפעיל את יתירות הכשל, והמכונה הראשית החדשה זמינה גם לקריאה וגם לכתיבה. בדרך כלל, תהליך יתירות הכשל מסתיים תוך פחות מ-30 שניות.
כשמתרחש מעבר לגיבוי בעת כשל, נקודת הקצה הראשית מפנה אוטומטית את התנועה לנקודת הקצה הראשית החדשה, אבל כל החיבורים של הלקוחות לנקודת הקצה הראשית מתנתקים במהלך המעבר לגיבוי בעת כשל. אפליקציות עם לוגיקה של ניסיון חוזר להתחברות יתחברו מחדש באופן אוטומטי ברגע שהמכונה הראשית החדשה תהיה אונליין. חלק מהחיבורים של הלקוח לנקודת הקצה לקריאה בלבד מתנתקים גם מהרפליקה לקריאה בלבד, שמשודרגת לראשית במהלך יתירות כשל. החיבורים לרפליקות שנותרו ממשיכים לפעול במהלך יתירות כשל. בניסיון החוזר, החיבורים מופנים מחדש לרפליקות החדשות.
כשמתרחש מעבר לגיבוי בעת כשל, בגלל האופי האסינכרוני של הרפליקציה, לרפליקות יכול להיות עיכוב שונה ברפליקציה. עם זאת, תהליך יתירות הכשל עושה כמיטב יכולתו כדי לעבור לרפליקה עם העיכוב הקצר ביותר. כך אפשר לצמצם את כמות הנתונים שאובדים ואת הירידה בתפוקת הקריאה במהלך יתירות כשל. המופע הראשי החדש יכול להיות באותו אזור של המופע הראשי הקודם או באזור אחר. הרפליקה שנבחרת להיות הראשית החדשה היא זו שנמצאת באותו אזור כמו הראשית הקודמת, ושיש לה את הפיגור הקטן ביותר. אם לא, רפליקה מאזור אחר יכולה להפוך לראשית החדשה.
מכיוון שהרפליקציה היא אסינכרונית, תמיד יש אפשרות לקרוא נתונים לא עדכניים במהלך מעבר לגיבוי בעת כשל. בנוסף, בזמן שהמכונה הראשית החדשה מקודמת, יכול להיות שחלק מהכתיבות למכונה יאבדו. האפליקציות צריכות להיות מסוגלות להתמודד עם ההתנהגות הזו.
Redis עושה כמיטב יכולתו כדי למנוע מהרפליקות האחרות לדרוש סנכרון מלא במהלך יתירות כשל, אבל זה יכול לקרות במקרים נדירים. סנכרון מלא יכול להימשך בין כמה דקות לשעה, בהתאם לקצב הכתיבה ולגודל של קבוצת הנתונים שמשוכפלת. במהלך הזמן הזה, הרפליקות שעוברות סנכרון מלא לא זמינות לקריאה. אחרי שהסנכרון מסתיים, אפשר לגשת לרפליקות לקריאה.
מצבי כשל של עותקים לקריאה בלבד
במכונות עם רפליקות לקריאה בלבד יכולות להיות תקלות שונות ומצבים לא תקינים שמשפיעים על האפליקציה. ההתנהגות משתנה בהתאם למספר הרפליקות של המכונה – אחת, או שתיים או יותר. בקטע הזה מתוארים כמה מצבי כשל נפוצים וההתנהגות של המכונה במצבים האלה.
הרפליקה לא זמינה
אם רפליקה נכשלת מסיבה כלשהי, היא מסומנת כלא זמינה וכל החיבורים אליה מסתיימים אחרי זמן קצוב מסוים. אחרי שהרפליקה משוחזרת, חיבורים חדשים מנותבים לרפליקה ששוחזרה. הזמן שנדרש לשחזור רפליקה משתנה בהתאם למצב הכשל.
אם יש כשל באזור, Memorystore for Redis לא משחזר את הרפליקה עד שהאזור הופך לזמין.
כשל באזור
אם האזור שבו נמצא המכונה הראשית נכשל, המכונה הראשית עוברת באופן אוטומטי למצב של מעבר לגיבוי בעת כשל (failover) לרפליקה באזור אחר. אם למכונה יש רק רפליקה אחת, נקודת הקצה לקריאה לא זמינה במהלך ההפסקה בשירות באזור. אם למכונה יש יותר מרפליקה אחת, הרפליקות מחוץ לאזור המושפע זמינות לקריאה.
אם האזור שבו נמצאת אחת או יותר מהרפליקות נכשל, הרפליקות האלה לא יהיו זמינות למשך זמן הכשל באזור. אם יש כשל בשני אזורים ויש שתי רפליקות או יותר, הרפליקה עם זמן האחזור הקצר ביותר באזורים שנותרו מקודמת לראשית. כל הרפליקות שנותרו באזורים שלא הושפעו זמינות לקריאה.
מחיצת רשת
מחיצת רשת היא תרחיש שבו הצמתים ממשיכים לפעול אבל לא יכולים להגיע לכל הלקוחות, האזורים או הצמתים האחרים. ב-Memorystore נעשה שימוש במערכת שמבוססת על קוורום כדי למנוע מצמתים מבודדים לשרת פעולות כתיבה. במקרה של חלוקת רשת, כל מכונה ראשית בחלוקת מיעוט מורידה את עצמה בדרגה. המחיצה של הרוב (אם יש כזו) בוחרת ראשי חדש אם עדיין אין לה כזה. רפליקות מבודדות ממשיכות להציג קריאות. עם זאת, יכול להיות שהם לא יהיו עדכניים אם הם לא יוכלו להסתנכרן מהשרת הראשי.
כדי לבדוק אם הקישור לא תקין, עוקבים אחרי המדדים master_link_down_since_seconds ו-offset_diff כדי לזהות צמתים מבודדים.
סנכרון מלא
כשרפליקה מפגרת יותר מדי אחרי הרפליקה הראשית, מופעל סנכרון מלא שמעתיק תמונת מצב שלמה מהרפליקה הראשית לרפליקה. הפעולה הזו יכולה להימשך בין כמה דקות לשעה במקרה הגרוע ביותר. סנכרון מלא לא גורם לכשל במכונה, אבל בזמן הסנכרון המלא, הרפליקה לא זמינה לקריאה, והמכונה הראשית משתמשת יותר במעבד ובניצול זיכרון.
נקודת הקצה הראשית מחזירה את הערך READONLY
יכול להיות שפעולות הכתיבה שלכם לנקודת הקצה הראשית של מכונה של Memorystore for Redis עם רפליקות לקריאה בלבד יקבלו שגיאות -READONLY You can't write against a read
only replica. באופן בלתי צפוי. מומלץ לסגור את החיבורים למכונה וליצור אותם מחדש. ברוב המקרים, הפעלה מחדש של אפליקציית הלקוח יכולה לפתור את הבעיה. אם האפשרויות האלה לא אפשריות או שהבעיה נמשכת, אפשר לפנות לצוות התמיכה של Google Cloud .
הרחבת פעולות הקריאה באמצעות נקודת הקצה לקריאה
עותקים לקריאה בלבד מאפשרים לאפליקציות להרחיב את פעולות הקריאה שלהן על ידי קריאה מהעותקים. אפליקציות יכולות להתחבר לרפליקות לקריאה בלבד דרך נקודת הקצה לקריאה.
לקרוא נקודות קצה
נקודת הקצה לקריאה היא כתובת IP שהאפליקציה מתחברת אליה. הוא מאזן את העומסים של החיבורים באופן שווה בין הרפליקות במכונה. חיבורים לעותק לקריאה בלבד יכולים לשלוח שאילתות קריאה, אבל לא שאילתות כתיבה. לכל מכונה במסלול Standard שמופעלות בה רפליקות לקריאה בלבד יש נקודת קצה לקריאה. הוראות להצגת נקודת הקצה לקריאה של המכונה מפורטות במאמר הצגת מידע על עותק לקריאה בלבד של המכונה.
ההתנהגות של נקודת הקצה לקריאה
- נקודת הקצה לקריאה מפיצה באופן אוטומטי את החיבורים בין כל הרפליקות הזמינות. החיבורים לא מופנים לשרת הראשי.
- רפליקה נחשבת זמינה כל עוד היא יכולה לשרת תנועת לקוחות. הנתון הזה לא כולל מקרים שבהם מתבצע סנכרון מלא של רפליקה עם הרפליקה הראשית שלה.
- רפליקה עם השהיית רפליקציה ארוכה ממשיכה לשרת תנועה. אפליקציות עם נפח כתיבה גבוה יכולות לקרוא נתונים לא עדכניים מרפליקה שמשרתת נפח כתיבה גבוה.
- אם צומת רפליקה הופך לצומת הראשי, החיבורים לצומת הזה מסתיימים והחיבורים החדשים מופנים לצומת רפליקה חדש.
- חיבורים נפרדים לנקודת הקצה לקריאה מטרגטים את אותה רפליקה למשך כל החיבור. חיבורים שונים מאותו מארח לקוח לא בהכרח יטרגטו את אותו צומת רפליקה.
עקביות בקריאה
עותקי ה-Read replica מנוהלים באמצעות שכפול אסינכרוני של OSS Redis מקורי. בגלל האופי של רפליקציה אסינכרונית, יכול להיות שהרפליקה תפגר אחרי המקור. אפליקציות עם כתיבה קבועה שגם קוראות מהרפליקה צריכות להיות מסוגלות לסבול קריאות לא עקביות.
אם האפליקציה דורשת עקביות מסוג "קריאת הכתיבה", מומלץ להשתמש בנקודת הקצה הראשית גם לכתיבה וגם לקריאה. שימוש בנקודת הקצה הראשית מבטיח שפעולות הקריאה תמיד יופנו לנקודת הקצה הראשית. גם במקרה כזה, יכול להיות שיהיו קריאות בעבר אחרי יתירות כשל.
הגדרת TTLs במפתחות בראשי מבטיחה שלא ייקראו מפתחות שפג תוקפם מהראשי או מהרפליקה. הסיבה לכך היא ש-Redis מוודא שלא ניתן לקרוא מפתח שפג תוקפו מהרפליקה.
התנהגות של הפעלת רפליקות לקריאה בלבד במכונה קיימת
הפעלת עותקים לקריאה בלבד היא פעולה בלעדית, כלומר אי אפשר לבצע שינויים אחרים במכונה של פעולת העדכון כחלק מאותה פעולה שמפעילה עותקים לקריאה בלבד.
כדי להפעיל עותקים לקריאה בלבד במכונה קיימת של Redis, צריך להקצות טווח תקין של כתובות IP משניות למיקום הצומת. הטווח חייב להיות בפורמט Classless Inter-Domain Routing (CIDR) בגודל
/28, בלי קשר לגודל של טווח כתובות ה-IP הקיים שהוקצה ל-Memorystore for Redis.- כשמפעילים רפליקות לקריאה במכונה של Redis, צריך לספק את טווח כתובות ה-IP הנוסף. אתם יכולים לבחור טווח ספציפי או לתת ל-Memorystore לבחור טווח באופן אוטומטי.
כתובת ה-IP לקריאה/כתיבה של המכונה לא משתנה כשמפעילים עותקים לקריאה בלבד. כתובת ה-IP של נקודת הקצה לקריאה נמצאת בטווח המקורי שהוקצה למכונה של Memorystore, ולא בטווח הנוסף שציינתם כשהפעלתם את הרפליקות לקריאה בלבד.
כדי למצוא את נקודת הקצה החדשה לקריאה, צפו במידע על הרפליקה לקריאה בלבד של המכונה אחרי שהפעולה להפעלת הרפליקות לקריאה בלבד מסתיימת.
שינוי קנה המידה של מכונה
אתם יכולים לשנות את מספר העותקים לקריאה בלבד של המכונה, וגם את גודל הצומת:
הוראות להוספה ולהסרה של צמתים מופיעות במאמר הוספה או הסרה של צומתי רפליקה ממכונה של Redis.
מומלץ לשנות את קנה המידה של המכונה בתקופה של תנועת קריאה וכתיבה נמוכה, כדי למזער את ההשפעה על האפליקציה.
הוספת רפליקה חדשה יוצרת עומס נוסף על הרפליקה הראשית בזמן שהרפליקה מבצעת סנכרון מלא. כשמוסיפים צמתים, החיבורים הקיימים לא מושפעים או מועברים. כשהרפליקה החדשה זמינה, היא מתחילה לקבל חיבורים מנקודת הקצה ומשרתת קריאות. כשמסירים רפליקה, כל החיבורים הפעילים שמנותבים אליה נסגרים. צריך להגדיר את אפליקציית הלקוח כך שתתחבר מחדש באופן אוטומטי לנקודת הקצה לקריאה, כדי ליצור מחדש את החיבורים לרפליקות שנותרו.
שיטות מומלצות
ניהול זיכרון
ב-Redis, פעולות הכתיבה של הלקוח לא יכולות לחרוג ממגבלת ה-maxmemory של המכונה. עם זאת, תקורה כמו פרגמנטציה, מאגרי שכפול ופקודות יקרות כמו EVAL יכולה להגדיל את ניצול הזיכרון מעבר למגבלה הזו. במקרים כאלה, Memorystore לא מצליח לבצע כתיבה עד שהעומס על הזיכרון פוחת. לפרטים נוספים, ראו שיטות מומלצות לניהול זיכרון.
אם מתבצעת ב-Memorystore פעולת BGSAVE בגלל ייצוא או רפליקציה של סנכרון מלא, ומתרחש מצב OOM, התהליך הצאצא נהרג. במקרה כזה, הפעולה BGSAVE נכשלת ושרת הצומת של Redis נשאר זמין.
כדי להבטיח שכפול ויצירת תמונת מצב בכל מצב, מומלץ לשמור על ניצול זיכרון של פחות מ-50% במהלך פעולות חשובות כמו ייצוא, שינוי קנה מידה וכו'. אפשר להפעיל באופן ידני ייצוא או יתירות כשל כדי לראות את ההשפעה של הפעולות האלה על הביצועים.
ניהול המעבד (CPU)
ב-Memorystore יש מדדים לגבי השימוש ב-CPU ומספר החיבורים לכל צומת. מומלץ להקצות מספיק משאבים כדי שהמערכת תוכל להתמודד עם אובדן של אזור זמינות אחד. היעד האידיאלי עשוי להשתנות בהתאם למספר הרפליקות ולדפוסי השימוש, אבל נקודת התחלה טובה היא לשמור על שימוש במעבד (CPU) של הרפליקה מתחת ל-50%.
יכול להיות שצמתים מסוימים יחוו שימוש גבוה אם דפוסי השימוש של הלקוח לא מאוזנים, או אם פעולות של יתירות כשל גורמות לחלוקת חיבורים לא מאוזנת. במקרה כזה, מומלץ לסגור מדי פעם את החיבורים כדי לאפשר ל-Memorystore לאזן מחדש את החיבורים באופן אוטומטי. Memorystore לא מאזן מחדש חיבורים פתוחים.
ניהול יתרת החיבורים
בכל פעם שהחיבורים של צומת נסגרים, הלקוחות צריכים להתחבר מחדש, בדרך כלל על ידי הפעלת חיבור אוטומטי מחדש בספריית הלקוח שבחרתם. כשהצומת מופעל מחדש, החיבורים הקיימים לא מנותבים מחדש, אבל חיבורים חדשים מנותבים לצומת החדש. לקוחות יכולים לנתק חיבורים מדי פעם כדי לוודא שהם מאוזנים בין הצמתים הזמינים.
ניהול השהיית הרפליקציה
יכול להיות שהרפליקות יפגרו אחרי המקור, במיוחד כשקצב הכתיבה גבוה מאוד. במקרים כאלה, הרפליקה ממשיכה להיות זמינה לקריאה. במצב כזה, הקריאות מהרפליקה יכולות להיות לא עדכניות, והאפליקציה צריכה להיות מסוגלת להתמודד עם זה, או שצריך לטפל בקצב הכתיבה הגבוה.
הפעלת עותקים לקריאה בלבד במכונה קיימת
לפני שמפעילים עותקי API לקריאה בלבד במכונה קיימת של Memorystore for Redis, מומלץ מאוד להפחית את תנועת הכתיבה לצומת הראשי. כך הצומת הראשי יכול לסנכרן את הנתונים עם הרפליקות באופן מלא. אם לא תפחיתו את תנועת הכתיבה, יכול להיות שלא תוכלו להפעיל את הרפליקות לקריאה בלבד.