यह समस्या क्यों हुई, जबकि Amazon Aurora स्टोरेज वॉल्यूम अपने आप 64TB तक बढ़ जाएगा।
सबसे पहले, हम RDS Aurora में संग्रहण को समझेंगे। Aurora में 2 प्रकार के स्टोरेज हैं। इंस्टेंस स्टोर स्थानीय भंडारण है जहां अस्थायी वस्तुओं को संग्रहीत किया जाता है और मुख्य संग्रहण डेटा के लिए। इसलिए, जब आप किसी टेबल पर ALTER चलाते हैं, तो यह एक अस्थायी तालिका उत्पन्न करेगा और RDS aurora अस्थायी तालिका को संग्रहीत करने के लिए इंस्टेंस संग्रहण का उपयोग करेगा। आपके उदाहरण के लिए जो db.r3.बड़ा उदाहरण है, इसमें स्थानीय संग्रहण का 1×32 GB है, इसलिए यदि उदाहरण पर आपकी अस्थायी वस्तुएं इस आकार से बड़ी हो जाती हैं, तो आपको “तालिका पूर्ण’ त्रुटि मिलती है। साथ ही, स्थानीय संग्रहण सीमा कुल संग्रहण मात्रा . से भिन्न होती है आपके Aurora इंस्टेंस के लिए उपलब्ध है, और आपके डेटाबेस उपयोग के आधार पर, आपका Amazon Aurora संग्रहण वॉल्यूम 10GB की वृद्धि में, 64 TB तक स्वतः ही बढ़ जाएगा।RDS में बड़ी टेबल पर बदलें तालिका पूर्ण त्रुटि का समाधान
- समस्या को दूर करने के लिए, आप अपने ALTER को चलाने के लिए अधिक स्थानीय संग्रहण प्राप्त करने के लिए इंस्टेंस को बढ़ा सकते हैं, टेबल को बदल सकते हैं और इंस्टेंस प्रकार को छोटा कर सकते हैं। इसके परिणामस्वरूप अपग्रेड/डाउनग्रेड इंस्टेंस प्रकार के दौरान कुछ डाउनटाइम होता है।
- आप "pt-online-schema-change" कमांड का भी उपयोग कर सकते हैं, यदि आप इस कमांड का उपयोग करते हैं तो यह बिना डाउनटाइम के उपयोग के लिए मूल तालिका को अभी भी उपलब्ध कराता है या कोई टेबल लॉक नहीं।
परिणाम:
अगर आप तालिका को pt . से बदल रहे हैं -ऑनलाइन-स्कीमा-परिवर्तन आदेश एक तालिका जिसका आकार 35-40GB है तो इसमें लगभग 30 घंटे लग सकते हैं।पीटी-ऑनलाइन-स्कीमा-परिवर्तन टेबल को लॉक नहीं करता है। यह आदेश मूल तालिका पर ट्रिगर बनाता है। लेकिन इसके लिए इसे सुपरयूजर प्रिविलेज की जरूरत होती है। जब आप स्टोर प्रक्रिया का उपयोग कर रहे हैं तो आपको त्रुटि मिलेगी:पीटी-ऑनलाइन-स्कीमा-परिवर्तन कमांड का उपयोग क्यों करें और सक्षम क्यों करें “log_bin_trust_function_creators“ डीबी पैरामीटर समूह में? ?
#1419 - आपके पास सुपर विशेषाधिकार नहीं है और बाइनरी लॉगिंग सक्षम है (आप *कम सुरक्षित log_bin_trust_function_creators चर का उपयोग करना चाहते हैंकारण: यह त्रुटि RDS इंस्टेंस पर तब होती है जब आप "संग्रहीत कार्यविधियाँ" का उपयोग करने का प्रयास करते हैं। आपको जल्द ही पता चल जाएगा कि किसी उपयोगकर्ता के लिए सुपर विशेषाधिकार देने से काम नहीं चलेगा। तो चीजों को काम करने का एकमात्र तरीका है log_bin_trust_function_creators को 1 पर सेट करना। Percona दस्तावेज़ों के अनुसार: बाइनरी लॉग सक्षम सर्वर पर ट्रिगर बना रहा है जिसके लिए सुपर विशेषाधिकार वाले उपयोगकर्ता की आवश्यकता होती है (जो अमेज़ॅन आरडीएस में असंभव है)। त्रुटि संदेश समाधान निर्दिष्ट करता है। हमें डीबी पैरामीटर समूह "log_bin_trust_function_creators" में चर को सक्षम करने की आवश्यकता है। इसे सक्षम करना सर्वर से कहने जैसा है: “मुझे नियमित उपयोगकर्ताओं के ट्रिगर और कार्यों पर भरोसा है, और यह कि वे समस्याएँ पैदा नहीं करेंगे, इसलिए मेरे उपयोगकर्ताओं को उन्हें बनाने की अनुमति दें।” चूंकि डेटाबेस की कार्यक्षमता नहीं बदलेगी, यह आपके उपयोगकर्ताओं पर भरोसा करने का मामला बन जाता है। log_bin_trust_function_creators एक वैश्विक चर है जिसे गतिशील रूप से बदला जा सकता है। जब आप MySQL डेटाबेस की उपयोगकर्ता तालिका में उपयोगकर्ताओं की अनुमतियों की जाँच करते हैं, तो "Super_priv" पर अधिक विवरण खोजने का प्रयास कर रहे हैं। आप देख सकते हैं कि Super_priv rdsadmin उपयोगकर्ता को छोड़कर किसी के लिए भी सेट नहीं है।
MySQL> select User,Super_priv from user; +-----------+------------+ | User | Super_priv | +-----------+------------+ | rdsadmin | Y | | root | N | | dbuser | N | +-----------+------------+ 3 rows in set (0.00 sec)
यहाँ "रूट" मास्टर उपयोगकर्ता है और "dbuser" DB उपयोगकर्ता है, ये उपयोगकर्ता हमारे द्वारा बनाए गए हैं और "rdsadmin" उपयोगकर्ता स्वचालित रूप से AWS द्वारा बनाया गया है, जिसकी हमारे पास इस उपयोगकर्ता तक पहुंच नहीं है। rdsadmin MySQL उपयोगकर्ता का उपयोग Amazon द्वारा रखरखाव और प्रबंधन कार्य के लिए किया जाता है।
यह ट्यूटोरियल का अंत है, आरडीएस सॉल्यूशन में टेबल फुल एरर में बिग टेबल को कैसे बदलें।
