בדף הזה מוסבר איך לפתור בעיות של השהיית רפליקציה בעותקי קריאה של Cloud SQL.
סקירה כללית
רפליקות לקריאה ב-Cloud SQL משתמשות בקבוצות זמינות של SQL Server Always-On לשכפול. השינויים נכתבים ביומן העסקאות במופע הראשי. המופע הראשי מעביר עסקאות לכל מופע משני של רפליקה, שבו השינויים מוחלים. מצב הזמינות שבו נעשה שימוש הוא מצב של ביצוע פעולות (commit) באופן אסינכרוני.יכול להיות שיהיה עיכוב בשכפול בכמה תרחישים, למשל:
- המופע הראשי לא יכול לשלוח את השינויים מספיק מהר אל העותק.
- ההעתק לא יכול לקבל את השינויים מספיק מהר.
- ההעתק לא יכול להחיל את השינויים מספיק מהר.
network_lag
metric. מידע נוסף על המדד זמין במאמר מעקב אחרי פרק הזמן שחלף מאז השינוי האחרון ברפליקציה.
מוודאים שההקצאה של העותק מספיקה
יכול להיות שיהיה עיכוב בשכפול אם מופע הרפליקה קטן יותר מהמופע הראשי (לדוגמה, עם פחות מעבדי vCPU וזיכרון). יכול להיות שגם רפליקה קטנה יותר יכלול דגלים שונים של הגדרות ברירת מחדל בהשוואה למופע ראשי גדול יותר. מומלץ שגודל מופע ההעתק יהיה לפחות כמו גודל המופע הראשי, כדי שיהיו מספיק משאבים לטיפול בעומס השכפול.
ניצול גבוה של המעבד ברפליקה יכול גם לגרום להשהיית השכפול. אם ניצול המעבד (CPU) של העותק גבוה (לדוגמה, מעל 90%), כדאי להגדיל את קיבולת המעבד של העותק.
אופטימיזציה של שאילתות וסכימות
בקטע הזה מוצעות כמה אופטימיזציות נפוצות של שאילתות וסכימות שאפשר לבצע כדי לשפר את ביצועי השכפול.
שאילתות שמחייבות זמן ריצה ארוך בעותק לקריאה
שאילתות שפועלות במשך זמן רב ברפליקה עלולות לחסום את הרפליקציה ב-Cloud SQL. יכול להיות שתרצו ליצור רפליקות נפרדות למטרות של עיבוד עסקאות אונליין (OLTP) ועיבוד אנליטי אונליין (OLAP), ולשלוח רק שאילתות ארוכות טווח לרפליקת OLAP.
נעילות בלעדיות בגלל DDL
פקודות של שפת הגדרת נתונים (DDL), כמו ALTER TABLE ו-CREATE INDEX, עלולות לגרום להשהיית שכפול ברפליקה בגלל נעילות בלעדיות. כדי להימנע ממצב של תחרות על משאבים, כדאי לתזמן את הביצוע של DDL בזמנים שבהם עומס השאילתות על העותקים נמוך יותר.
CREATE INDEX, ALTER INDEX ו-INDEX
MAINTENANCE יכולות לגרום להשהיית שכפול בגלל מספר גדול של רשומות ביומן העסקאות שההצהרות האלה יכולות ליצור.
רפליקה בעומס יתר
אם עותק לקריאה מקבל יותר מדי שאילתות, יכול להיות שהשכפול ייחסם. כדאי לפצל את פעולות הקריאה בין כמה עותקים משוכפלים כדי להפחית את העומס על כל אחד מהם.
כדי להימנע מעליות חדות במספר השאילתות, כדאי להגביל את מספר השאילתות לקריאת העתקים בלוגיקה של האפליקציה או בשכבת proxy, אם משתמשים בה.
אם יש עליות חדות בפעילות במופע הראשי, כדאי לפצל את העדכונים.
מסד נתונים ראשי מונוליטי
כדאי לשקול לבצע שרדינג אנכי (או אופקי) במסד הנתונים הראשי כדי למנוע מצב שבו טבלה אחת או יותר עם פיגור מעכבות את כל שאר הטבלאות.
מעקב אחרי עיכוב ברפליקציה
אפשר להשתמש במדדים replica_lag ו-network_lag כדי לעקוב אחרי השהיית השכפול ולזהות אם הגורם להשהיה הוא מסד הנתונים הראשי, הרשת או העותק המשוכפל.
| מדד | תיאור |
|---|---|
| השהיה ברשת ( cloudsql.googleapis.com) |
ההפרש בין חותמת הזמן של רשומת היומן האחרונה שהתקבלה ברפליקה לבין רשומת היומן האחרונה שנשלחה בשרת הראשי. |
אימות השכפול
כדי לוודא שהשכפול פועל, בודקים את הערך של מדדcloudsql.googleapis.com/database/replication/state במופע הראשי. אם המצב הוא Running, המשמעות היא שהשכפול תקין.