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

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

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

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

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

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

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

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

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

סיבות נפוצות להשהיית השכפול

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

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

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

• עומס על המעבד (CPU) ועל הזיכרון: עומס עבודה כבד של קריאה במופע של מאגר קריאה יכול להתחרות בתהליך הרפליקציה על משאבי המעבד (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 כדי לזהות מתי יש עיכוב בשאילתות בגלל השהיית רפליקה.

• Cloud Monitoring: אפשר להשתמש במדד 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 ביומן Write-Ahead Log ‏ (WAL). יכול לקחת הרבה זמן עד שהרשומות האלה יופעלו מחדש בצמתים של מאגר הקריאה, מה שיוביל לעלייה זמנית בפיגור השכפול.

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

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

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

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

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

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

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

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