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

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

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

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

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

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

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

בדיקה אם יש עיכוב ברפליקציה

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

סיבות נפוצות להשהיה ברפליקציה

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

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

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

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

התנגשויות ברפליקציה

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

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

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

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

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

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

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

ב-AlloyDB אתם יכולים גם להחליט אם להפעיל ויסות נתונים מבוסס-השהיה של שאילתות קריאה בצומתי קריאה באמצעות הדגל 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 עם אותו מסנן. מידע נוסף זמין במאמר הפניית מדדים של תובנות מערכת.

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

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

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

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

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

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

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

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

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

פתרון בעיות שמונעות רפליקציה

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

קריסות של מופע ייעודי לשאילתות מסוג "קריאה-בלבד"

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

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

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

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