משימות תחזוקה ב-Apache Cassandra

בקטע הזה מתוארות משימות תחזוקה תקופתיות של Cassandra.

תחזוקה למניעת אנטרופיה

צריך לבצע תחזוקה תקופתית של צמתי הטבעת של Apache Cassandra כדי להבטיח עקביות בכל הצמתים. כדי לבצע את פעולת התחזוקה הזו, משתמשים בפקודה הבאה:

apigee-service apigee-cassandra apigee_repair -pr

כשמריצים את הפקודה הזו, מומלץ לפעול לפי ההנחיות הבאות של Apigee:

  • מריצים בכל צומת של Cassandra (בכל האזורים או מרכזי הנתונים).

  • מריצים בצומת אחד בכל פעם, כדי להבטיח עקביות בכל הצמתים בטבעת. הפעלה של משימות תיקון בכמה צמתים בו-זמנית עלולה לפגוע בתקינות של Cassandra.

    כדי לבדוק אם עבודת תיקון בצומת הסתיימה בהצלחה, מחפשים בקובץ system.log של הצומת רשומה עם ה-UUID של סשן התיקון האחרון והביטוי 'session completed successfully'. דוגמה לרשומה ביומן:

    INFO [AntiEntropySessions:1] 2015-03-01 10:02:56,245 RepairSession.java (line 282) [repair #2e7009b0-c03d-11e4-9012-99a64119c9d8] session completed successfully"
Ref: https://support.datastax.com/hc/en-us/articles/204226329-How-to-check-if-a-scheduled-nodetool-repair-ran-successfully
  • להריץ את הכלי בתקופות של עומס עבודה נמוך יחסית (הכלי מטיל עומס משמעותי על המערכת).
  • צריך להריץ לפחות כל שבעה ימים כדי למנוע בעיות שקשורות ל"מחיקות שנשכחו" של Cassandra.
  • מריצים את הסקריפט בצמתים שונים בימים שונים, או מתזמנים אותו כך שיעברו כמה שעות בין ההרצה בכל צומת.
  • משתמשים באפשרות -pr (טווח המחיצות) כדי לציין את טווח המחיצות הראשי של הצומת בלבד.

אם הפעלתם אימות JMX עבור Cassandra, אתם צריכים לכלול את שם המשתמש והסיסמה כשאתם מפעילים את nodetool. לדוגמה:

apigee-service apigee-cassandra apigee_repair -u username -pw password -pr

אפשר גם להריץ את הפקודה הבאה כדי לבדוק את האפשרויות הנתמכות של apigee_repair:

apigee-service apigee-cassandra apigee_repair -h

הערה: apigee_repair הוא wrapper סביב הכלי nodetool repair של Cassandra, שמבצע בדיקות נוספות לפני שמבצעים את התיקון של Cassandra.

מידע נוסף זמין במקורות המידע הבאים:

תחזוקה של קובצי יומן

היומנים של Cassandra מאוחסנים בספרייה /opt/apigee/var/log/apigee-cassandra בכל צומת. כברירת מחדל, אפשר ליצור עד 50 קובצי יומן, כל אחד בגודל של עד 20MB. כשמגיעים למגבלה הזו, יומנים חדשים מחליפים את הישנים.

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

  1. עורכים את /opt/apigee/customer/application/cassandra.properties כדי להגדיר את המאפיינים הבאים. אם הקובץ הזה לא קיים, יוצרים אותו: 
    conf_logback_maxfilesize=20MB
# max file size
conf_logback_maxbackupindex=50 # max open files
  2. מפעילים מחדש את Cassandra באמצעות הפקודה הבאה: 
    /opt/apigee/apigee-service/bin/apigee-service apigee-cassandra restart

תחזוקת המקום בכונן

חשוב לעקוב אחרי השימוש בדיסק של Cassandra באופן קבוע כדי לוודא שלפחות 50% מכל דיסק פנויים. אם ניצול הדיסק עולה על 50%, מומלץ להוסיף עוד מקום בכונן כדי להפחית את אחוז הניצול.

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

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

  • דחיסת נתונים: החל מגרסה 4.51.00 של Edge for Private Cloud, התקנות חדשות של Apigee Cassandra יוצרות מרחבי מפתחות באמצעות Leveled Compaction Strategy.

    התקנות של גרסאות קודמות של Edge for Private Cloud ששודרגו ל-Edge for Private Cloud 4.54.00 שומרות על אסטרטגיית הדחיסה הקודמת. אם אסטרטגיית הדחיסה הקיימת היא SizeTieredCompactionStrategy, מומלץ לשנות אותה ל- LeveledCompactionStrategy, שמאפשרת ניצול טוב יותר של הדיסק. הוראות מפורטות זמינות במאמר שינוי אסטרטגיית הדחיסה של Cassandra.

הערה: כש-Cassandra מבצעת דחיסת נתונים, היא יכולה לצרוך כמות משמעותית של מחזורי מעבד (CPU) וזיכרון. אבל השימוש במשאבים אמור לחזור למצב תקין אחרי שהדחיסות יסתיימו. אפשר להריץ את הפקודה 'Nodetool compactionstats' בכל צומת כדי לבדוק אם מתבצעת דחיסה. הפלט של compactionstats מציין אם יש דחיסות בהמתנה לביצוע ואת הזמן המשוער להשלמה.