בקטע הזה מתוארות משימות תחזוקה תקופתיות של Cassandra.
תחזוקה נגד אנטרופי
צמתים של טבעת Apache Cassandra דורשים תחזוקה תקופתית כדי להבטיח עקביות בכל הצמתים. כדי לבצע את פעולת התחזוקה הזו, משתמשים בפקודה הבאה:
apigee-service apigee-cassandra apigee_repair -pr
מומלץ לבצע את הפעולות הבאות כשמריצים את הפקודה הזו ב-Apigee:
- מריצים בכל צומת של Cassandra (בכל האזורים או במרכזי הנתונים).
מריצים על צומת אחד בכל פעם, כדי להבטיח עקביות בכל הצמתים ב-ring. הפעלת משימות תיקון בכמה צמתים בו-זמנית עלולה להזיק לבריאות של Cassandra.
כדי לבדוק אם משימה לתיקון באחד מהצמתים הושלמה, מחפשים בקובץ
system.logשל הצומת רשומה עם מזהה ה-UUID של סשן התיקון האחרון והביטוי 'הסשן הושלם בהצלחה'. דוגמה לרשומה ביומן: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(partitioner range) כדי לציין את טווח המחיצות הראשי של הצומת בלבד.
אם הפעלתם אימות 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 הוא מעטפת של תיקון nodetool של Cassandra, שמבצעת בדיקות נוספות לפני ביצוע התיקון של Cassandra.
מידע נוסף זמין במקורות הבאים:
תחזוקת קובצי יומן
יומני Cassandra מאוחסנים בספרייה /opt/apigee/var/log/apigee-cassandra בכל צומת. כברירת מחדל, אפשר ליצור עד 50 קובצי יומן, כל אחד בגודל של עד 20MB. כשמגיעים למגבלה הזו, יומנים ישנים יותר נמחקים כשיומנים חדשים נוצרים.
אם קובצי היומנים של Cassandra תופסים יותר מדי מקום, אפשר לשנות את נפח האחסון שהוקצה לקובצי היומנים על ידי עריכת ההגדרות של log4j.
- עורכים את
/opt/apigee/customer/application/cassandra.propertiesכדי להגדיר את המאפיינים הבאים. אם הקובץ הזה לא קיים, יוצרים אותו:conf_logback_maxfilesize=20MB # max file size conf_logback_maxbackupindex=50 # max open files
- מפעילים מחדש את Cassandra באמצעות הפקודה הבאה:
/opt/apigee/apigee-service/bin/apigee-service apigee-cassandra restart
תחזוקת נפח האחסון
מומלץ לעקוב באופן קבוע אחרי ניצול הדיסק ב-Cassandra כדי לוודא ש-50% לפחות מכל דיסק פנויים. אם ניצול הדיסק עולה על 50%, מומלץ להוסיף מקום פנוי בדיסק כדי להקטין את האחוז שנמצא בשימוש.
כדי לצמצם את ניצול הדיסק שלה, Cassandra מבצעת באופן אוטומטי את הפעולות הבאות:
- מחיקה של אסימון אימות כשהתוקף של האסימונים פג. עם זאת, יכול להיות שיחלפו כמה שבועות עד שמקום האחסון בדיסק שהאסימונים השתמשו בו יתפנה, בהתאם להגדרות שלכם. אם המחיקה האוטומטית לא מספיקה כדי לשמור על נפח אחסון מספיק בדיסק, תוכלו לפנות לתמיכה כדי לקבל מידע על מחיקה ידנית של אסימונים כדי לפנות מקום.
הערה לגבי דחיסת נתונים: החל מ-Edge for Private Cloud 4.51.00, התקנות חדשות של Apigee Cassandra ייצרו מרחבי מפתחות עם שיטת דחיסת נתונים ברמות.
התקנות של גרסאות ישנות יותר של Edge for Private Cloud ששודרגו ל-Private Cloud 4.51.00 ימשיכו להשתמש באסטרטגיית הדחיסה הקודמת. אם שיטת הדחיסה הקיימת היא SizeTieredCompactionStrategy, מומלץ לשנות אותה ל-LeveledCompactionStrategy, שמאפשרת ניצול יעיל יותר של הדיסק.
הערה: כש-Cassandra מבצעת דחיסה של נתונים, יכול להיות שהיא תשתמש בכמות משמעותית של מחזורי מעבד (CPU) וזיכרון. עם זאת, ניצול המשאבים אמור לחזור למצב הרגיל אחרי שהדחיסות יושלמו.
אפשר להריץ את הפקודה 'Nodetool compactionstats' בכל צומת כדי לבדוק אם דחיסת הנתונים פועלת. הפלט של compactionstats מודיע אם יש דחיסות בהמתנה לביצוע, ואת זמן השלמת הדחיסה המשוער.