2016-01-04 5 views
25

कृपया कमेट लॉग और इसके उपयोग को समझने के लिए मेरे लिए कोई स्पष्टीकरण दें।कैसंद्रा के प्रतिबद्धता लॉग का उद्देश्य क्या है?

कैसंद्रा में, डिस्क पर लिखते समय प्रतिबद्धता पहली प्रविष्टि बिंदु या MemTables लॉग है।

यदि मेमटेबल्स डिस्क पर फ़्लश हो रहा है, तो कमिट लॉग का उपयोग क्या है, डेटा लॉग नोड होने पर सर्वर सिंक समस्याओं का एकमात्र उद्देश्य है?

उत्तर

36

आप प्रतिबद्धता के रूप में प्रतिबद्धता लॉग के बारे में सोच सकते हैं, लेकिन कैसंद्रा इसके बिना असामान्य रूप से धीमा होगा। जब MemTables डिस्क पर लिखा जाता है तो हम उन्हें SSTables कहते हैं। एसएसटीबल्स अपरिवर्तनीय हैं, जिसका अर्थ है कि एक बार कैसंद्रा उन्हें डिस्क पर लिखता है, यह उन्हें अपडेट नहीं करता है। तो जब एक कॉलम बदलता है तो कैसंद्रा को डिस्क पर एक नया एसएसटीबल लिखना होगा। यदि कैसंद्रा प्रत्येक अद्यतन पर इन एसएसटीबल्स लिख रहे थे तो यह पूरी तरह से आईओ बाध्य और बहुत धीमा होगा।

तो कैसंड्रा बेहतर प्रदर्शन प्राप्त करने के लिए कुछ चाल का उपयोग करता है। प्रत्येक स्तंभ अद्यतन पर डिस्क पर एसएसटीबल्स लिखने के बजाय, यह अद्यतनों को स्मृति में रखता है और आईओ को उचित स्तर पर रखने के लिए समय-समय पर उन परिवर्तनों को डिस्क पर फ़्लश करता है। लेकिन इससे स्पष्ट समस्या होती है कि अगर मशीन नीचे जाती है या कैसंड्रा दुर्घटनाग्रस्त हो जाती है तो आप उस नोड पर डेटा खो देंगे। डेटा खोने से बचने के लिए, मेमोरी में हालिया परिवर्तनों को रखने के अलावा कैसंद्रा अपने CommitLog में परिवर्तन लिखता है।

आप पूछ सकते हैं कि CommitLog को केवल एसएसटीबल्स लिखने से बेहतर क्यों लिखा जा रहा है। CommitLog लेखन के लिए अनुकूलित है। एसएसटीबल्स के विपरीत जो क्रमबद्ध क्रम में पंक्तियों को संग्रहित करता है, CommitLog उस क्रम में अपडेट स्टोर करता है जिसे वे कैसंद्रा द्वारा संसाधित किया गया था। CommitLog एक ही फ़ाइल में सभी कॉलम परिवारों के लिए परिवर्तन भी संग्रहीत करता है ताकि डिस्क को एक ही समय में एकाधिक कॉलम परिवारों के लिए अपडेट प्राप्त होने पर खोजों का एक गुच्छा करने की आवश्यकता न हो।

असल में यह बेहतर है क्योंकि इसे एसएसटीबल्स लिखने से कम डेटा लिखना है और यह डिस्क पर एक ही स्थान पर वह डेटा लिखता है।

कैसंद्रा एसएसटीबल्स को किस डेटा को फ़्लश कर दिया गया है इसका ट्रैक रखता है और एक निश्चित बिंदु से पुराने सभी डेटा लिखे जाने के बाद कमिट लॉग को कम करने में सक्षम होता है।

जब कैसंद्रा शुरू होता है तो उसे समय के आखिरी ज्ञात अच्छे बिंदु से प्रतिबद्ध लॉग को पढ़ना होता है (जिस बिंदु पर हम जानते हैं कि सभी पिछले लिखने को एसएसटीबल में लिखा गया था)। यह प्रतिबद्धता लॉग में अपने मेमटेबल्स में परिवर्तनों को फिर से लागू करता है ताकि यह उसी स्थिति में हो सके जब यह रुक गया।यह प्रक्रिया धीमी हो सकती है, इसलिए यदि आप रखरखाव के लिए कैसंड्रा नोड रोक रहे हैं तो nodetool drain का उपयोग बंद करने से पहले nodetool drain का उपयोग करना एक अच्छा विचार है जो मेमटेबल्स में एसएसटीबल्स में सब कुछ फ्लश करेगा और स्टार्टअप पर बहुत कम काम करेगा।

+0

यदि नोड को रोकते समय मैं नोडेटूल नाली के बजाय नोडेटूल फ्लश का उपयोग करता हूं तो क्या अंतर है? –

+0

'नोडेटूल फ्लश' बस डिस्क पर memtables flushes। 'नोडेटूल नाली' फ्लश मेमटेबल्स और क्लाइंट और अन्य नोड्स से कनेक्शन स्वीकार करना बंद कर देता है। – psanford

+1

क्या प्रतिबद्ध लॉग दोहराया गया है? अन्यथा लॉग इन विफलता के एकल बिंदु हैं, है ना? – anon

25

कैसेंड्रा में लिखने पथ इस तरह काम करता है:

Cassandra Node ---->Commitlog-----------------> Memtable 
         |      | 
         |      | 
         |---> Periodically  |---> Periodically 
           sync to disk   flush to SSTable 

Memtable और CommitLog हैं नहीं समानांतर में (एक तरह से) लिखा। Memtable को लिखने से पहले CommitLog को लिखें समाप्त होना चाहिए। संबंधित स्रोत कोड ढेर है:

org.apache.cassandra.service.StorageProxy.mutateMV:mutation.apply-> 
org.apache.cassandra.db.Mutation.apply:Keyspace.open(keyspaceName).apply-> 
org.apache.cassandra.db.Keyspace.apply-> 
org.apache.cassandra.db.Keyspace.applyInternal{ 
    Tracing.trace("Appending to commitlog"); 
    commitLogPosition = CommitLog.instance.add(mutation) 
    ... 
    Tracing.trace("Adding to {} memtable",... 
    ... 
    upd.metadata().name(...); 
    ... 
    cfs.apply(...); 
    ... 
} 

commitlog के प्रयोजन के एक नोड दुर्घटनाओं के बाद memtable पुन: बनाने के लिए सक्षम होना है या रीबूट हो जाता है। यह महत्वपूर्ण है, क्योंकि जब यह 'पूर्ण' होता है तो ज्ञापन केवल डिस्क पर फिसल जाता है - जिसका अर्थ है कि कॉन्फ़िगर किए गए मेमटेबल आकार से अधिक है - या फ्लश नोडेटूल या ओपसेंटर द्वारा किया जाता है। तो memtable में डेटा सीधे जारी नहीं है।

यह कहकर, एक नोड को रिबूट करने से पहले एक अच्छी बात यह है कि यह सुनिश्चित करने के लिए कि आपका मेमटेबल जारी है, "नोडेटूल फ्लश" को कॉल करना है। नोड फिर से आने के बाद भी यह प्रतिबद्धता के प्लेबैक समय को कम करेगा।

+0

क्या प्रतिबद्ध लॉग दोहराया गया है? अन्यथा लॉग इन विफलता के एकल बिंदु हैं, है ना? – anon

+0

प्रत्येक नोड का अपना प्रतिबद्ध लॉग है। यह विफलता का एक बिंदु नहीं है। – psanford

संबंधित मुद्दे