עיכוב בשכפול

‫MySQL   |  PostgreSQL   |  SQL Server

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

סקירה כללית

רפליקות לקריאה ב-Cloud SQL משתמשות בקבוצות זמינות של SQL Server Always-On לשכפול. השינויים נכתבים ביומן העסקאות במופע הראשי. המופע הראשי מעביר עסקאות לכל מופע משני של רפליקה, שבו השינויים מוחלים. מצב הזמינות שבו נעשה שימוש הוא מצב של ביצוע פעולות באופן אסינכרוני.

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

• המופע הראשי לא יכול לשלוח את השינויים מספיק מהר אל העותק.
• ההעתק לא יכול לקבל את השינויים מספיק מהר.
• ההעתק לא יכול להחיל את השינויים מספיק מהר.

אפשר לעקוב אחרי שני התרחישים הראשונים שמופיעים ברשימה באמצעות network_lag metric. מידע נוסף על המדד זמין במאמר מעקב אחרי פרק הזמן שחלף מאז השינוי האחרון ברפליקה.

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

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

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

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

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

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

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

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

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

בנוסף, הצהרות DDL כמו CREATE INDEX,‏ ALTER INDEX ו-INDEX MAINTENANCE עלולות לגרום להשהיית שכפול בגלל מספר גדול של רשומות ביומן העסקאות שההצהרות האלה יכולות ליצור.

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

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

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

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

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

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

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

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

מדד	תיאור
השהיה ברשת (cloudsql.googleapis.com/database/replication/network_lag)	ההפרש בין חותמת הזמן של רשומת היומן האחרונה שהתקבלה בעותק לבין רשומת היומן האחרונה שנשלחה בשרת הראשי. הערך network_lag מעוגל כלפי מעלה לשנייה הקרובה ביותר, ולכן ערך של שנייה אחת בדוח יכול לייצג השהיה בטווח של אלפית שנייה או שתיים ועד שנייה שלמה.

אימות השכפול

כדי לוודא שהשכפול פועל, בודקים את הערך של מדד cloudsql.googleapis.com/database/replication/state במופע הראשי. אם המצב הוא Running, המשמעות היא שהשכפול תקין.

מה השלב הבא:

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