एक 22 जीबी MySQL डेटाबेस का बैकअप प्रतिदिन


28

अभी मैं mysqldump का उपयोग करके बैकअप करने में सक्षम हूं। लेकिन मुझे वेब सर्वर को नीचे ले जाना होगा और बैकअप करने में लगभग 5 मिनट लगेंगे। अगर मैं वेब सर्वर को नहीं लेता, तो यह हमेशा के लिए खत्म हो जाता है और कभी खत्म नहीं होता है + वेबसाइट बैकअप के दौरान अप्राप्य हो जाती है।

क्या मेरे 22 जीबी और बढ़ते डेटाबेस का बैकअप लेने का एक तेज / बेहतर तरीका है?

सभी टेबल MyISAM हैं।


इस लिंक पर एक नज़र
डालिए

जवाबों:


28

हाँ।

दूसरी मशीन के लिए सेटअप प्रतिकृति। जब आपको बैकअप करने की आवश्यकता होती है, तो आप द्वितीयक मशीन को लॉक कर सकते हैं, mysqlhotcopy या mysqldump कर सकते हैं, और फिर उसे अनलॉक कर सकते हैं। यह आपके मास्टर के साथ बैकअप लेगा, और आपको कभी भी मास्टर को ऑफलाइन नहीं लेना होगा।

आप इसे एक ही मशीन पर भी कर सकते हैं, अगर आपको I / O लिखने में कोई दिक्कत नहीं है, लेकिन आदर्श रूप से आपको इसे वास्तविक भौतिक सर्वर पर वास्तविक समय में वापस करना चाहिए, और अपने स्नैपशॉट बैकअप को जितनी बार ज़रूरत हो अपने उत्पादन सर्वर को परेशान किए बिना।

एक ज्ञात राज्य और बिनलॉग का उपयोग करके डेटाबेस को पुनर्स्थापित करना सैद्धांतिक रूप से भी संभव है। मैंने कभी ऐसा नहीं किया है, इसलिए कृपया पहले जांच करें, लेकिन आप अपने डेटाबेस की ज्ञात स्थिति का बैकअप ले सकते हैं, फिर सभी नए बिनलॉग का बैकअप ले सकते हैं और यदि आपको कभी भी पुनर्स्थापित करने की आवश्यकता होती है तो उन्हें फिर से शुरू करें। चूंकि Binlogs को रैखिक रूप से लिखा जाता है, इसलिए दूरस्थ कंप्यूटर पर नए binlogs को पुन: व्यवस्थित करना बहुत तेज़ होगा।

संपादित करें: वास्तव में, ऐसा लगता है कि बैकअप के लिए द्विपद का उपयोग करना प्रलेखित है।

यह प्रश्न अत्यधिक संबंधित है


हां, यह बहुत अच्छा काम करता है और मेरा जवाब बनने जा रहा है। केवल प्रमुख नकारात्मक पक्ष यह है कि आपको यह सुनिश्चित करने की आवश्यकता है कि प्रतिकृति दैनिक आधार पर सही ढंग से काम कर रही है। हम व्यावसायिक घंटे के दौरान और स्वामी से एक रात के बैकअप के दौरान अपने दास डेटाबेस का स्नैपशॉट लेते हैं।

5

ओएस संभालने के लिए मुझे क्षमा करें लिनक्स है। यदि आप LVM का उपयोग नहीं कर रहे हैं, तो आपको होना चाहिए। यदि आप हैं, तो यहां स्नैपशॉट के माध्यम से बैकअप बनाने का एक बहुत ही सरल तरीका है।

# Define these vars to meet your needs. These meet mine.
lvol="/dev/VolGroup03/lvol0"
snap_name="nightly_snapshot"
snap_vol="$(dirname $lvol)/$snap_name"
snap_path="/mnt/$snap_name"
snap_size="10g" # Not the size of your data, anticipated data changes during the backup
backup_path="/backups/$snap_name"

/usr/bin/time -f 'Databases were locked for %E' -- \
mysql <<- MYSQL
# based on http://pointyhair.com/tiki-view_blog_post.php?blogId=1&postId=5
FLUSH TABLES WITH READ LOCK;
\! lvcreate --size $snap_size --snapshot --name $snap_name $lvol
UNLOCK TABLES;
MYSQL
mount $snap_vol $snap_path
rsync -av --delete $snap_path/mysql $backup_path/
umount $snap_path
lvremove -f $snap_vol

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


2

READ LOCK के साथ FLUSH TABLES कुछ ऐसा नहीं है जिसे आप उत्पादन प्रणाली के आधार पर नियमित (या अर्ध-नियमित) करना चाहते हैं। यह केवल एक अंतिम उपाय होना चाहिए।

कम से कम दो प्रतिकृति गुलामों की स्थापना करें (इसके लिए READ LOCK के साथ FLUSH TABLES की आवश्यकता होगी)। एक बार जब वे सेट हो जाते हैं, तो आप एक का बैकअप ले सकते हैं जबकि दूसरा एक अतिरिक्त मास्टर के रूप में सिंक में रहता है।

इसके अलावा, यदि आपका कोई दास असफल हो जाता है, तो आप एक स्नैपशॉट का उपयोग उस से दूसरे (या तीसरे) गुलाम के पुनर्निर्माण के लिए कर सकते हैं। यदि आपके सभी दास विफल हो जाते हैं, तो आप वापस ताला के साथ फ्लश टेबल पर वापस आ सकते हैं।

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

जैसा कि 22 जीबी अपेक्षाकृत छोटा है, आपको ऐसा करने में कोई समस्या नहीं होगी। एक बड़े डेटाबेस के साथ इसे करना अधिक समस्याग्रस्त हो सकता है।


1

यहाँ समाधान दो गुना है, जैसा कि ऊपर वर्णित है:

  1. अपने सर्वर के प्रतिकृति को एक दास पर सेट करें जिसे आप ऑफ़लाइन ले सकते हैं। ऐसा करने का सबसे अच्छा तरीका mysqldump और --master-data पैरामीटर का उपयोग करके डेटाबेस का एक डंप लेना है।
  2. दास पर रात के बैकअप सेट करें। आप या तो mysqldump --master-data --flush-log और --single-transaction झंडे के साथ उपयोगकर्ता कर सकते हैं, या आप mysql सर्वर को रोक सकते हैं, डेटा फ़ाइलों को डिस्क पर कॉपी कर सकते हैं, और इसे फिर से शुरू कर सकते हैं (प्रतिकृति जहां ले जाएगा इसे छोड़ दिया)।
  3. जाँच करें और सुनिश्चित करें कि mysql अभी भी नकल कर रहा है गुलाम हर (उदाहरण 5, 10, 20 मिनट) पर एक स्क्रिप्ट चलाएँ। मैंने इसे करने के लिए एक सरल अजगर स्क्रिप्ट लिखी , जिसका आप उपयोग करने के लिए स्वागत करते हैं।

ध्यान दें कि यदि आप अपनी तालिकाओं के लिए InnoDB का उपयोग कर रहे हैं, तो आप किसी भी टेबल के ताले को करने से बचने के लिए -single-transaction ध्वज का उपयोग कर सकते हैं और अभी भी डेटाबेस का एक सुसंगत डंप प्राप्त कर सकते हैं, यहां तक ​​कि मास्टर पर भी, और इस प्रकार आपके बैकअप के बिना सर्वर को नीचे ले जा रहा है। हालांकि, उपरोक्त समाधान एक बेहतर है।

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

यदि आप I / O कंटेस्टेंट के बारे में चिंतित हैं, तो डंप को बहुत लंबा लग रहा है, तो आप एक तीसरी मशीन जोड़ सकते हैं और उस पर mysqldump चला सकते हैं जो आपके डिस्क को थ्रैश करने से बचने के लिए नेटवर्क पर है।


0

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

  1. FLUSH TABLES WITH READ LOCK;
  2. डेटाबेस पर एक स्नैपशॉट खींचो और फाइलसिस्टम लॉग करें।
  3. UNLOCK TABLES;
  4. अपने अवकाश पर अपने डेटा फ़ाइलों को स्नैपशॉट से कॉपी करें।

InnoDB तालिकाओं के साथ, आप SET AUTOCOMMIT=0;रीड लॉक निष्पादित करने से पहले चलाना चाहते हैं।



-1

आप एक क्रमिक बैकअप कर सकते हैं। बैकअप 1/24 रिकॉर्ड हर घंटे। इस दृष्टिकोण के साथ एकमात्र समस्या यह है कि यदि यह दिन के पहले कुछ घंटों के दौरान क्रैश हो जाता है, तो आप उस समय से क्रैश के समय तक कुछ भी खो देंगे। किसी भी तरह से, यह रिकॉर्ड खोए हुए 24 घंटे से कम है (मुझे नहीं पता कि यह आपके लिए कितना महत्वपूर्ण है)।

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