MySQL और MariaDB के लिए क्षमता योजना - आयाम भंडारण आकार

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

इस ब्लॉग पोस्ट में, हम यह देखने जा रहे हैं कि शुरू में आपके स्टोरेज स्पेस को कैसे आकार दिया जाए, और फिर अपने MySQL या MariaDB डेटाबेस के विकास का समर्थन करने की क्षमता की योजना बनाई जाए।

MySQL डिस्क स्थान का उपयोग कैसे करता है

MySQL एक विशिष्ट निर्देशिका के तहत हार्ड डिस्क पर फ़ाइलों में डेटा संग्रहीत करता है जिसमें सिस्टम चर "डेटादिर" होता है। डेटादिर . की सामग्री MySQL सर्वर संस्करण, और लोड किए गए कॉन्फ़िगरेशन पैरामीटर और सर्वर चर (उदा., General_log, slow_query_log, बाइनरी लॉग) पर निर्भर करेगा।

वास्तविक भंडारण और पुनर्प्राप्ति जानकारी भंडारण इंजन पर निर्भर है। MyISAM इंजन के लिए, तालिका की अनुक्रमणिका .MYI फ़ाइल में, डेटा निर्देशिका में, तालिका के लिए .MYD और .frm फ़ाइलों के साथ संग्रहीत की जाती है। InnoDB इंजन के लिए, इंडेक्स को टेबल के साथ टेबल स्पेस में स्टोर किया जाता है। अगर innodb_file_per_table विकल्प सेट है, अनुक्रमणिका .frm फ़ाइल के साथ तालिका की .ibd फ़ाइल में होगी। मेमोरी इंजन के लिए, डेटा मेमोरी (हीप) में संग्रहीत होता है जबकि संरचना डिस्क पर .frm फ़ाइल में संग्रहीत होती है। आगामी MySQL 8.0 में, मेटाडेटा फ़ाइलें (.frm, .par, dp.opt) नई डेटा डिक्शनरी स्कीमा की शुरुआत के साथ हटा दी जाती हैं।

यह नोट करना महत्वपूर्ण है कि यदि आप तालिका डेटा संग्रहीत करने के लिए InnoDB साझा तालिका स्थान का उपयोग कर रहे हैं (innodb_file_per_table=OFF ), आपके द्वारा डेटा की विशाल पंक्तियों को छोटा करने या हटाने के बाद भी आपके MySQL भौतिक डेटा का आकार लगातार बढ़ने की उम्मीद है। इस कॉन्फ़िगरेशन में खाली स्थान को पुनः प्राप्त करने का एकमात्र तरीका निर्यात करना, मौजूदा डेटाबेस को हटाना और उन्हें mysqldump के माध्यम से वापस आयात करना है। इस प्रकार, innodb_file_per_table=ON . को सेट करना महत्वपूर्ण है यदि आप डिस्क स्थान के बारे में चिंतित हैं, तो तालिका को छोटा करते समय, स्थान को पुनः प्राप्त किया जा सकता है। साथ ही, इस कॉन्फ़िगरेशन के साथ, एक विशाल DELETE ऑपरेशन डिस्क स्थान को तब तक खाली नहीं करेगा जब तक कि OPTIMIZE TABLE को बाद में निष्पादित नहीं किया जाता है।

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

डेटाबेस आकार अनुमान

आकार का आकलन करने का मूल तरीका समय में दो अलग-अलग बिंदुओं के बीच वृद्धि अनुपात का पता लगाना है, और फिर वर्तमान डेटाबेस आकार के साथ गुणा करना है। इस उद्देश्य के लिए अपने पीक-आवर्स डेटाबेस ट्रैफ़िक को मापना सर्वोत्तम अभ्यास नहीं है, और यह संपूर्ण रूप से आपके डेटाबेस उपयोग का प्रतिनिधित्व नहीं करता है। एक बैच ऑपरेशन या एक संग्रहीत प्रक्रिया के बारे में सोचें जो आधी रात को या सप्ताह में एक बार चलती है। मध्यरात्रि में हाउसकीपिंग ऑपरेशन द्वारा संभवतः सिकुड़ने से पहले, आपका डेटाबेस संभावित रूप से सुबह में महत्वपूर्ण रूप से बढ़ सकता है।

इस माप के लिए आधार तत्व के रूप में हमारे बैकअप का उपयोग करने का एक संभावित तरीका है। Percona Xtrabackup, MariaDB बैकअप और फाइलसिस्टम स्नैपशॉट जैसे भौतिक बैकअप तार्किक बैकअप की तुलना में आपके डेटाबेस आकार का अधिक सटीक प्रतिनिधित्व देंगे, क्योंकि इसमें डेटाबेस और इंडेक्स की बाइनरी कॉपी होती है। Mysqldump जैसा तार्किक बैकअप केवल SQL कथनों को संग्रहीत करता है जिन्हें मूल डेटाबेस ऑब्जेक्ट परिभाषाओं और तालिका डेटा को पुन:पेश करने के लिए निष्पादित किया जा सकता है। फिर भी, आप अभी भी mysqldump बैकअप की तुलना करके एक अच्छा विकास अनुपात प्राप्त कर सकते हैं।

डेटाबेस आकार का अनुमान लगाने के लिए हम निम्न सूत्र का उपयोग कर सकते हैं:

कहां,

• बी - वर्तमान सप्ताह पूर्ण बैकअप आकार,
• बी - पिछले सप्ताह पूर्ण बैकअप आकार,
• डीबी<उप>डेटा - कुल डेटाबेस डेटा आकार,
• डीबी<उप>अनुक्रमणिका - कुल डेटाबेस इंडेक्स आकार,
• 52 - एक वर्ष में सप्ताहों की संख्या,
• वाई - वर्ष।

एमबी में कुल डेटाबेस आकार (डेटा और इंडेक्स) की गणना निम्नलिखित कथनों का उपयोग करके की जा सकती है:

mysql> SELECT ROUND(SUM(data_length + index_length) / 1024 / 1024, 2) "DB Size in MB" FROM information_schema.tables;
+---------------+
| DB Size in MB |
+---------------+
|       2013.41 |
+---------------+

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

साथ ही, innodb_log_file_size . का हिसाब देना न भूलें x 2, innodb_data_file_path और गैलेरा क्लस्टर के लिए, gcache.size जोड़ें मूल्य।

द्विआधारी लॉग आकार अनुमान

प्रतिकृति और पॉइंट-इन-टाइम पुनर्प्राप्ति उद्देश्यों के लिए MySQL मास्टर द्वारा बाइनरी लॉग उत्पन्न किए जाते हैं। यह लॉग फ़ाइलों का एक सेट है जिसमें MySQL सर्वर पर किए गए डेटा संशोधनों के बारे में जानकारी होती है। बाइनरी लॉग का आकार लेखन कार्यों की संख्या और बाइनरी लॉग प्रारूप - STATEMENT, ROW या MIXED पर निर्भर करता है। स्टेटमेंट-आधारित बाइनरी लॉग आमतौर पर पंक्ति-आधारित बाइनरी लॉग की तुलना में बहुत छोटे होते हैं, क्योंकि इसमें केवल राइट स्टेटमेंट होते हैं जबकि रो-बेस्ड में संशोधित पंक्तियों की जानकारी होती है।

बाइनरी लॉग के अधिकतम डिस्क उपयोग का अनुमान लगाने का सबसे अच्छा तरीका है कि एक दिन के लिए बाइनरी लॉग आकार को मापें और इसे expire_logs_days से गुणा करें। मान (डिफ़ॉल्ट 0 है - कोई स्वचालित निष्कासन नहीं)। expire_logs_days . सेट करना महत्वपूर्ण है ताकि आप आकार का सही अनुमान लगा सकें। डिफ़ॉल्ट रूप से, MySQL के बाइनरी लॉग फ़ाइल को घुमाने से पहले प्रत्येक बाइनरी लॉग को 1GB के आसपास कैप किया जाता है। हम इस अनुमान के उद्देश्य के लिए केवल बाइनरी लॉग को फ्लश करने के लिए MySQL ईवेंट का उपयोग कर सकते हैं।

सबसे पहले, सुनिश्चित करें कि event_scheduler वैरिएबल सक्षम है:

mysql> SET GLOBAL event_scheduler = ON;

फिर, एक विशेषाधिकार प्राप्त उपयोगकर्ता के रूप में (ईवेंट और रीलोड विशेषाधिकारों के साथ), निम्न ईवेंट बनाएं:

mysql> USE mysql;
mysql> CREATE EVENT flush_binlog
ON SCHEDULE EVERY 1 HOUR STARTS CURRENT_TIMESTAMP ENDS CURRENT_TIMESTAMP + INTERVAL 2 HOUR
COMMENT 'Flush binlogs per hour for the next 2 hours'
DO FLUSH BINARY LOGS;

एक लेखन-गहन कार्यभार के लिए, आपको संभवतः अंतराल को 30 मिनट या 10 मिनट तक छोटा करना होगा, इससे पहले कि बाइनरी लॉग 1GB अधिकतम आकार तक पहुंच जाए, फिर आउटपुट को एक घंटे तक गोल कर दें। फिर निम्न कथन का उपयोग करके ईवेंट की स्थिति सत्यापित करें और LAST_EXECUTED कॉलम देखें:

mysql> SELECT * FROM information_schema.events WHERE event_name='flush_binlog'\G
       ...
       LAST_EXECUTED: 2018-04-05 13:44:25
       ...

फिर, अब हमारे पास मौजूद बाइनरी लॉग पर एक नज़र डालें:

mysql> SHOW BINARY LOGS;
+---------------+------------+
| Log_name      | File_size  |
+---------------+------------+
| binlog.000001 |        146 |
| binlog.000002 | 1073742058 |
| binlog.000003 | 1073742302 |
| binlog.000004 | 1070551371 |
| binlog.000005 | 1070254293 |
| binlog.000006 |  562350055 | <- hour #1
| binlog.000007 |  561754360 | <- hour #2
| binlog.000008 |  434015678 |
+---------------+------------+

इसके बाद हम अपने बाइनरी लॉग ग्रोथ के औसत की गणना कर सकते हैं जो लगभग ~562 एमबी प्रति घंटा . है पीक आवर्स के दौरान। इस मान को 24 घंटे और expire_logs_days . से गुणा करें मूल्य:

mysql> SELECT (562 * 24 * @@expire_logs_days);
+---------------------------------+
| (562 * 24 * @@expire_logs_days) |
+---------------------------------+
|                           94416 |
+---------------------------------+

हमें 94416 एमबी मिलेगी जो लगभग ~95 जीबी . है हमारे बाइनरी लॉग के लिए डिस्क स्थान का। दास के रिले लॉग मूल रूप से मास्टर के बाइनरी लॉग के समान होते हैं, सिवाय इसके कि वे दास पक्ष पर संग्रहीत होते हैं। इसलिए, यह गणना दास रिले लॉग पर भी लागू होती है।

स्पिंडल डिस्क या सॉलिड स्टेट?

MySQL फ़ाइलों पर दो प्रकार के I/O संचालन होते हैं:

• अनुक्रमिक I/O-उन्मुख फ़ाइलें:
  • InnoDB सिस्टम टेबलस्पेस (ibdata)
  • MySQL लॉग फ़ाइलें:
    • बाइनरी लॉग (binlog.xxxx)
    • REDO लॉग (ib_logfile*)
    • सामान्य लॉग
    • धीमे क्वेरी लॉग
    • त्रुटि लॉग
• यादृच्छिक I/O-उन्मुख फ़ाइलें:
  • InnoDB फ़ाइल-प्रति-तालिका डेटा फ़ाइल (*.ibd) innodb_file_per_table=ON के साथ (डिफ़ॉल्ट)।

सर्वश्रेष्ठ प्रदर्शन के लिए एक उच्च थ्रूपुट डिस्क सबसिस्टम में यादृच्छिक I/O-ओरिएंटेड फ़ाइलों को रखने पर विचार करें। यह फ्लैश ड्राइव हो सकता है - या तो SSDs या NVRAM कार्ड, या SAS 15K या 10K जैसे उच्च RPM स्पिंडल डिस्क, हार्डवेयर RAID नियंत्रक और बैटरी-समर्थित इकाई के साथ। अनुक्रमिक I/O-उन्मुख फ़ाइलों के लिए, बैटरी-समर्थित राइट-कैश के साथ HDD पर संग्रहीत करना MySQL के लिए पर्याप्त होना चाहिए। ध्यान दें कि बैटरी खत्म होने पर प्रदर्शन में गिरावट की संभावना है।

हम इस क्षेत्र (डिस्क थ्रूपुट और फ़ाइल आवंटन का आकलन) को एक अलग पोस्ट में कवर करेंगे।

क्षमता योजना और आयाम

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

इसे एक उदाहरण के साथ स्पष्ट करना सबसे अच्छा है। निम्नलिखित परिदृश्य को ध्यान में रखते हुए:

• अगला हार्डवेयर चक्र:3 वर्ष
• वर्तमान डेटाबेस आकार:2013 एमबी
• वर्तमान पूर्ण बैकअप आकार (सप्ताह एन):1177 एमबी
• पिछला पूर्ण बैकअप आकार (सप्ताह एन-1):936 एमबी
• डेल्टा आकार:241MB प्रति सप्ताह
• डेल्टा अनुपात:प्रति सप्ताह 25.7% की वृद्धि
• 3 वर्षों में कुल सप्ताह:156 सप्ताह
• कुल डेटाबेस आकार अनुमान:((1177 - 936) x 2013 x 156)/936 =80856 एमबी ~ 81 जीबी 3 साल बाद

यदि आप बाइनरी लॉग का उपयोग कर रहे हैं, तो इसे पिछले अनुभाग में प्राप्त मूल्य से जोड़ दें:

• 81 + 95 =176 जीबी स्टोरेज डेटाबेस और बाइनरी लॉग के लिए।

परिचालन और रखरखाव कार्यों के लिए कम से कम 100% अधिक जगह जोड़ें (स्थानीय बैकअप, डेटा स्टेजिंग, त्रुटि लॉग, ऑपरेटिंग सिस्टम फ़ाइलें, आदि):

• 176 + 176 =352 जीबी कुल डिस्क स्थान।

इस अनुमान के आधार पर, हम यह निष्कर्ष निकाल सकते हैं कि हमें अपने डेटाबेस के लिए 3 वर्षों के लिए कम से कम 352 GB डिस्क स्थान की आवश्यकता होगी। आप इस मान का उपयोग अपनी नई हार्डवेयर खरीद को सही ठहराने के लिए कर सकते हैं। उदाहरण के लिए, यदि आप एक नया समर्पित सर्वर खरीदना चाहते हैं, तो आप बैटरी-समर्थित RAID नियंत्रक के साथ 6 x 128 SSD RAID 10 का विकल्प चुन सकते हैं जो आपको कुल डिस्क स्थान का लगभग 384 GB देगा। या, यदि आप क्लाउड पसंद करते हैं, तो आप हमारे 81GB डेटाबेस उपयोग के लिए प्रावधानित IOPS के साथ 100GB ब्लॉक स्टोरेज प्राप्त कर सकते हैं और हमारे 95GB बाइनरी लॉग और अन्य परिचालन उपयोग के लिए मानक लगातार ब्लॉक स्टोरेज का उपयोग कर सकते हैं।

हैप्पी डाइमेंशन!