मेरे अमेज़ॅन अरोरा क्लस्टर पर हमेशा "वॉल्यूम बाइट्स" का उपयोग क्यों किया जाता है?


11

मेरे पास एक अमेज़ॅन (AWS) औरोरा डीबी क्लस्टर है, और हर दिन, इसकी [Billed] Volume Bytes Usedवृद्धि हो रही है।

VolumeBytesUsed समय के साथ CloudWatch मीट्रिक

मैंने INFORMATION_SCHEMA.TABLESतालिका का उपयोग करके अपनी सभी तालिकाओं (उस क्लस्टर में अपने सभी डेटाबेस में) का आकार जाँच लिया है :

SELECT ROUND(SUM(data_length)/1024/1024/1024) AS data_in_gb, ROUND(SUM(index_length)/1024/1024/1024) AS index_in_gb, ROUND(SUM(data_free)/1024/1024/1024) AS free_in_gb FROM INFORMATION_SCHEMA.TABLES;
+------------+-------------+------------+
| data_in_gb | index_in_gb | free_in_gb |
+------------+-------------+------------+
| 30         | 4           | 19         |
+------------+-------------+------------+

कुल: 53GB

तो मुझे इस समय लगभग 75GB बिल क्यों दिया जा रहा है?

मैं समझता हूं कि प्रोविजनल स्पेस को कभी मुक्त नहीं किया जा सकता है, उसी तरह जैसे कि नियमित MySQL सर्वर पर आईबीडीटा फाइल्स कभी भी सिकुड़ नहीं सकती हैं; आई 'म ओके विद दैट। यह प्रलेखित है, और स्वीकार्य है।

मेरी समस्या यह है कि हर दिन, मेरे द्वारा बिल की गई जगह बढ़ जाती है। और मुझे यकीन है कि मैं अस्थायी रूप से 75GB स्थान का उपयोग नहीं कर रहा हूं। अगर मैं ऐसा कुछ करता, तो मैं समझ जाता। यह ऐसा है जैसे मेरी टेबल से पंक्तियों को हटाकर, या ड्रापिंग टेबल, या यहां तक ​​कि डेटाबेस को छोड़ने के द्वारा स्टोरेज स्पेस मैं मुक्त हो रहा हूं, कभी भी पुन: उपयोग नहीं किया जाता है।

मैंने कई बार AWS (प्रीमियम) समर्थन से संपर्क किया है, और ऐसा क्यों है, इस बारे में अच्छी व्याख्या करने में सक्षम नहीं था।
मुझे उन OPTIMIZE TABLEतालिकाओं पर चलने के सुझाव मिले हैं, जिन पर free_space( INFORMATION_SCHEMA.TABLESतालिका के अनुसार ) बहुत कुछ है , या इनोबीडी इतिहास की लंबाई की जांच करने के लिए, यह सुनिश्चित करने के लिए कि हटाए गए डेटा को अभी भी रोलबैक खंड में नहीं रखा गया है (संदर्भ: MVCC ) , और यह सुनिश्चित करने के लिए कि रोलबैक सेगमेंट को खाली कर दिया गया है, उदाहरण को पुनः आरंभ करें।
उन लोगों में से किसी ने मदद नहीं की।

जवाबों:


19

यहां खेलने के लिए कई चीजें हैं ...

  1. प्रत्येक तालिका अपने स्वयं के टेबलस्पेस में संग्रहीत होती है

    डिफ़ॉल्ट रूप से, अरोड़ा समूहों (नामित default.aurora5.6) के लिए पैरामीटर समूह परिभाषित करता है innodb_file_per_table = ON। इसका अर्थ है कि प्रत्येक तालिका एक अलग फ़ाइल में संग्रहीत है, औरोरा भंडारण क्लस्टर पर। आप देख सकते हैं कि इस क्वेरी का उपयोग करके आपके प्रत्येक टेबल के लिए कौन से टेबलस्पेस का उपयोग किया गया है:

    SELECT name, space FROM INFORMATION_SCHEMA.INNODB_SYS_TABLES;

    नोट: मैंने बदलने की कोशिश नहीं की innodb_file_per_tableहै OFF। शायद इससे मदद मिलेगी ..?

  2. तालिकाओं को हटाकर मुक्त किया गया संग्रहण स्थान पुन: उपयोग नहीं किया जाता है

    AWS प्रीमियम समर्थन का हवाला देते हुए:

    अरोरा स्टोरेज इंजन के अनूठे डिज़ाइन के कारण इसके प्रदर्शन और दोष सहिष्णुता को बढ़ाने के लिए अरोरा में मानक MySQL के समान फ़ाइल-प्रति-टेबल तालिकाओं को डीफ़्रैग्मेन्ट करने की कार्यक्षमता नहीं है।

    वर्तमान में अरोरा दुर्भाग्य से टेबलस्पेस को सिकोड़ने का एक तरीका नहीं है क्योंकि मानक MySQL करता है और सभी खंडित स्थान चार्ज किए जाते हैं क्योंकि यह वॉल्यूमबाइट्स में शामिल है।
    कारण यह है कि अरोड़ा एक गिराई गई तालिका के स्थान को उसी तरह से पुनः प्राप्त नहीं कर सकता है जैसा कि मानक MySQL है कि तालिका के लिए डेटा को पूरी तरह से अलग तरीके से मानक MySQL डेटाबेस में एकल संग्रहण वॉल्यूम के साथ संग्रहीत किया जाता है।

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

    लेकिन उस व्यर्थ स्थान को फिर से उपयोग करने के लिए कुछ अस्पष्ट तरीका है ...
    फिर से, AWS प्रीमियम समर्थन को उद्धृत करें:

    एक बार जब आपका कुल डेटा सेट एक निश्चित आकार (लगभग 160 जीबी) से अधिक हो जाता है, तो आप फिर से उपयोग के लिए 160 जीबी ब्लॉक में जगह को पुनः प्राप्त करना शुरू कर सकते हैं जैसे कि यदि आपके अरोरा क्लस्टर वॉल्यूम में 400 जीबी है और डीआरओपी 160 जीबी या इससे अधिक टेबल अरोरा हो सकता है स्वचालित रूप से 160 GB डेटा का पुनः उपयोग करें। हालाँकि यह इस स्थान को पुनः प्राप्त करने के लिए धीमा हो सकता है।
    बड़ी मात्रा में डेटा को एक बार में मुक्त करने के लिए आवश्यक कारण मानक MySQL के विपरीत एंटरप्राइज़ स्केल DB इंजन के रूप में औरोरस अद्वितीय डिजाइन के कारण है जो इस पैमाने पर उपयोग नहीं किया जा सकता है।

  3. वैकल्पिक बुराई बुराई है!

    क्योंकि ऑरोरा MySQL 5.6 पर आधारित है, OPTIMIZE TABLEको मैप किया जाता है ALTER TABLE ... FORCE, जो इंडेक्स स्टैटिस्टिक्स को अपडेट करने के लिए टेबल को रिस्ट्रिक्ट करता है और क्लस्टर इंडेक्स में फ्री अनयूज्ड स्पेस देता है। प्रभावी रूप से, के साथ innodb_file_per_table = ON, इसका मतलब है कि OPTIMIZE TABLEएक नया टेबलस्पेस फाइल बनाता है, और पुराने को हटा देता है। चूँकि एक टेबलस्पेस फ़ाइल को हटाने के लिए उपयोग किए जा रहे भंडारण को खाली नहीं किया जाता है, इसका मतलब है कि OPTIMIZE TABLEहमेशा अधिक भंडारण का प्रावधान किया जाएगा। आउच!

    रेफरी: https://dev.mysql.com/doc/refman/5.6/en/optimize-table.html#optimize-table-innodb-details

  4. अस्थायी तालिकाओं का उपयोग करना

    डिफ़ॉल्ट रूप से, अरोड़ा उदाहरणों के लिए पैरामीटर समूह (नामित default.aurora5.6) परिभाषित करता है default_tmp_storage_engine = InnoDB। इसका मतलब है कि हर बार जब मैं एक TEMPORARYटेबल बना रहा हूं , तो यह मेरी सभी नियमित तालिकाओं के साथ, औरा स्टोरेज क्लस्टर पर संग्रहीत है। इसका मतलब है कि उन तालिकाओं को रखने के लिए नए स्थान का प्रावधान किया गया है, इस प्रकार कुल VolumeBytesUsed में वृद्धि हुई है।
    इसके लिए समाधान काफी सरल है: default_tmp_storage_engineपैरामीटर मान को बदल दें MyISAM। यह अरोरा को TEMPORARYउदाहरण के स्थानीय भंडारण पर तालिकाओं को बनाने के लिए मजबूर करेगा ।
    ध्यान दें: उदाहरणों का स्थानीय भंडारण सीमित है; देखने Free Local Storageको देखने के लिए कितने संग्रहण अपने इंस्टेंस CloudWatch पर मीट्रिक। बड़े (महंगा) उदाहरणों में अधिक स्थानीय भंडारण है।

    रेफरी: अभी तक कोई नहीं; वर्तमान अमेज़ॅन अरोड़ा प्रलेखन में इसका उल्लेख नहीं है। मैंने दस्तावेज़ीकरण को अपडेट करने के लिए AWS समर्थन टीम से पूछा, और यदि वे एक बार मेरे उत्तर को अपडेट कर देंगे।


1
यह एक महान जवाब है, और येवच , वे कुछ प्रमुख कैवियट हैं। खुशी है कि मैंने यह देखा।
सिजॉयज

डिट्टो। एक DB सर्वर को सूचित किया गया था 300 GB तक, MySQL के साथ 54 GB के रिपोर्ट आकार के लिए ... यदि अंतरिक्ष को कभी भी पुनः प्राप्त नहीं किया गया है, तो यह एक अच्छा उदाहरण है कि जब आपके पास अक्सर लिखित-टेबल ( जैसे लॉग टेबल, इंडेक्स टेबल आदि)।
geerlingguy

0

जब ऑरोरा डेटा हटा दिया जाता है, जैसे कि एक टेबल या विभाजन को हटाकर, समग्र आवंटित स्थान समान रहता है। भविष्य में डेटा की मात्रा बढ़ने पर मुक्त स्थान का पुन: उपयोग होता है। https://docs.amazonaws.cn/en_us/AmazonRDS/latest/AuroraUserGuide/Aurora.Managing.Performance.html

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.