עיכוב בשכפול

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

סקירה כללית

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

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

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

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

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

ניצול גבוה של המעבד ברפליקה יכול גם לגרום להשהיית השכפול. אם ניצול המעבד (CPU) של העותק גבוה (לדוגמה, מעל 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 של הרפליקה. אם השימוש במעבד של העותק הוא מעל 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 לא מצליח להחיל את שינויי השכפול מספיק מהר.

אימות השכפול

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

  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)

מה השלב הבא: