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