क्या उच्च ट्रैफ़िक डेटाबेस सर्वर पर बहुत अधिक हार्ड ड्राइव होना बुरा है?

Question

एक उच्च यातायात उत्पादन डेटाबेस सर्वर के लिए MySQL के साथ एक Ubuntu सर्वर चल रहा है। MySQL उदाहरण के अलावा मशीन पर और कुछ नहीं चल रहा है।

हम DB डेटाबेस पर दैनिक डेटाबेस बैकअप संग्रहीत करते हैं, क्या कोई प्रदर्शन हिट या कारण है कि हमें हार्ड डिस्क को अपेक्षाकृत खाली क्यों रखना चाहिए? यदि डेटाबेस और सभी बैकअप के साथ डिस्क को 86% + तक भर दिया जाता है, तो क्या यह प्रदर्शन को नुकसान पहुंचाता है?

तो क्या 86-90% + पूर्ण क्षमता के साथ चलने वाला DB सर्वर केवल 10% पूर्ण डिस्क के साथ चलने वाले सर्वर की तुलना में किसी भी तरह से कम प्रदर्शन करेगा?

सर्वर पर कुल डिस्क आकार 1 टीबी से अधिक है, इसलिए डिस्क के 10% भी बुनियादी ओ / एस स्वैपिंग और इस तरह के लिए पर्याप्त होना चाहिए।

Comments

रूट (/) के समान समान डेटा पर MySQL डेटा? तुम सच में नहीं चाहते कि भरने के लिए; दुर्घटनाग्रस्त शहर।

— ग्रेविफेस

मुझे नहीं लगता कि जब तक डेटा को अच्छी तरह से प्रबंधित किया जा रहा है तब तक डिस्क स्थान को साफ रखने का कोई अंतर्निहित कारण नहीं है। जिसमें से बोलते हुए, आप स्थानीय स्तर पर क्यों समर्थन कर रहे हैं? पहली बात मैं उन बैकअप को किसी अन्य बॉक्स में बंद कर दूंगा।

— BenC

ध्यान रखें कि लगभग पूर्ण डिस्क में डेटाबेस के आधार पर सेवाओं के लिए डाउनटाइम जोखिम होता है। यदि DB डिस्क फुल है तो DB बंद हो जाएगा। इसलिए कम जगह पर बाईं ओर जाने से उच्च डाउनटाइम जोखिम होगा।

— मिस्टर

Answer 1

सबसे पहले आप अपने डेटाबेस बैकअप को अपने डेटाबेस के समान भौतिक ड्राइव या RAID समूह पर नहीं रखना चाहते हैं। इसका कारण यह है कि एक डिस्क विफलता (यदि आप बिना किसी RAID संरक्षण के चल रहे हैं) या एक भयावह RAID विफलता (यदि आप RAID-1 या RAID-5 का उपयोग कर रहे हैं) तो आप अपने डेटाबेस और अपने डेटाबेस बैकअप खो देंगे।

डिस्क प्रदर्शन के बारे में आपका प्रश्न यह बताता है कि डिस्क ड्राइव पूर्ण कैसे निर्भर करता है कि डिस्क पर डेटा कैसे एक्सेस किया जाता है। स्पिनिंग डिस्क के लिए दो भौतिक कारक हैं जो I / O प्रदर्शन को प्रभावित करते हैं। वो हैं:

• समय की तलाश - वह समय है जो डिस्क ड्राइव को अपने वर्तमान ट्रैक स्थान से ट्रैक पर ले जाने के लिए अनुरोधित डेटा को ट्रैक करता है।

• घूर्णी विलंबता - जो वांछित डेटा को ड्राइव हेड के रूप में रीड हेड तक पहुंचने में औसत समय लगता है - 15K RPM ड्राइव के लिए यह 2 एमएस (मिलीसेकंड) है

आपका ड्राइव कितना भरा हुआ है यह आपके सर्वर के I / Os के अनुभव के औसत समय को प्रभावित कर सकता है। उदाहरण के लिए, यदि आपकी ड्राइव भरी हुई है और आपके पास डेटाबेस टेबल्स हैं जो डिस्क के प्लेटर्स के चरम विपरीत छोरों पर ड्राइव पर शारीरिक रूप से स्थित हैं, तो जैसा कि आप इन तालिकाओं में से प्रत्येक I / Os के डेटा का उपयोग करते हुए I / Os का अनुभव करेंगे। ड्राइव का अधिकतम समय।

हालाँकि, यह कहा जा रहा है कि यदि आपकी ड्राइव भरी हुई है और आपका एप्लिकेशन ड्राइव पर संग्रहीत डेटा का केवल एक छोटा सा अंश एक्सेस करता है और यह सभी डेटा ड्राइव पर संवेग के रूप में स्थित है, तो ये I / Os समय के साथ न्यूनतम रूप से प्रभावित होंगे ।

दुर्भाग्य से, इस प्रश्न का उत्तर है कि "आपका माइलेज अलग-अलग होगा", जिसका अर्थ है कि आपका एप्लिकेशन डेटा तक कैसे पहुंचता है और वह डेटा कहां स्थित है, यह निर्धारित करेगा कि आपका I / O प्रदर्शन क्या होगा।

इसके अलावा, जैसा कि @gravyface द्वारा उल्लेख किया गया है, यह आपके डेटाबेस से आपके ऑपरेटिंग सिस्टम के भंडारण की आवश्यकताओं को अलग करने के लिए "सबसे अच्छा अभ्यास" होगा। फिर से, यह डिस्क की सतह पर सिर की गति को कम करने में मदद करेगा क्योंकि दोनों एक ही ड्राइव पर ड्राइव के ऑपरेशन सिस्टम और डेटाबेस क्षेत्रों के बीच निरंतर मांग कर सकते हैं क्योंकि ऑपरेटिंग सिस्टम और डेटाबेस सॉफ्टवेयर दोनों I / O अनुरोध करते हैं।

Answer 2

यहाँ पर विचार करने के लिए दो कोण हैं: प्रदर्शन और रोबस्टनेस।

प्रदर्शन-वार, आमतौर पर इसके लिए अलग डिस्क स्पिंडल (या RAID समूह / ड्राइव सेट) की सिफारिश की जाती है:

1. ओएस सामान (बायनेरिज़, लॉग्स, होम डाइरेक्टरीज़ आदि)
2. यदि आप स्वैप का उपयोग करने की अपेक्षा नहीं करते हैं, तो स्वैप स्थान (जो 1 के साथ जोड़ा जा सकता है)
3. उत्पादन डीबी
4. उत्पादन DB का लेन-देन लॉग (यदि उपयोग किया जाता है)
5. डेटाबेस डंप / बैकअप

इसके पीछे का तर्क बहुत सीधा है: आप डिब को "अन्य सामान" से प्रभावित नहीं करना चाहते हैं जो डिस्क की मांग करता है (उदाहरण के लिए यदि मशीन भारी रूप से स्वैप करना शुरू कर देती है और स्वैप विभाजन आपके द्वारा डीबी डेटा से डिस्क के दूसरी तरफ है। लंबे डिस्क के साथ संघर्ष करना चाहता है)।

---

एक मजबूती के दृष्टिकोण से आप एक ही तरह का ब्रेकडाउन चाहते हैं, लेकिन एक अलग कारण से: जैसा कि अन्य लोगों ने बताया है कि आप अपने DB और इसके बैकअप दोनों को निकालने के लिए एक असफल डिस्क नहीं चाहते हैं (हालांकि वास्तविक रूप से आपको बैकअप को कॉपी करना चाहिए। वैसे भी सर्वर एक भयावह विफलता की स्थिति में)।

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

Comments

दुख की बात है कि बहुत सारे डिस्ट्रॉफ अभी भी /डिफ़ॉल्ट रूप से uber के साथ विभाजन सेट करते हैं ।

— ग्रेविफेस 20

@gravyface सहमत - मुझे पता है कि उबंटू अब (12.04) आपको उस और ठीक से विभाजित विभाजन लेआउट के बीच विकल्प देता है। निश्चित नहीं है कि यह क्या डिफ़ॉल्ट है, लेकिन IMHO यह सबसे खराब चीजों में से एक हो सकता है लिनक्स ने यूनिक्स समुदाय को नुकसान पहुंचाने के मामले में किया है: दसियों हजार "sysadmins" जो सोचते हैं कि एक भी विशाल /विभाजन पूरी तरह से ठीक है और उन्हें पीछे हटाना है ...

— voretaq7

Answer 3

मैं डेटाबेस और अस्थायी (नीचे देखें) बैकअप को रूट (/) से भिन्न विभाजन पर ले जाने की सलाह दूंगा।

इसके अलावा, आपके (ग्रहण) संपीड़ित डेटाबेस डंप बैकअप के लिए एक समझदार रोटेशन / अवधारण योजना के साथ आते हैं। वहाँ (आमतौर पर) स्थानीय डिस्क पर बैकअप की कई प्रतियां रखने का कोई कारण नहीं है। डिजास्टर रिकवरी के लिए कुछ नहीं करता है और जब ऑफ-साइट ले जाया जाता है, तो डिस्क को हटा देना चाहिए।

यह बहुत मानक संचालन प्रक्रिया है।

Answer 4

इससे मुझे नेटऐप पर एक बग की याद आ गई जहां फाइल सिस्टम जो पूर्ण के पास हैं उनका प्रदर्शन काफी गिर गया था (जैसे आधा)। (माना कि कुछ साल पहले था)।

जैसा कि सभी ने कहा है कि इसका उत्तर निर्भर करता है, लेकिन यह इसके माध्यम से सोचने योग्य है।

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

तीन प्रकार के डेटा हैं जो एक डेटाबेस के लिए हार्ड डिस्क पर बैठते हैं।

1. आपकी वास्तविक डेटाबेस फ़ाइल। यह एक बड़ी प्रचारित फ़ाइल होगी जो आम तौर पर बड़ी मात्रा में विकसित होती है (उदाहरण के लिए 10%)।
2. लॉग्स, आपका ट्रांजेक्शन लॉग जो लगातार लिखा जा रहा है, डिलीट, को लिखा, आदि ...
3. बड़े प्रश्नों के लिए अस्थायी फ़ाइलें जो स्मृति में नहीं चल सकती हैं।

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

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

(3) tempDB, अगर DB को लिखित प्रश्नों के लिए आवश्यक है, या पर्याप्त RAM नहीं है, तो आपको कम डिस्क स्थान की तुलना में बड़ी समस्याएं मिली हैं, जिससे प्रदर्शन समस्याएं पैदा हो सकती हैं, क्योंकि आपका पढ़ा हुआ प्रदर्शन तब डिस्क बाध्य हो सकता है। यदि MySql को tempDB के लिए डिस्क स्थान आवंटित करने की आवश्यकता है और हार्ड डिस्क बाहर भागा है, तो आप आउटेज का जोखिम भी चलाते हैं।

बैकअप के बारे में ...

1. मैंने जिस भी उद्यम में काम किया है, उसी मशीन में बैकअप रखता है। जब एक पुनर्स्थापना की बात आती है (जो बैकअप के बारे में परवाह करता है, तो यह उस गणना को पुनर्स्थापित करता है)। एक ही डिस्क पर db फ़ाइल के सही होने की गति को कुछ भी हरा नहीं सकता है।
2. उम्मीद है कि स्पष्ट है, सुनिश्चित करें कि बैकअप सिर्फ स्थानीय नहीं हैं।

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

1. पुष्टि करते हुए कि मेरे पास पर्याप्त रैम है
2. अपने डीबी से लॉग और सभी क्षणिक डेटा को अलग करना।
3. अपने OS को अलग करते हुए, आपका MySql शेष से स्थापित होता है।

यदि आप 1 के लिए अलग स्पिंडल और कंट्रोलर का उपयोग कर सकते हैं।

अलग-अलग स्पिंडल द्वारा पीछा किया गया

एक गरीब आदमी के अलग-अलग विभाजन के बाद।

Answer 5

मुझे हाल ही में ऐसी ही समस्या हुई थी जब मैंने अपने एक प्रतिकृति सर्वर पर सभी डिस्क स्थान का उपयोग किया था। तत्काल प्रभाव दुर्घटना की प्रतिकृति के लिए था और फिर मैं MySQL में लॉग इन नहीं कर सका क्योंकि mysqld.sock फ़ाइल नहीं खोली जा सकी।