एडब्ल्यूएस आरडीएस भंडारण बढ़ाने के लिए डाउनटाइम?

Question

मैं दो आरडीएस इंस्टेंसेस (केवल स्टोरेज स्पेस आवंटित किया गया है, न कि इंस्टेंस टाइप या अन्य पैरामीटर) के स्टोरेज को बढ़ाना चाहता हूं। पर दस्तावेज़ https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_PIOPS.StorageTypes.html#USER_PIOPS.ModifyingExisting पता चलता है:

आप मानक स्टोरेज से प्रोविज़न किए गए IOPS स्टोरेज में, या प्रोविज़न किए गए IOPS से स्टैंडर्ड स्टोरेज में बदल सकते हैं, साथ ही स्टोरेज को बढ़ा सकते हैं, जिसमें थोड़ा भी डाउनटाइम नहीं है।

मैं निश्चित रूप से परिवर्तन करने से पहले एक रखरखाव विंडो को शेड्यूल करूंगा। लेकिन इस क्षेत्र में प्रलेखन थोड़ा अस्पष्ट लगता है। किसी ऐसे व्यक्ति के लिए, जिसने पहले ऐसा किया हो, "कम टू नो डाउनटाइम" क्या है? क्या मैं 5 सेकंड की उम्मीद कर सकता हूं या यह 5 मिनट की तरह है?

अपडेट जुलाई, 2019:

मैंने लिंक को सही और अद्यतित AWS प्रलेखन में अपडेट किया है (जो टूट गया था)। नए दस्तावेज़ में एक ब्लर्ब है जो मूल प्रश्न का उत्तर देने में मदद करता है:

ज्यादातर मामलों में, स्केलिंग स्टोरेज को किसी आउटेज की आवश्यकता नहीं होती है और यह सर्वर के प्रदर्शन को कम नहीं करता है। DB उदाहरण के लिए संग्रहण आकार को संशोधित करने के बाद, DB आवृत्ति की स्थिति संग्रहण-अनुकूलन है। स्टोरेज संशोधन के बाद DB उदाहरण पूरी तरह से चालू है। हालाँकि, आप छह घंटे के लिए या डीबी उदाहरण स्थिति भंडारण-अनुकूलन, जो भी लंबा हो, के लिए आगे भंडारण संशोधन नहीं कर सकते हैं।

हालाँकि, एक विशेष मामला है यदि आपके पास SQL ​​Server DB आवृत्ति है और नवंबर 2017 से भंडारण कॉन्फ़िगरेशन को संशोधित नहीं किया है। इस मामले में, आपको आवंटित को बढ़ाने के लिए अपने DB उदाहरण को संशोधित करने पर कुछ मिनटों का एक छोटा आउटेज अनुभव हो सकता है। भंडारण। आउटेज के बाद, DB उदाहरण ऑनलाइन है, लेकिन संग्रहण-अनुकूलन स्थिति में है। भंडारण अनुकूलन के दौरान प्रदर्शन को नीचा दिखाया जा सकता है।

Answer 1

सबसे पहले, ध्यान दें कि आप गलत संचालन को देख रहे होंगे - आप वर्णन करते हैं कि आप भंडारण आकार बदलना चाहते हैं , लेकिन भंडारण प्रकार का वर्णन करते हुए प्रलेखन उद्धृत किया है । यह एक महत्वपूर्ण गड़बड़ी है: आरडीएस सलाह देता है कि आप भंडारण आकार बदलने के लिए एक आउटेज का अनुभव नहीं करेंगे, लेकिन आप भंडारण प्रकार बदलने के लिए एक आउटेज का अनुभव करेंगे।

भंडारण आकार बदलने के लिए अपमानित प्रदर्शन की अपेक्षा, जिसकी अवधि और प्रभाव कई कारकों पर निर्भर करेगा:

• आपका RDS उदाहरण प्रकार
• विन्यास
  • क्या यह रखरखाव के दौरान होगा?
  • क्या ये परिवर्तन आपके मल्टी-एज़ ग़ुलाम पर सबसे पहले होंगे, और फिर असफल होंगे?
• वर्तमान डेटाबेस का आकार
• उम्मीदवार डेटाबेस का आकार
• आपके अनुरोधित उपलब्धता क्षेत्र में, आपके अनुरोधित क्षेत्र में दिन के इस अनुरोध को संभालने के लिए AWS क्षमता
• इंजन प्रकार ( अमेज़ॅन अरोरा उपयोगकर्ताओं के लिए , स्टोरेज परिवर्धन को आरडीएस द्वारा प्रबंधित किया जाता है, 10 जीबी वेतन वृद्धि में आवश्यक है, इसलिए यह चर्चा मूक है)

इसे ध्यान में रखते हुए, आप अपने आप को, अपने परिवेश में और अपनी शर्तों पर यह परीक्षण करके बेहतर कार्य करेंगे। निम्नलिखित के साथ प्रयोग करने का प्रयास करें:

• अपने मौजूदा उदाहरण के स्नैपशॉट से एक नया आरडीएस उदाहरण बहाल करना, और नए क्लोन पर इस ऑपरेशन को करना।
• इस क्लोन के साथ:
  • दिन के अलग-अलग समय पर आकार बढ़ाएँ, जब आप AWS पर एक अलग भार की अपेक्षा करेंगे।
  • विभिन्न आकारों में वृद्धि।
  • मल्टी-AZ के साथ इसे आज़माएं। देखें कि क्या आपका वास्तविक डाउनटाइम मल्टी-एज को सक्षम न करने की तुलना में बदलता है।
  • एक रखरखाव विंडो के दौरान इसे आज़माएं, और तुरंत परिवर्तन लागू करने के साथ इसकी तुलना करें।

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

यदि आप अभी भी "बॉलपार्क" उत्तर की तलाश कर रहे हैं, तो मैं मिनटों के दायरे में कम से कम प्रदर्शन में गिरावट के लिए योजना बनाने की सलाह दूंगा, सेकंड नहीं - फिर से आपके पर्यावरण और कॉन्फ़िगरेशन पर बहुत निर्भर करता हूं।

संदर्भ के लिए, मैंने हाल ही में शनिवार दोपहर (ईएसटी) में 10GB को 40GB db.m1.small प्रकार के उदाहरण में जोड़ने के लिए इस सटीक ऑपरेशन को लागू किया। उदाहरण लगभग 17 मिनट के लिए "संशोधित" स्थिति में रहा। ध्यान दें कि संशोधित स्थिति वास्तविक डाउनटाइम का वर्णन नहीं करती है, बल्कि ऑपरेशन की अवधि को लागू किया जा रहा है । आप वास्तविक उदाहरण में अतिरिक्त परिवर्तन लागू नहीं कर पाएंगे (हालाँकि आप अभी भी DB तक ही पहुँच सकते हैं) और यह भी अवधि है कि आप किसी भी प्रदर्शन में गिरावट की उम्मीद कर सकते हैं।

यदि आप केवल संग्रहण आकार बदलने की योजना बना रहे हैं, तो आउटेज अनपेक्षित है, लेकिन ध्यान दें कि यह तब हो सकता है जब यह परिवर्तन अन्य परिचालनों के साथ संयोजन में किया जाता है जैसे कि उदाहरण पहचानकर्ता / वर्ग, या संग्रहण प्रकार को बदलना।

Comments

आखिरी पैराग्राफ बहुत ज्यादा है जो मैं था। इससे बहुत मदद मिलती है। धन्यवाद!

— एंडी शिन

जब कोई मुश्किल से ट्रैफ़िक होता है तो मैं सुबह 3 बजे 10GB m3.xlarge DB में 10GB जोड़ने के लिए एक घंटे से अधिक का समय लेता हूं।

— नियो

एक और अधिक डाटापॉइंट, ~ रेखीय की पुष्टि। 100G को 300G DB में जोड़ने में 2 घंटे 50 मिनट का समय लगा।

— जोन स्मिथ

सामान्य उद्देश्य (SSD) और मल्टीजी के साथ db.t2.small पर 10G क्षमता को 100G क्षमता तक बढ़ाने में मेरे लिए केवल 23 मिनट का समय लगा। यह भी ध्यान दें, यदि आप आकार में वृद्धि कर रहे हैं क्योंकि DB पहले से ही पूर्ण है, यह तब तक गैर-कार्यात्मक रहेगा जब तक कि ऑपरेशन समाप्त नहीं हो जाता।

— डेवुर

लोड के तहत PIOPS स्टोरेज की 100 से 200GB तक बढ़ रही है, ~ 10am प्रशांत, के बारे में 30 मिनट लगे और काफी थ्रूपुट / विलंबता को प्रभावित नहीं किया। (इस दौरान IOPS को काफी पढ़ें (लिखें)।

— टेलर ह्यूजेस

Answer 2

जैसा कि आप केवल स्टोरेज का आकार बढ़ा रहे हैं और इंस्टेंस टाइप या किसी अन्य चीज को नहीं बदल रहे हैं तो कोई डाउनटाइम नहीं होना चाहिए, लेकिन ऑपरेशन किए जाने के दौरान 'अपमानित प्रदर्शन' हो सकता है।

आपके द्वारा उद्धृत संदर्भ अस्पष्ट है क्योंकि यह उसी समय भंडारण प्रकार को बदलने पर चर्चा कर रहा है क्योंकि यह भंडारण आकार बदलने पर चर्चा करता है। यदि आप यहां तालिका में 'आवंटित भंडारण' को देखते हैं:

http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Overview.DBInstance.Modifying.html

आप देखेंगे कि यह केवल "प्रदर्शन को नीचा दिखाया जा सकता है" और एक आउटेज के बारे में कुछ भी नहीं (जो यह कहता है कि भंडारण के स्विच करते समय कुछ मामलों में होता है)।

संदर्भ के लिए, जब एक 15GB db.m3.medium MySQL डेटाबेस को कार्यदिवस के दौरान यूरो-पश्चिम -1 में 20GB के लिए बदल रहा है, तो डेटाबेस के लिए मेरे ऐप की कनेक्टिविटी निर्बाध थी। हालाँकि, IOPS को पढ़ना / लिखना दोनों ही 20 मिनट के लिए 400-700 / s के बीच बढ़ गए, इसलिए अपमानित प्रदर्शन का संदर्भ मुझे लगता है। यह एकल-AZ और मल्टी-AZ डेटाबेस इंस्टेंस दोनों के लिए रिपोर्ट किया गया था। (उदाहरण 25 मिनट से थोड़ा अधिक समय के लिए 'संशोधित' के रूप में बताया गया था।)

स्वाभाविक रूप से आप इसे अपने उत्पादन db उदाहरण के रूप में अपने उत्पादन db उदाहरण पर करने से पहले एक db उदाहरण पर आज़मा सकते हैं ताकि आप सुरक्षित रूप से देख सकें कि वास्तविक करने से पहले यह आपकी स्थिति में कैसा व्यवहार करता है।

Comments

स्टोरेज टाइप (मैग्नेटिक <-> gp2 / प्रोविज़न IOPS) बदलने से आउटेज हो जाएगा। वॉल्यूम बढ़ाना, gp2 बदलना <-> प्रावधानित IOPS, या प्रावधान किए गए IOPS को समायोजित करने से आउटेज नहीं होना चाहिए। आप एक वॉल्यूम छोटा नहीं कर सकते।

— 23