עיכוב בשכפול

בדף הזה מוסבר איך לפתור בעיות של השהיית רפליקציה בעותקים לקריאה של Cloud SQL.

סקירה כללית

רפליקות לקריאה ב-Cloud SQL משתמשות ב שכפול סטרימינג של PostgreSQL. השינויים נכתבים ביומן Write-Ahead Log ‏ (WAL) במופע הראשי. השולח של WAL שולח את ה-WAL אל המקבל של WAL בעותק המשוכפל, שם הוא מוחל.

יכול להיות שיהיה עיכוב בשכפול בכמה תרחישים, למשל:

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

מוודאים שההקצאה של העותק מספיקה

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

ניצול גבוה של המעבד ברפליקה יכול גם לגרום להשהיית השכפול. אם ניצול המעבד של העותק גבוה (לדוגמה, מעל 90%), כדאי להגדיל את קיבולת המעבד של העותק.

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

אופטימיזציה של שאילתות וסכימות

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

שאילתות שמחייבות זמן ריצה ארוך בעותק לקריאה

יכול להיות ששאילתות שפועלות במשך זמן רב בעותק המשוכפל יחסמו את השכפול ב-Cloud SQL. זה יכול לקרות כששכפול מנסה להחיל שינויים (למשל מפעולת VACUUM) על שורות ששאילתה קוראת בעותק המשוכפל.

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

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

  • שינוי הדגלים של ההשהיה במצב המתנה. הדגלים max_standby_archive_delay ו-max_standby_streaming_delay קובעים כמה זמן העותק ימתין לפני ביטול שאילתות במצב המתנה שמתנגשות עם השכפול. ערכים סבירים הם בדרך כלל בין 30 ל-60 שניות. אפשר לבדוק את התצוגה pg_stat_database_conflicts כדי לקבל תובנות לגבי התנגשויות בין שאילתות.
  • מפעילים את התכונה הניסיונית hot_standby_feedback. הגדרת הדגל hot_standby_feedback לערך on בעותק יכולה לעזור, כי היא גורמת לעיכוב של פעולות vacuum בשרת הראשי. עם זאת, זה עלול לגרום לניפוח של הטבלה בשרת הראשי, ולכן צריך לשקול את היתרונות והחסרונות.

מידע נוסף זמין ב מאמרי העזרה בנושא PostgreSQL.

פיגור גבוה ברשת

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

  • שכפול בין אזורים. שכפול בין אזורים שונים עלול לגרום לזמן אחזור גבוה יותר ברשת.
  • ניצול גבוה של המעבד הראשי. אם השימוש ב-CPU של השרת הראשי הוא מעל 90%, יכול להיות שתהליך השליחה של WAL לא יקבל מספיק זמן CPU. כדאי להפחית את העומס על המעבד הראשי או להגדיל את ה-CPU שלו.
  • ניצול גבוה של CPU ברפליקה. אם השימוש במעבד של העותק זהה או גבוה מ-90%, יכול להיות שתהליך קבלת ה-WAL לא יקבל מספיק זמן מעבד. כדאי להפחית את העומס על העותק או להגדיל את המעבד שלו.
  • בעיות ברוחב הפס של הרשת או צווארי בקבוק של קלט/פלט בדיסק. אפשר לנסות להשתמש באזור קרוב יותר או בהגדרת דיסק עם תפוקה גבוהה יותר. כדי לצמצם את התנועה בין אזורים, כדאי לשנות את ערך הדגל wal_compression במופע הראשי.
אפשר לעקוב אחרי השהיית הרשת באמצעות המדד cloudsql.googleapis.com/database/replication/network_lag. למדד הזה יש מגבלה מקסימלית של 25 שניות, גם אם הפיגור בפועל גבוה יותר.

המדד network_lag דומה למדד cloudsql.googleapis.com/database/postgresql/replication/replica_byte_lag שמודד את השהיית sent_location במונחים של בייטים, כפי שמצוין בתווית replica_lag_type שלו.

נעילות בלעדיות בגלל DDL

פקודות של שפת הגדרת נתונים (DDL), כמו ALTER TABLE ו-CREATE INDEX, עלולות לגרום להשהיית שכפול בעותק עקב נעילות בלעדיות. כדי להימנע ממצב של תחרות על משאבים, כדאי לתזמן את הביצוע של DDL לתקופות שבהן עומס השאילתות על העותקים נמוך יותר.

מידע נוסף זמין ב מאמרי העזרה בנושא PostgreSQL.

עותק משוכפל בעומס יתר

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

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

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

מסד נתונים ראשי מונוליטי

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

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

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

מדדתיאור
השהיית שכפול
(cloudsql.googleapis.com/database/replication/replica_lag)

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

המדד הזה מחושב באמצעות now() - pg_last_xact_replay_timestamp() ברפליקה. זהו ערך משוער. אם השכפול נכשל, העותק לא יודע מה הפער בינו לבין מסד הנתונים הראשי, והמדד הזה לא יציין את השהיית הכוללת.
Lag bytes
(cloudsql.googleapis.com/database/postgres/replication/replica_byte_lag)

מספר הבייטים שבהם מצב העותק מפגר אחרי המצב של מסד הנתונים הראשי. ‫replica_byte_lag exports 4 time series, and the replica_lag_type label can indicate any of the following:

  • ‫sent_location: מציין כמה בייטים של WAL נוצרו, אבל עדיין לא נשלחו לרפליקה.
  • ‫write_location: הערך 'כתיבה מינוס השהיה בשליחה' מציג בייטים של WAL ברשת, שנשלחו אבל עדיין לא נכתבו בעותק המשוכפל.
  • ‫flush_location: השהיית כתיבה של flush מינוס מציגה בייטים של WAL שנכתבו בעותק המשוכפל אבל עדיין לא הועברו לעותק המשוכפל.
  • ‫replay_location: מציג את הפיגור הכולל בבייטים. ההפרש בין זמן ההפעלה מחדש לבין זמן הסיום של ההעברה מציין את העיכוב בהפעלה מחדש.
השהיה ברשת
(cloudsql.googleapis.com/database/replication/network_lag)

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

אם הערך של network_lag הוא אפס או זניח, אבל הערך של replica_lag גבוה, זה מצביע על כך שמקבל ה-WAL לא מצליח להחיל את שינויי השכפול מספיק מהר.

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

אימות השכפול

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

  select status, last_msg_receipt_time from pg_stat_wal_receiver;

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

  postgres=> select status, last_msg_receipt_time from pg_stat_wal_receiver;
    status   |     last_msg_receipt_time
  -----------+-------------------------------
  streaming | 2020-01-21 20:19:51.461535+00
  (1 row)

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

  postgres=> select status, last_msg_receipt_time from pg_stat_wal_receiver;
  status | last_msg_receipt_time
  --------+-----------------------
  (0 rows)

מה השלב הבא: