עיכוב בשכפול

‫MySQL   |  PostgreSQL   |  SQL Server

בדף הזה מוסבר איך לפתור בעיות של השהיית רפליקציה בעותקי קריאה של 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) הראשית. אם השימוש ב-CPU של השרת הראשי הוא מעל 90%, יכול להיות שתהליך השליחה של WAL לא יקבל מספיק זמן CPU. כדאי להפחית את העומס על המעבד הראשי או להגדיל את המעבד שלו.
• ניצול גבוה של CPU ברפליקה. אם השימוש במעבד של העותק זהה או גבוה מ-90%, יכול להיות שתהליך קבלת ה-WAL לא יקבל מספיק זמן מעבד. כדאי להפחית את העומס על העותק או להגדיל את המעבד שלו.
• בעיות ברוחב הפס של הרשת או צווארי בקבוק של קלט/פלט בדיסק. אפשר לנסות להשתמש באזור קרוב יותר או בהגדרת דיסק עם תפוקה גבוהה יותר. כדי לצמצם את התנועה בין אזורים, כדאי לשנות את ערך הדגל wal_compression במופע הראשי.

אפשר לעקוב אחרי השהיית הרשת באמצעות המדד cloudsql.googleapis.com/database/replication/network_lag. למדד הזה יש מגבלה מקסימלית של 25 שניות, גם אם הפיגור בפועל גבוה יותר.

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

המדד 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: הערך של write minus sent lag מציג את הבייטים של WAL ברשת, שנשלחו אבל עדיין לא נכתבו בעותק המשוכפל. ‫flush_location: השהיית כתיבה של flush minus מציגה בייטים של 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 מוצג ומופיע ערך עדכני של last_msg_receipt_time:

  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)

מה השלב הבא:

• קידום רפליקות להעברה אזורית או להתאוששות מאסון