🥇फाइल प्रणालीहरूको पातलो प्रावधान Linux२० सेकेन्डमा तीन-टेराबाइट MySQL डाटाबेसको काम गर्ने प्रतिलिपिहरू कसरी बनाउने

मेरो नाम युरी हो, र म सिटीमोबिलमा सिस्टम प्रशासन टोलीको प्रमुख हुँ। आज, म फाइल प्रणालीहरूको लागि थिन प्रोभिजनिङ टेक्नोलोजीसँग काम गर्ने मेरो अनुभव साझा गर्नेछु। Linux कम्पनीको CI/CD प्रक्रियाहरूमा यसलाई कसरी लागू गर्न सकिन्छ भनेर म व्याख्या गर्नेछु। हामी उत्पादनमा डेलिभर गर्दा कोड स्वचालित रूपमा परीक्षण गर्न, हामीलाई उत्पादन संस्करणको नजिकको MySQL डाटाबेसको पढ्ने-लेख्ने प्रतिलिपिहरू आवश्यक पर्ने अवस्थाको जाँच गर्नेछौं।

परिचय: किन नराम्रो सल्लाह दिने?

एक तार्किक प्रश्न, किनभने त्यहाँ परीक्षण वातावरण मा डाटाबेस स्कीमा माइग्रेट गर्न सिद्ध संयन्त्रहरू छन्। किन मुख्य गैर-सार्डेड DBMS लाई त्यस्ता भोल्युमहरूमा विस्तार गर्ने? र सबै डाटा परीक्षणको लागि आवश्यक छैन। म व्याख्या गर्ने प्रयास गर्नेछु।

लगभग एक वर्ष पहिले, हाम्रो ट्याक्सी एग्रीगेटरको सक्रिय वृद्धिको पृष्ठभूमिमा (2018 मा, पूरा यात्राहरू लगभग 15 गुणा बढ्यो), डेटाको मात्रा, सर्भरहरूमा लोड, र रोलआउटहरूको आवृत्ति बढ्यो। हामीले आफूलाई निम्न अवस्थामा भेट्टायौं:

मुख्य MySQL डाटाबेस 1000 TB को लगभग 2,5 तालिकाहरूमा बढ्यो, र बढ्दै गयो।
छिट्टै टुक्रा बन्ने र आधारलाई नष्ट गर्ने कुनै उपाय थिएन। यो पुरानो दृष्टिकोण द्वारा अनुमति दिइएको थिएन "म डाटाबेसमा के चाहन्छु र म कसरी चाहन्छु" लेख्छु, JOIN र आन्तरिक तालिका निर्भरताहरूको गुच्छा।
परीक्षण वातावरणमा डाटाबेस स्कीमा माइग्रेट गर्ने कुनै संयन्त्र थिएन।
परिनियोजनको समयमा कोडको कुनै स्वचालित परीक्षण थिएन।

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

यद्यपि, कार्य पूरा भयो: हामीले दुई हप्ता भित्र पहिलो काम गर्ने स्ट्यान्ड प्राप्त गर्यौं। यसले गत वर्षमा धेरै परिवर्तनहरू पार गरेको छ र प्रयोग गर्न जारी छ।

अर्को, म हाम्रो समाधानको विकासका सबै चरणहरू र चरणहरू विस्तारमा वर्णन गर्नेछु। तपाईंले देख्नुहुनेछ कि यो विधि यसको अस्तित्वको अधिकारको योग्य छ।

"पातलो रिडन्डन्सी" भनेको के हो?
यो हार्डवेयर वा सफ्टवेयर टेक्नोलोजी हो (अर्को नाम स्प्यार्स भोल्युम हो) जसले तपाईंलाई उपलब्ध भन्दा बढी आवश्यक स्रोतहरू आवंटित गर्न अनुमति दिन्छ। यस अवस्थामा, आवंटित भोल्युमले मात्र-पर्याप्त (आवश्यकता अनुसार) र मात्र-मा-समय (आवश्यक समयको लागि) मापदण्ड पूरा गर्नुपर्छ। साधारणतया, पातलो रिजर्भेसन विभिन्न भण्डारण प्रणालीहरूमा आवश्यक मात्रामा डिस्क स्पेस प्रदान गर्न प्रयोग गरिन्छ, वास्तवमा उपलब्ध ती भन्दा बढी। प्रविधि विभिन्न फाइल प्रणालीहरू द्वारा समर्थित छ, उदाहरणका लागि, LVM2, ZFS, BTRFS। यो व्यापक रूपमा भर्चुअलाइजेशन हाइपरवाइजरहरूमा प्रयोग गरिन्छ। पातलो ब्याकअपले हामीलाई यस खण्डको धेरै प्रतिलिपिहरू (MySQL DBMS को डाटा डाइरेक्टरी) को साथमा मुख्य खण्डको स्न्यापसटहरूबाट द्रुत रूपमा सिर्जना गर्न अनुमति दियो।

पहिलो स्ट्यान्ड, पातलो LVM प्रविधि

यस अध्यायलाई "कसरी प्रयोग गरेर ठूलो मात्रामा डाटाको द्रुत स्न्यापसटहरू बनाउने भनेर पनि भन्न सकिन्छ। पातलो LVM, फाइल प्रणालीको स्थिरता र MySQL DBMS लाई अशोभनीय स्तरहरूमा घटाउँदै।"

हामीले मुख्य OS विभाजनहरू निर्माण गर्न LVM प्रयोग गरिसकेपछि, हामीले यसको साथ सुरु गर्ने निर्णय गर्यौं। सुरु गर्नको लागि, हामीलाई एउटा छुट्टै भौतिक मेसिन चाहिन्छ - हाम्रो मुख्य MySQL डाटाबेसको प्रतिकृति, जसमा हामीले अनुरोधमा प्रतिकृतिको स्न्यापसट सिर्जना गर्न सक्छौं र यसलाई छुट्टै MySQL उदाहरणको छेउमा उठाउन सक्छौं। परीक्षणको क्रममा, हामीले यस उदाहरणमा परिमार्जन कार्यहरू प्रयोग गर्न अनुमति दियौं, र परीक्षणहरू पूरा भएपछि, हामीले यसलाई सुरक्षित रूपमा मेटायौं। सर्भर कन्फिगरेसन यस्तो थियो:

2 x इंटेल सिल्भर 4114 (10x2,2 GHz HT)
8 x 32 GB DDR4
RAID-8 मा Adaptec RAID नियन्त्रकमा 1920 x 10 GB Intel SSD

तपाईं RAID नियन्त्रक र सफ्टवेयर RAID MD बीच छनौट गर्ने विषयमा छुट्टै लेख लेख्न सक्नुहुन्छ। मलाई केवल भन्न दिनुहोस् कि हाम्रो छनौट दुई कारकहरूद्वारा प्रभावित थियो:

समस्या तयार भएको समयमा, हामीले RAID नियन्त्रकहरूमा सबै DBMS हरू स्थापना गर्यौं, त्यसैले हामी भन्न सक्छौं कि यो ऐतिहासिक रूपमा भयो।
सिंथेटिक फाइल प्रणाली परीक्षणहरू र विभिन्न MySQL अपरेसनहरूसँग परीक्षणहरू बीचको प्रदर्शनमा भिन्नता न्यूनतम थियो।

हामीले परिणामस्वरूप RAID-10 विभाजित गर्यौं: हामीले सम्पूर्ण भोल्युमको लागि एकल भोल्युम समूह (VG) बनायौं (लगभग 6,7 GB को ओभरहेडको साथ) र 50 GB प्रणालीको लागि तार्किक विभाजन (लजिकल भोल्युम, LV) सिर्जना गर्यौं। सामान्य अवस्थामा, हामीले बाँकी ठाउँलाई MySQL खण्डको रूपमा परिभाषित गर्छौं। तर हामीलाई पातलो ब्याकअप चाहिन्छ, त्यसैले पहिले हामीले एक तथाकथित पूल सिर्जना गर्यौं, जसको भित्र हामीले 3,5 TB (अनुमानित डाटाबेस भोल्युमहरूमा आधारित) को साथ /var/lib/mysql को लागि एउटा खण्ड सिर्जना गर्यौं:

lvcreate -l 100%FREE -T vga/thin
lvcreate -V 3.5T -T vga/thin -n mysql

हामीले विभाजनलाई ext4 मा ढाँचा गर्यौं, यसलाई माउन्ट गर्यौं, प्रतिकृति रेकर्ड गर्यौं र मूल स्ट्यान्ड पायौं। त्यसपछि हामीले एपीआईको रूपमा एक बाइन्डिङ बनायौं, जसले स्न्यापसटहरू सिर्जना गर्नुपर्छ, दिइएको पोर्टमा MySQL डाटाबेस उदाहरण उठाउनु पर्छ र सिर्जना गरिएको उदाहरण मेटाउनुपर्छ। यसले विशेष रूपमा प्रणाली कलहरू प्रयोग गर्ने भएकोले, हामीले स्क्रिप्टिङ भाषाको रूपमा नियमित बासलाई छनोट गर्‍यौं, र HTTP → bash API जडान गर्न खुला स्रोत समाधान प्रयोग गर्‍यौं। जाउ एक्सपोज, Go मा लेखिएको छ।

कुनै दिन हामी हाम्रो bash स्क्रिप्टहरू खुला स्रोतमा जारी गर्नेछौं, तर अहिलेको लागि म मुख्य एल्गोरिथ्म मात्र वर्णन गर्नेछु:

मुख्य स्न्यापसट स्न्यापमेन सिर्जना गर्दै:

मुख्य प्रतिकृति रोक्दै।
हामीले स्न्यापमेन स्न्यापसटको साथ सञ्चालनमा ब्लक राख्यौं।
नयाँ स्न्यापसट स्न्यापमेन सिर्जना गर्नुहोस्।
MySQL सुरु गर्नुहोस् र लक हटाउनुहोस्।

snapmain बाट एक मनमानी पोर्टमा डाटाबेस सिर्जना गर्दै:

हामीले एक विशिष्ट डाटाबेस उदाहरण (पोर्ट) मा लक राख्छौं।
हामी जाँच गर्छौं कि मुख्य स्न्यापसटको सिर्जना अवरुद्ध छ। यदि यो त्यहाँ छ भने, हामी पर्खनुहोस् र प्रत्येक 5 सेकेन्ड पुन: जाँच गर्नुहोस्।
हामी जाँच गर्छौं कि त्यहाँ उदाहरणको पुरानो LV खण्ड छ।
3.1 यदि त्यहाँ छ भने, MySQL उदाहरण रोक्न र LV विभाजन मेटाउन kill -9 प्रयोग गर्नुहोस्।
हामी snapmain बाट नयाँ उदाहरण सिर्जना गर्छौं।
हामी यस उदाहरणको लागि डाइरेक्टरीहरू तयार र माउन्ट गर्छौं।
हामी दास (फाइलहरू) को विशेषताहरू हटाउँछौं र MySQL उदाहरण सुरु गर्छौं।
उहाँलाई गुरु बनाऔं।
हामी अवरोध हटाउँछौं।

अनियमित पोर्टमा डाटाबेस हटाउँदै:

हामीले एक विशिष्ट डाटाबेस उदाहरण (पोर्ट) मा लक राख्छौं।
किल -9 प्रयोग गरेर MySQL उदाहरण मार्नुहोस्।
डाइरेक्टरीहरू अनमाउन्ट गरौं।
हामी LV विभाजन मेटाउँछौं र लक हटाउँछौं।

नयाँ डाटाबेस उदाहरणको क्लोनिङ विभाजनका लागि उदाहरण आदेशहरू:

lvcreate -n stage_3307 -s vga/snapmain
lvchange -ay -K vga/stage_3307
mount -o noatime,nodiratime,data=writeback /dev/mapper/vga-stage_3307 /mnt/stage_3307

अब म तपाईंलाई पातलो रिडन्डन्सी प्रयोग गर्दा हामीले सामना गरेको मुख्य समस्याको बारेमा बताउनेछु। हामी SSD ड्राइभको प्रदर्शनमा अड्किएका छौं। यो थिन LVM को विशेषताहरु को कारण भयो: यो मूलतया 4 MB को पूर्वनिर्धारित आकार को कम-स्तर भाग संग उपकरण स्तर मा सञ्चालन गर्दछ। यो कस्तो देखिन्थ्यो:

मुख्य खण्ड /var/lib/mysql बाट स्न्यापसट सिर्जना गर्नुहोस्।
हामी मास्टरसँग समात्न प्रतिकृति सुरु गर्छौं।
प्रतिकृति तालिकामा भएको कुनै पनि परिवर्तनले पुरानो, अपरिवर्तित डेटालाई स्न्यापसट खण्डमा भण्डारण गर्न बल दिन्छ।
उठाइएको परीक्षण उदाहरणमा कुनै पनि परिवर्तनले त्यस उदाहरणको लागि क्लोन स्न्यापसट खण्डमा डेटाको पुरानो, अपरिवर्तित टुक्राहरू भण्डारण गर्न निम्त्याउँछ।
हामीले यन्त्रमा 100% I/O अपरेसनहरूको भार पाउँछौं, कुनै पनि सञ्चालनको ढिलो र प्रतिकृतिको क्रमिक ढिलाइ।
कामको दिनको अन्त्यमा हामीले एउटा स्ट्यान्ड पाउँछौं जुन धेरै घण्टा पछाडि छ।

थप विवेकपूर्ण नतिजा (मुख्य बुँदाहरू) प्राप्त गर्न हामीले यसलाई कसरी व्यवहार गर्यौं:

RAID नियन्त्रक:

सबै प्रकारका क्यासिङ पूर्वनिर्धारित रूपमा असक्षम हुन्छन्।
राइटब्याक सेट गर्नुहोस् (डेटा बफरमा प्रवेश गर्दा, डिस्कमा वास्तविक बचत गर्नु अघि लेखन पूरा हुन्छ)।

फाइल प्रणाली:

माउन्ट पोइन्ट /var/lib/mysql मा हामीले लेख्यौं noatime,nodiratime,data=writeback
tune4fs प्रयोग गरेर ext2 लगिङ असक्षम पारियो।

MySQL:

निर्धारित innodb_flush_method = O_DSYNC (बढाइएको रेकर्डिङ गति, यसैले विश्वसनीयता कम)।
लगिङ असक्षम गरिएको छ, हामीलाई लगहरू आवश्यक पर्दैन।
निर्धारित innodb_buffer_pool_size = 4G (InnoDB पूल साइज जति सानो हुन्छ, त्यति नै छिटो MySQL बन्द हुँदा बन्द हुनेछ, र छिटो हामी स्न्यापसट सिर्जना गर्नेछौं)।

यो पूर्ण सूची होइन, विशेष गरी MySQL को लागी। यद्यपि, बाँकी परिवर्तनहरू साना छन् र प्रायः सधैं वा सही रूपमा लागू हुँदैनन्। उदाहरणका लागि, डिस्कहरू अनलोड गर्ने प्रयासमा, हामीले पनि हटायौं innodb_parallel_doublewrite_path in /dev/shm, जसले गलत तरिकाले समाप्त गरिएको उदाहरण सुरु गर्दा केही अवस्थामा हामीलाई ५ सेकेन्डसम्म बचत गर्छ।

हामीले स्न्यापसट लिनु अघि MySQL किन रोक्छौं? आखिर, हामी यसलाई काम गर्ने प्रतिकृतिबाट हटाउन सक्छौं। यो सही छ, तर यस स्न्यापसटमा नयाँ डाटाबेस उदाहरणलाई पूर्वनिर्धारित रूपमा क्षतिग्रस्त मानिनेछ र स्टार्टअपमा पूर्ण स्क्यान आवश्यक हुनेछ। प्रतिकृति रोक्न निश्चित रूपमा छिटो छ, यद्यपि यो सम्पूर्ण प्रक्रियामा सबैभन्दा लामो अपरेशनको रूपमा समाप्त हुन्छ।

फलस्वरूप, हामीले अधिक स्वीकार्य समय र प्रयोग गर्न तयार स्ट्यान्ड प्राप्त गर्यौं। यद्यपि, मुख्य प्रतिकृतिको प्रतिकृति ढिलाइको सबैभन्दा स्पष्ट ग्राफबाट देख्न सकिन्छ, स्थिति अझै पनि आदर्शबाट टाढा छ:

अन्य कमजोरीहरू मध्ये, यो पातलो LVM पूल निगरानीको व्यावहारिक असम्भवतालाई ध्यान दिन लायक छ: प्रणाली मानक iostat प्रकार्यहरू बाहेक, यो बुझ्न असम्भव छ, उदाहरणका लागि, कुन पूल तत्वले हाल फाइल प्रणालीमा सबैभन्दा ठूलो भार उत्पादन गरिरहेको छ।

अलग रूपमा, माथि वर्णन गरिएको अप्टिमाइजेसनसँग सम्बन्धित एउटा ठूलो कमीलाई ध्यान दिन लायक छ: हामीले YOLO स्ट्यान्ड प्राप्त गर्यौं। प्रत्येक एक वा दुई महिनामा एक पटक ext4 ले यस्तो दुरुपयोगको सामना गर्न सकेन र अपूरणीय रूपमा टुट्यो, पुन: फर्म्याट गर्न र प्रतिकृतिको पुन: अपलोड गर्न आवश्यक छ। गतिमा जितेर, हामीले आशाहीन रूपमा स्थिरतालाई बर्बाद गर्यौं।

पातलो LVM प्रयोग गर्दा कुन मेट्रिक्स तपाईंले निगरानी गर्नुपर्छ:

पातलो पूल डाटा %
पातलो पूल मेटाडेटा %

यदि हाम्रो स्ट्यान्ड डाटाको लागि स्पेसको रन आउटबाट बच्छ (डिस्कहरू सफा गर्न पर्याप्त छ), तब मेटाडाटाको लागि स्पेस रन आउटले पूलको पूर्ण पतन र यसलाई स्क्र्याचबाट पुनर्निर्माण गर्नुपर्ने आवश्यकता निम्त्याउँछ।

पूल भित्र फाइल प्रणाली समय संग धेरै खण्डित हुन्छ। म दिनमा एक पटक क्रोन आदेश चलाउन सिफारिस गर्दछु fstrim -v /var/lib/mysql.

उप-योग:

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

दोस्रो स्ट्यान्ड, ZFS प्रविधि

म धेरै पहिले ZFS फाइल प्रणालीसँग काम गर्थें, तर त्यतिबेला, ZFS ले यसको नेटिभ सोलारिस OS परिवारमा भरपर्दो रूपमा राम्रोसँग काम गर्थ्यो। FreeBSD मा एउटा पोर्ट थियो जसको कार्यान्वयन स्तर एकदम राम्रो थियो। त्यहाँ एउटा अधूरो पोर्ट पनि थियो जसको लागि Linux, जुन थोरै मानिसहरूले प्रयोग गर्थे। यसको B-tree डेटा भण्डारण संरचनाको कारण (संयोगवश, MySQL को InnoDB को समान भण्डारण संरचना छ), ZFS ले धेरै ठूलो संख्यामा फाइलहरू भएका स्थापनाहरूमा खराब प्रदर्शन गर्‍यो। यो, प्रयोग गर्नु अघि डोरीहरू सिक्ने आवश्यकतासँग मिलेर, मलाई यो फाइल प्रणालीको दीर्घकालीन प्रयोग गर्न प्रेरित गर्‍यो। Ext4 र xfs देखा परे र मानक बने। तर ZFS हाम्रो आवश्यकताहरूको लागि उपयुक्त भन्दा बढी छ, र Linuxसमीक्षाको आधारमा हेर्दा, -संस्करण पूर्ण रूपमा समझदार उत्पादनमा परिणत भएको छ (यद्यपि पूर्ण रूपमा समर्थित छैन, त्यसैले ZFS मा स्क्र्याचबाट प्रणाली स्थापना गर्नु विभिन्न वूडू प्रविधिहरूको मद्दतले मात्र सम्भव छ), हामीले यसलाई प्रयास गर्ने निर्णय गर्यौं।

स्पष्ट कारणहरूको लागि, स्ट्यान्ड समान कन्फिगरेसनको साथ छनोट गरिएको थियो (RAID नियन्त्रकको अपवादको साथ)। हामीले आठ 1920 GB SSD ड्राइभहरू स्थापना गर्यौं। बेयर ZFS मा सर्भर अपलोड गर्न हाम्रो आफ्नै नेटवर्क छवि लेख्ने इच्छा थिएन, त्यसैले हामीले 50 GB सबै डिस्कहरू काट्यौं र प्रणालीको लागि तिनीहरूमा MD RAID-10 बनायौं। प्रत्येक डिस्कमा बाँकी 1950 GB RAID-10 को ZFS एनालगमा जोडिएको थियो:

zpool create zpool mirror /dev/sda2 /dev/sdb2 mirror /dev/sdc2 /dev/sdd2 mirror /dev/sde2 /dev/sdf2 mirror /dev/sdg2 /dev/sdh2

हामीले MySQL को लागि खण्डहरू सिर्जना गर्यौं:

zfs create zpool/mysql
zfs set compression=gzip zpool/mysql
zfs set recordsize=128k zpool/mysql
zfs set atime=off zpool/mysql
zfs create zpool/mysql/data
zfs set recordsize=16k zpool/mysql/data
zfs set primarycache=metadata zpool/mysql/data
zfs set mountpoint=/var/lib/mysql zpool/mysql/data

कृपया ध्यान दिनुहोस् कि हामीले नेटिभ gzip डाटा कम्प्रेसन सक्षम गरेका छौं। हामीसँग सर्भरमा धेरै प्रोसेसर स्रोतहरू छन् र तिनीहरू पूर्ण रूपमा प्रयोग भएका छैनन्। परिणाम स्वरूप, हाम्रो डाटाबेसको 3 TB 1,6 TB मा परिणत भयो, र कमजोर लिङ्कले, अघिल्लो अवस्थामा जस्तै, अधिकतम डिस्क प्रदर्शन, कम डाटा राम्रो, हामीले ZFS बाट सुरुदेखि नै ठूलो बोनस पाउँछौं! पूर्ण लोडमा भीडको समयमा, यसले gzip चलाउन 4 कोरसम्म लिन्छ, तर हामीलाई कुनै आपत्ति छैन।

त्यसपछि कार्यान्वयन तिब्र गतिमा भयो । MySQL प्रतिकृति सेटिङहरू LVM स्ट्यान्डबाट कार्बन प्रतिलिपिको रूपमा स्थानान्तरण गरियो। मैले ZFS आदेशहरू प्रयोग गरेर स्क्रिप्टहरू पुन: लेख्न केही समय खर्च गर्नुपर्‍यो, तर सामान्यतया एल्गोरिदमहरू उस्तै रहे। स्न्यापसट सिर्जना गर्ने एउटा उदाहरण:

zfs set snapdir=visible zpool/mysql/data
zfs create zpool/stage_3307
zfs clone zpool/mysql/data@snapmain zpool/stage_3307/data
zfs set mountpoint=/mnt/stage_3307 zpool/stage_3307/data

अतिरिक्त ट्युनिङबाट: हामीले मेटाडेटा र l2arc र zil लगहरू मेमोरीमा ZFS विभाजनहरू सार्यौं। हाम्रो कार्यको लागि, यो पछि गएको रूपमा, यो अनावश्यक थियो, तर अहिलेको लागि हामीले यो अनुकूलन छोड्यौं; आवश्यक भएमा यसलाई परिवर्तन गर्न सजिलो छ। नकारात्मक प्रभावहरू मध्ये एक यो हो कि सर्भर रिबुट गरेपछि, तपाईंले सम्बन्धित मेमोरी क्षेत्रहरू पुन: सिर्जना गर्नुपर्नेछ। कुनै डाटा हराएको छैन। Zpool स्थिति क्लिपिङ:

logs
      /dev/shm/zil_slog.img  ONLINE       0     0     0
cache
      /dev/shm/l2arc.img     ONLINE       0     0     0

यस कन्फिगरेसनमा, हामीले स्ट्यान्डको परीक्षण सुरु गर्‍यौं र उत्कृष्ट नतिजाहरू पायौं: स्न्यापशटहरूमा दुई एकै साथ चलिरहेको डाटाबेस उदाहरणहरू (र एउटा सक्रिय मुख्य प्रतिकृति) संग, हामीले 50-60% डिस्क उपयोग पायौं।

हामीले हाम्रो मुख्य समस्याबाट छुटकारा पायौं, जस्तै प्रतिकृति ल्याग ग्राफमा देख्न सकिन्छ (थिन LVM सेक्सनमा अघिल्लो ग्राफसँग तुलना गर्नुहोस्):

यसका अतिरिक्त र यसका लागि धन्यवाद, हामीले सबै कार्यहरू धेरै गतिमा बढाएका छौं: पूर्ण रूपमा रोकिँदै र प्रतिकृति सुरु गर्नको लागि स्न्यापसट सिर्जना गर्न 40 सेकेन्डसम्म लाग्छ, स्न्यापसटबाट नयाँ MySQL उदाहरण तैनात गर्न 20 सेकेन्डसम्म लाग्छ। जुन हामी र हाम्रो कार्यक्रम कोड परीक्षण दुवैको लागि सन्तोषजनक भन्दा बढी छ।

उप-योग:

परिणामहरूले कोड परीक्षणको लागि उत्पादन डाटाबेसको प्रतिलिपि प्राप्त गर्न हाम्रो आवश्यकतालाई पूर्ण रूपमा सन्तुष्ट गर्यो।
टेक्नोलोजीलाई प्रविष्टि चाहिन्छ: तपाईले ZFS के हो र कसरी यसको साथ काम गर्ने भनेर बुझ्न आवश्यक छ।
हामीले ठूलो संख्यामा (१ मिलियन भन्दा बढी) साना फाइलहरूसँग ZFS को हालको स्थिति जाँच गरेका छैनौं। तर हामी मान्दछौं कि समस्या रहिरहन्छ, त्यसैले म कुनै पनि फाइल भण्डारणको लागि यो फाइल प्रणाली सिफारिस गर्दिन।

के अर्को छ?

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

परिणामहरू

मौलिक समस्या हल भएको थियो, यद्यपि एक असामान्य तरिकामा। मध्यवर्ती निष्कर्षहरूले प्रयोग गरिएका प्रत्येक प्रविधिहरूको फाइदा र बेफाइदाहरू वर्णन गरेको छ, त्यसैले कुन प्रविधि प्रयोग गर्न सकिन्छ र कहिले प्रयोग गर्न सकिन्छ भनेर निर्णय गरौं:

पातलो LVM - साना डाटाबेसहरूको लागि र जब तपाईं ZFS सिक्न चाहनुहुन्न वा समय छैन।
ZFS - यदि तपाइँसँग यसको साथ काम गर्ने अनुभव छ वा कुनै पनि परिस्थितिमा यसलाई अध्ययन गर्न समय खर्च गर्ने अवसर छ।

प्रस्तुतिको उच्च स्तरमा, यो लेख दुई फाइल प्रणालीहरूको प्रविधिको तुलना मात्र होइन। मुख्य विचार जुन म व्यक्त गर्न चाहन्छु र सुदृढीकरण गर्न चाहन्छु यो हो कि तपाईं व्यापारिक-महत्वपूर्ण परिस्थितिहरूमा बाकस बाहिर सोच्न डराउनु हुँदैन र केवल तयार-बनाएका व्यंजनहरू मात्र लिनुहोस्। एक पटक, हामी प्राविधिक विभागमा सम्पूर्ण रूपमा हाम्रो टाउको हल्लाउन सक्छौं र भन्न सक्छौं कि एक मिनेट भन्दा कममा डाटाबेसको तीन-टेराबाइट प्रतिलिपिहरू सिर्जना गर्ने कार्य असम्भव छ, र हामीलाई जोखिमपूर्ण प्रविधिहरू आवश्यक पर्दैन, गरौं। यो सही छ। यो सम्भव थियो, तर हामीले परीक्षण बिना र कार्यान्वयनको क्रममा लगभग छ महिनादेखि एक वर्ष र धेरै ग्राहक यात्राहरू (यात्रा हाम्रो मुख्य व्यवसाय सूचक हो) गुमाउने थियौं। बक्स बाहिर काम गरेर, हामीले कार्यान्वयनमा धेरै समय गुमाएनौं, नयाँ र बिर्सिएका पुराना प्रविधिहरूमा अनुभव प्राप्त गर्‍यौं, र हामीलाई वास्तवमै यसको आवश्यकता परेको समयमा परीक्षण प्रदान गर्‍यौं। निस्सन्देह, यसले हाम्रा सबै सूचकहरूमा सकारात्मक प्रभाव पारेको छ। छनोट सधैं तपाईको हो, र हामी, हाम्रो भागको लागि, हाम्रो ब्लगमा रोचक वर्तमान र भविष्यका उपलब्धिहरूको बारेमा कुरा गर्न जारी राख्नेछौं।

स्रोत: www.habr.com