מדדים ומעקב של TTL

בדף הזה מוסבר על מדדי אורך החיים (TTL) ב-Spanner. מידע נוסף זמין במאמר מידע על TTL.

מדדים

‫Spanner מספק מידע על פעילויות של TTL בטבלת מערכת שאפשר לקרוא באמצעות שאילתות SQL, וגם כמדדים שאפשר לגשת אליהם דרך Cloud Monitoring.

בטבלת המערכת מופיע מידע על TTL לכל טבלה במסד נתונים, וב-Cloud Monitoring מופיעים מדדים ברמת מסד הנתונים.

שימוש בשאילתת SQL

‫Spanner מספק טבלה מובנית שעוקבת אחרי מידע שקשור ל-TTL. שם הטבלה הוא SPANNER_SYS.ROW_DELETION_POLICIES והסכימה שלה היא:

שם העמודה	סוג	תיאור
TABLE_NAME	מחרוזת	השם של הטבלה שמכילה את מדיניות ה-TTL הזו.
PROCESSED_WATERMARK	TIMESTAMP	המדיניות הזו הופעלה על כל השורות בטבלה עד עכשיו. יכול להיות שמחיצות מסוימות בטבלה עברו עיבוד לאחרונה, ולכן חותמת הזמן הזו מייצגת את המחיצה שעברה עיבוד הכי מזמן. בדרך כלל תוך 72 שעות.
UNDELETABLE_ROWS	INT64	מספר השורות שלא ניתן למחוק באמצעות מדיניות ה-TTL. פרטים נוספים מופיעים במאמר בנושא שורות שלא ניתן למחוק.
MIN_UNDELETABLE_TIMESTAMP	TIMESTAMP	חותמת הזמן הכי ישנה של שורות שלא ניתן למחוק שנצפתה במהלך מחזור העיבוד האחרון.

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

אפשר להריץ שאילתת SQL על הנתונים האלה, כמו בדוגמה הבאה:

SELECT TABLE_NAME, UNDELETABLE_ROWS
FROM SPANNER_SYS.ROW_DELETION_POLICIES
WHERE UNDELETABLE_ROWS > 0

אפשר לגשת לטבלאות SPANNER_SYS רק דרך ממשקי SQL. לדוגמה:

• הדף Spanner Studio במסוף Google Cloud
• הפקודה gcloud spanner databases execute-sql
• ‫executeQuery API

שיטות אחרות לקריאה יחידה ש-Spanner מספק לא תומכות ב-SPANNER_SYS.

שימוש ב-Cloud Monitoring

‫Spanner מספק את המדדים הבאים כדי לעקוב אחר פעילות ה-TTL ברמת מסד הנתונים:

• ‫row_deletion_policy/deleted_rows הוא מספר השורות שנמחקו על ידי מדיניות ה-TTL.
• ‫row_deletion_policy/undeletable_rows הוא מספר השורות שתואמות להצהרת מחיקת השורה (GoogleSQL) או TTL INTERVAL(PostgreSQL), אבל אי אפשר למחוק אותן. בדרך כלל, הסיבה לכך היא שהיו יותר מדי שורות צאצא בשורה, ולכן הפעולה חרגה ממגבלת העסקאות של Spanner.
• ‫row_deletion_policy/processed_watermark_age הוא הזמן שחלף בין עכשיו לבין חותמת הזמן של הקריאה ששימשה את המחזור האחרון שהסתיים בהצלחה (עם שורות שלא ניתן למחוק או בלי שורות כאלה).

המדדים האלה זמינים דרך Cloud Monitoring ומסוףGoogle Cloud .

מעקב

אפשר גם לעקוב אחרי פעילויות אחרות של TTL.

איתור הסריקה המוצלחת האחרונה

אפשר למצוא את חותמת הזמן של התמונה האחרונה שבה Spanner סיים סריקה של הטבלה בחיפוש אחר שורות שתוקפן פג. כדי לעשות את זה באמצעות שאילתת SQL:

SELECT PROCESSED_WATERMARK
FROM SPANNER_SYS.ROW_DELETION_POLICIES
WHERE TABLE_NAME = $name

לחלופין, המדד row_deletion_policy/process_watermark_age מציג מידע דומה, אבל הוא מבוטא כהפרש בין הזמן הנוכחי לבין הזמן של הסריקה האחרונה. המדד לא מחולק לפי טבלה, אבל הוא מייצג את זמן הסריקה הכי ישן של כל הטבלאות במסד הנתונים שמופעל בהן TTL.

שורות שתואמות למדיניות TTL נמחקות בדרך כלל תוך 72 שעות מתאריך התפוגה שלהן. אתם יכולים להגדיר התראה ב-processed_watermark_age כדי לקבל הודעה אם משך הזמן חורג מ-72 שעות.

אם processed_watermark_age ישן יותר מ-72 שעות, יכול להיות שמשימות בעדיפות גבוהה יותר מונעות את ההפעלה של TTL. במקרה כזה, מומלץ לבדוק את ניצול המעבד ולהוסיף עוד קיבולת חישוב אם צריך. אם ניצול המעבד נמצא בטווח המומלץ, כדאי לבדוק אם יש שימוש בלתי מאוזן במשאבים (hotspotting) באמצעות Key Visualizer.

מעקב אחרי שורות שנמחקו

כדי לעקוב אחרי פעילות ה-TTL בטבלה, יוצרים תרשים של המדד row_deletion_policy/deleted_rows. במדד הזה מוצג מספר השורות שנמחקו לאורך זמן.

אם לא חלף תוקף של נתונים, המדד הזה יהיה ריק.

מעקב אחרי שורות שלא ניתן למחוק

אם אי אפשר למחוק שורה באמצעות TTL, ‏ Spanner מנסה שוב באופן אוטומטי. אם הפעולה של TTL לא מצליחה לעבור עיבוד אחרי ניסיון חוזר, Spanner מדלג על השורה ומדווח עליה במדד row_deletion_policy/undeletable_rows_count.

אתם יכולים להגדיר התראה ב-row_deletion_policy/undeletable_rows_count כדי לקבל הודעה על ספירה שאינה אפס.

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

SELECT TABLE_NAME, UNDELETABLE_ROWS, MIN_UNDELETABLE_TIMESTAMP
FROM SPANNER_SYS.ROW_DELETION_POLICIES
WHERE UNDELETABLE_ROWS > 0

כדי לחפש את התוכן של השורה שלא ניתן למחוק:

SELECT *
FROM $TABLE_NAME
WHERE $EXPIRE_COL >= $MIN_UNDELETABLE_TIMESTAMP

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