‫Google משתמשת בטכנולוגיית AI כדי לתרגם תוכן לשפה המועדפת עליך. בתרגומים כאלו עשויות להיות שגיאות.

משימות תחזוקה ב-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 כדי לשנות את נפח האחסון שמוקצה לקובצי היומן.

עורכים את /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 מבצעת באופן אוטומטי את הפעולות הבאות כדי לצמצם את ניצול הדיסק שלה:

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

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

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