इस सेक्शन में, Cassandra के लिए समय-समय पर रखरखाव के टास्क के बारे में बताया गया है.
एंटी-एन्ट्रोपी रखरखाव
Apache Cassandra रिंग नोड को समय-समय पर रखरखाव की ज़रूरत होती है, ताकि सभी नोड पर एक जैसी परफ़ॉर्मेंस मिल सके. यह रखरखाव करने के लिए, नीचे दिए गए निर्देश का इस्तेमाल करें:
apigee-service apigee-cassandra apigee_repair -pr
Apigee का सुझाव है कि इस कमांड को चलाते समय, ये काम करें:
- सभी क्षेत्रों या डेटा सेंटर में हर Cassandra नोड पर चलाएं.
एक बार में एक नोड पर चलाएं, ताकि यह पक्का किया जा सके कि रिंग में सभी नोड एक जैसे हों. एक ही समय में कई नोड पर रिपेयर जॉब चलाने से, 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 रिपेयर के आस-पास मौजूद एक रैपर है. यह Cassandra को रिपेयर करने से पहले, अन्य जांच करता है.
ज़्यादा जानकारी के लिए, ये संसाधन देखें:
लॉग फ़ाइल का रखरखाव
Cassandra लॉग, हर नोड पर /opt/apigee/var/log/apigee-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 के नए इंस्टॉलेशन, लेवल की कंपैक्शन रणनीति के साथ कीस्पेस बनाएंगे.
Private Cloud 4.51.00 पर अपग्रेड किए गए, Edge for Private Cloud के पुराने वर्शन के इंस्टॉलेशन में, डेटा कंपैक्ट करने की पिछली रणनीति का इस्तेमाल जारी रहेगा. अगर मौजूदा कॉम्पैक्शन रणनीति, साइज़ के हिसाब से कॉम्पैक्शन की रणनीति है, तो हमारा सुझाव है कि आप इसे लेवल के हिसाब से कॉम्पैक्शन की रणनीति में बदलें. इससे डिस्क का बेहतर तरीके से इस्तेमाल किया जा सकता है.
ध्यान दें: जब Cassandra डेटा कंपैक्शन करता है, तो इसमें काफ़ी सीपीयू साइकल और मेमोरी लग सकती है. हालांकि, डेटा कंपैक्ट होने के बाद, संसाधनों के इस्तेमाल की दर सामान्य हो जाएगी.
कॉम्पैक्शन चल रहा है या नहीं, यह देखने के लिए हर नोड पर 'Nodetool compactionstats' कमांड चलाया जा सकता है. compactionstats के आउटपुट से आपको यह जानकारी मिलती है कि क्या कॉम्पैक्ट करने के लिए कोई काम बाकी है और उसे पूरा होने में कितना समय लगेगा.