Google आपकी पसंदीदा भाषा में कॉन्टेंट का अनुवाद करने के लिए, एआई टेक्नोलॉजी का इस्तेमाल करता है. एआई से मिले अनुवादों में गलतियां हो सकती हैं.

Apache कैसंड्रा के रखरखाव से जुड़े टास्क

चेतावनी: इस दस्तावेज़ में, Edge for Private Cloud 4.51.00 के बारे में बताया गया है. यह वर्शन अब काम नहीं करता. Google इस वर्शन के लिए, सिक्योरिटी पैच, गड़बड़ी ठीक करने की सुविधा या तकनीकी सहायता नहीं देता है. फ़िलहाल, 4.54.00 वर्शन का इस्तेमाल किया जा सकता है. मौजूदा वर्शन के लिए, Edge for Private Cloud का दस्तावेज़ देखें या रिलीज़ की तुलना करने के लिए, सभी वर्शन देखें.

इस सेक्शन में, Cassandra के लिए समय-समय पर किए जाने वाले रखरखाव के टास्क के बारे में बताया गया है.

एंटी-एंट्रॉपी मेंटेनेंस

Apache Cassandra रिंग नोड को समय-समय पर रखरखाव की ज़रूरत होती है, ताकि सभी नोड में एक जैसा डेटा बना रहे. रखरखाव से जुड़ा यह काम करने के लिए, इस निर्देश का इस्तेमाल करें:

apigee-service apigee-cassandra apigee_repair -pr

इस निर्देश को चलाते समय, Apigee ये सुझाव देता है:

हर Cassandra नोड (सभी इलाकों या डेटा सेंटर में) पर चलाएं.
एक बार में एक नोड पर चलाएं, ताकि रिंग में मौजूद सभी नोड में एक जैसा डेटा हो. पक्का करें कि हर Cassandra नोड पर, डिस्क में बचा स्टोरेज 50% उपलब्ध हो. एक ही समय पर कई नोड पर रिपेयर जॉब चलाने से, 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 विकल्प (पार्टिशनर रेंज) का इस्तेमाल करें.

अगर आपने Cassandra के लिए JMX से पुष्टि करने की सुविधा चालू की है, तो nodetool को शुरू करते समय आपको उपयोगकर्ता नाम और पासवर्ड शामिल करना होगा. उदाहरण के लिए:

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

apigee_repair: के साथ काम करने वाले विकल्पों को देखने के लिए, यह कमांड भी चलाया जा सकता है

apigee-service apigee-cassandra apigee_repair -h

ध्यान दें: apigee_repair, Cassandra के nodetool repair के लिए एक रैपर है. यह Cassandra की मरम्मत करने से पहले, अतिरिक्त जांच करता है.

ज़्यादा जानकारी के लिए, ये लेख पढ़ें:

लॉग फ़ाइल का रखरखाव

Cassandra के लॉग, हर नोड पर /opt/apigee/var/log/cassandra डायरेक्ट्री में सेव किए जाते हैं. डिफ़ॉल्ट रूप से, ज़्यादा से ज़्यादा 50 लॉग फ़ाइलें बनाई जा सकती हैं. हर फ़ाइल का साइज़ ज़्यादा से ज़्यादा 20 एमबी हो सकता है. यह सीमा पूरी होने के बाद, नए लॉग बनने पर पुराने लॉग मिटा दिए जाते हैं.

अगर आपको लगता है कि 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 डेटा को कंपैक्ट करता है, तो इसमें काफ़ी सीपीयू साइकल और मेमोरी लग सकती है. हालांकि, कंपैक्शन की प्रोसेस पूरी होने के बाद, संसाधन का इस्तेमाल सामान्य हो जाना चाहिए. हर नोड पर 'Nodetool compactionstats' कमांड चलाकर, यह देखा जा सकता है कि कंपैक्शन चल रहा है या नहीं. compactionstats के आउटपुट से आपको पता चलता है कि क्या कंपैक्शन की प्रोसेस बाकी है और उसे पूरा होने में कितना समय लगेगा.