עיכוב בשכפול

‫MySQL   |  PostgreSQL   |  SQL Server

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

סקירה כללית

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

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

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

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

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

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

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

מה השלב הבא:

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