פתרון בעיות בשכפול

ל-AlloyDB יש ארכיטקטורה שמפרידה בין מחשוב לאחסון, ומאפשרת לכל אחד מהם להתרחב באופן עצמאי. למרות שהמכונות המרכזיות ומאגר הקריאה חולקות את אותו אחסון בסיסי, השכפול הוא עדיין תהליך חיוני לשמירה על עקביות ועדכניות הנתונים בעותקי הקריאה. באשכול AlloyDB, פעולות הכתיבה מתבצעות במכונה המרכזית ואז נרשמות ביומן Write-Ahead Log ‏ (WAL). לאחר מכן השינויים האלה משוכפלים לצמתי מאגר הקריאה. כדי לפתור בעיות, חשוב להבין את שני השלבים העיקריים של תהליך השכפול הזה:

• שטיפת WAL: יומן הרישום מראש (WAL), שמכיל את השינויים במסד הנתונים, נשלח מהשרת הראשי לשרת המשני. השרת המשני שומר את ה-WAL בדיסק באופן מיידי.
• החלת WAL (או הפעלה חוזרת): ה-WAL שנשמר מופעל מחדש על העותק, כלומר השינויים מוחלים על מטמוני הזיכרון של העותק.

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

• השהיה ב-flush או ברשת: זו ההשהיה בשלב ה-flush של WAL. זהו הזמן שנדרש לשליחת ה-WAL מהשרת הראשי ולשמירתו בשרת המשני.
• השהיית הפעלה חוזרת: זהו העיכוב בשלב ההחלה של WAL. זהו הזמן שנדרש לשכפול כדי להחיל את השינויים מ-WAL.

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

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

בדיקת השהיית רפליקציה

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

סיבות נפוצות לפיגור בשכפול

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

התחרות על משאבים

השכפול עשוי להיות איטי יותר גם בגלל תחרות על משאבי המערכת, כמו מעבד (CPU) וזיכרון.

• עומס על המעבד (CPU) והזיכרון: עומס עבודה כבד של קריאה במכונת מאגר קריאה יכול להתחרות עם תהליך השכפול על משאבי המעבד והזיכרון. אפשר לבדוק את השימוש במעבד ובזיכרון של המכונות ב Google Cloud מסוף. אם אתם רואים ניצול גבוה של משאבים, יכול להיות שתצטרכו להגדיל את הקיבולת או להרחיב את מכונות מאגר הקריאה.
• גודל הצומת של מאגר הקריאה: אם המכונה הראשית גדולה בהרבה מהצמתים של מאגר הקריאה, יכול להיות שהיא תיצור יומני שכפול מהר יותר מהמהירות שבה צמתים הקריאה יכולים לעבד אותם. במקרים כאלה, מומלץ להשתמש בצמתי קריאה גדולים יותר כדי להקצות יותר משאבים לרפליקות.

התנגשויות בשכפול

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

כדי לזהות את הקונפליקטים האלה, מחפשים הודעות canceling statement due to conflict with recovery בקובץ postgres.log בכלי Logs Explorer.

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

• ‫Reduce max_standby_streaming_delay: הפרמטר הזה קובע כמה זמן תהליך ההפעלה מחדש ימתין לפני ביטול שאילתות שחוסמות אותו. ערך ברירת המחדל הוא 30 שניות. הפחתת הערך הזה יכולה לעזור לצמצם את זמן ההשהיה של השכפול, אבל היא עלולה גם לגרום לביטול של יותר שאילתות קריאה. אפשר לשנות את הפרמטר הזה כדי למצוא את האיזון הכי טוב לאפליקציה.

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

• בודקים שהדגל alloydb.promote_cancel_to_terminate פעיל: הדגל הזה, שמופעל כברירת מחדל, מאפשר ל-AlloyDB להפסיק בכוח את תהליכי ה-backend של השאילתות שלא מגיבים לבקשות ביטול. כך אפשר למנוע ממערכות קצה עורפיות שלא מגיבות לחסום שכפול למשך תקופות ארוכות.

ויסות נתונים של שאילתות קריאה על סמך השהיה

ב-AlloyDB יש לכם גם שליטה בהפעלה של הגבלת קצב (throttling) של שאילתות קריאה בצמתים לקריאה על סמך השהיה, באמצעות הדגל google_storage.log_replay_throttle_read_transactions. אם הפרמטר מוגדר לערך ברירת המחדל שלו, on, שאילתות הקריאה מוגבלות על ידי השהיית ההתחלה של שאילתות חדשות וקריאת מאגרים חדשים למשך דקה אחת לכל היותר, כשהשהיית השכפול חורגת משנייה אחת. התכונה הזו משפרת את השהיית השכפול על ידי הקצאת יותר משאבים להפעלה מחדש כדי לצמצם את הפער מהר יותר, אבל עלולה להגדיל את זמן האחזור של שאילתות הקריאה. אם האפליקציה שלכם לא רגישה להשהיית שכפול, אתם יכולים לתת עדיפות לשיפור זמן האחזור של שאילתות הקריאה על ידי הגדרת google_storage.log_replay_throttle_read_transactions לערך off.

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

• יומנים: מחפשים הודעות Delayed.*due to replica lag בקובץ postgres.log ב-Logs Explorer כדי לזהות מתי יש עיכוב בשאילתות בגלל השהיית שכפול.

• ניטור בענן: אפשר להשתמש במדד alloydb.googleapis.com/instance/postgresql/wait_count כדי לראות כמה שאילתות הוגבלו. כדי לעשות זאת, מסננים את המדד לפי wait_event_name ומחפשים HighLagThrottle. כדי לראות את הזמן הכולל שבו הוגבלו שאילתות, אפשר להשתמש במדד alloydb.googleapis.com/instance/postgresql/wait_time עם אותו מסנן. מידע נוסף זמין במאמר הפניה למדדים של תובנות לגבי המערכת.

• תובנות לגבי שאילתות: בתצוגה Active queries בלוח הבקרה Query insights, אירוע ההמתנה HighLagThrottle מופיע בעמודה Wait event כשמתבצעת הגבלת קצב של שאילתה בגלל השהיית שכפול. פרטים נוספים זמינים במאמר בנושא מעקב אחרי שאילתות פעילות.

עומס עבודה כבד

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

נפח גדול של יומני כתיבה מראש (Write-Ahead-Logs) בגלל בניית אינדקס ScaNN

יצירת אינדקס ScaNN עשויה ליצור כמויות גדולות של רשומות WAL של כתיבות לדף מלא. זה עלול לגרום לעיכוב בשליחת רשומות WAL מהמופע הראשי למופעי קריאה. אם השהיית השכפול תואמת ליצירת אינדקס ScaNN במספרים גדולים של הטמעות, אפשר להפעיל את wal_compression במופע הראשי כדי לחסוך ב-I/O של הרשת והדיסק ולהפחית את השהיית השכפול. יכול להיות שזה יגרום לעומס קטן נוסף על המעבד.

‫wal_compression רק דוחס רשומות של כתיבה בדף מלא ולא משפיע על רוב רשומות ה-WAL. שינוי הדגל הזה לא דורש הפעלה מחדש ואין השבתה.

עסקאות גדולות

טרנזקציות שמשנות מספר גדול של שורות – למשל, על ידי מחיקה של כמה טבלאות או טבלאות גדולות – יוצרות רשומות גדולות במיוחד של COMMIT או ABORT ביומן כתיבה מראש (WAL). יכול לקחת הרבה זמן לשחזר את הרשומות האלה בצמתים של מאגר הקריאה, מה שמוביל לעלייה זמנית בפיגור השכפול.

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

פתרון בעיות שמונעות שכפול

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

קריאה של קריסות של מופעי מאגר

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

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

ההשפעה של שינוי הגודל של מופע על השהיית השכפול

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