उत्पादन में रेडिस

जब एक कॉम्बैट सर्वर पर उपयोग किया जाता है तो मैं रेडिस की कुछ विशेषताओं के बारे में बात करना चाहूंगा। डिस्क पर डेटा सहेजते समय हम विकल्पों पर विचार करेंगे, जिससे आप विफलताओं के मामले में विश्वसनीयता की अलग-अलग डिग्री हासिल कर सकेंगे। बैकअप और निगरानी के लिए कॉन्फ़िगरेशन उदाहरण भी प्रदान किए जाएंगे। इस्तेमाल किया Redis 2.2.11 अमेज़न EC2 पर Ubuntu 10.10 स्थापित के साथ।

बैकअप

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

रेडिस निम्नलिखित मापदंडों के आधार पर RDB स्नैपशॉट बनाता है। redis.conf :

save 900 100 save 300 1000 save 60 100000 dir /var/redis/ dbfilename dump.rdb rdbcompression yes 

दो दृढ़ता मोड हैं: आरडीबी और एओएफ । यह ध्यान देने योग्य है कि दोनों मोड में डिस्क पर जानकारी लिखने का एक बहुत ही विश्वसनीय तरीका उपयोग किया जाता है, जो व्यावहारिक रूप से हार्डवेयर विफलता के दौरान डेटा हानि की स्थिति को समाप्त करता है। आप कितना डेटा खो देते हैं यह केवल दृढ़ता मोड की पसंद पर निर्भर करता है। RDB आपको इस पैरामीटर को लचीले ढंग से समायोजित करने की अनुमति देता है, लेकिन औसतन, यदि यह विफल रहता है, तो यह लगभग एक घंटे तक खो सकता है। इस मोड में, Redis पहले पूर्ण डेटाबेस स्नैपशॉट को एक अस्थायी फ़ाइल में लिखता है और डिस्क पर लिखने के पूरा होने के बाद ही यह काम कर रहा है। यह नाम बदलने () सिस्टम कॉल की परमाणुता के कारण डेटा हानि को समाप्त करता है।

एओएफ के मामले में, रेडिस उन कार्यों का एक लॉग रखता है जो ग्राहक प्रदर्शन करते हैं और उन्हें एक फ़ाइल में लिखते हैं (डिफ़ॉल्ट रूप से, हर दूसरे)। AOF एपेंड ओनली फाइल के लिए एक संक्षिप्त नाम है, जिसका अर्थ है कि रेडिस पहले से रिकॉर्ड किए गए डेटा को संशोधित नहीं करता है, लेकिन केवल नए लोगों को अंत में जोड़ता है। इस तथ्य के कारण कि एओएफ का उपयोग करते समय, रेडिस डिफ़ॉल्ट रूप से हर सेकंड डिस्क पर डेटा लिखता है, इस मोड का उपयोग करते समय विफलता के मामले में आप जो अधिकतम खो देते हैं वह 1 सेकंड है।

हमारे प्रोजेक्ट में, हम RDB का उपयोग करते हैं क्योंकि हमारे लिए एक घंटे का डेटा खोना महत्वपूर्ण नहीं है। इसके अलावा, सबसे खराब स्थिति में, डेटा मुख्य DBMS से पुनर्प्राप्त किया जा सकता है।

रेडिस में दृढ़ता के बारे में अधिक जानकारी:

http://redis.io/topics/persistence
http://antirez.com/post/redis-persistence-demystified.html

बैकअप के लिए, हम अद्भुत बैकअप रत्न का उपयोग करते हैं, जिसमें रेडिस का समर्थन है।

 # encoding: utf-8 Backup::Model.new(:my_backup, 'My Backup') do split_into_chunks_of 500 database Redis do |db| db.name = "dump" db.path = "/var/redis" db.host = "localhost" db.additional_options = [] db.invoke_save = false end compress_with Gzip do |compression| compression.best = true compression.fast = false end notify_by Mail do |mail| # ... end store_with S3 do |s3| # ... end end 

हम चालान में विशेष रूप से इनवोक_सेवे को अक्षम करते हैं क्योंकि हम नहीं चाहते कि हर बैकअप के लिए डिस्क पर मुख्य Redis स्ट्रीम को लिखकर अवरुद्ध किया जाए।

निगरानी

मॉनीट का उपयोग निगरानी के लिए किया जाता है, जो होने वाली सभी घटनाओं को सूचित करने के लिए कॉन्फ़िगर किया गया है। इसके लिए सेटिंग्स काफी सरल हैं:

 set mailserver localhost set mail-format { from: monit-app1@example.com } set alert support@example.ru but not on { action pid ppid } check process redis with pidfile /var/run/redis.pid start program = "/usr/bin/redis-server /etc/redis/redis.conf" stop program = "/usr/bin/redis-cli -p 6379 shutdown" group redis 

BGSAVE के साथ स्मृति से बाहर

संग्रहीत डेटा की बड़ी मात्रा के साथ, RDB स्नैपशॉट का उपयोग करने पर समस्याएँ हो सकती हैं। रिकॉर्डिंग के लिए, BGSAVE कमांड का उपयोग किया जाता है , जो वर्तमान प्रक्रिया का एक कांटा बनाता है और इस कांटे में डेटा को डिस्क पर लिखा जाता है। इस प्रकार, मुख्य धारा अवरुद्ध नहीं है और रिकॉर्डिंग अतुल्यकालिक रूप से होती है। समस्या यह है कि UNIX सिस्टम पर, जब कांटा () कहा जाता है, तो पैरेंट प्रक्रिया द्वारा उपयोग की जाने वाली मेमोरी की सामग्री को भी चाइल्ड प्रोसेस में कॉपी किया जाता है। मान लीजिए, यदि Redis वर्तमान में 2Gb मेमोरी पर कब्जा कर लेता है, और सिस्टम में केवल 1Gb मुक्त मेमोरी बनी रहती है, तो BGSAVE कमांड निष्पादित करते समय निम्नलिखित त्रुटि संभव है:

 [१ [६ ९ ६] २ 12: मार्च १२:२६:54 # पृष्ठभूमि में नहीं बचा सकता: कांटा: स्मृति आवंटित नहीं कर सकता

आधुनिक प्रणालियों में, कांटे के लिए मेमोरी कॉपी करते समय, कॉपी ऑन राइट विधि का उपयोग किया जाता है। मेमोरी तब ही कॉपी की जाती है जब रिकॉर्डिंग संबंधित सेक्शन में हो। Redis केवल डेटा को अतुल्य रूप से सहेजने के लिए प्रक्रिया का एक कांटा बनाता है, यह कांटा इसे किसी भी तरह से नहीं बदलता है, जिसका अर्थ है कि हम सिस्टम पैरामीटर vm.overcommit_memory को सुरक्षित रूप से 1 पर सेट कर सकते हैं। यह पैरामीटर उपलब्ध स्मृति से अधिक मेमोरी आवंटित करने के लिए जिम्मेदार है। /Etc/sysctl.conf में लाइन जोड़ें :

 vm.overcommit_memory = 1 

और विन्यास को फिर से बनाएँ:

 # sysctl -p 

इस समस्या के बारे में अधिक जानकारी:

http://groups.google.com/group/redis-db/browse_thread/thread/dc4876861b174358
पृष्ठभूमि की बचत लिनक्स के तहत एक कांटा () त्रुटि के साथ विफल हो रही है, भले ही मैंने बहुत सारी मुफ्त रैम दी हो!