MySQL Binlogs :: कैसे पुनर्प्राप्त करें

इसलिए मुझे एहसास हुआ कि मैंने इस स्थिति के बाद इस बारे में एक पोस्ट नहीं किया था कि हाल ही में आया था।

यहाँ परिदृश्य है: एक बैकअप आधी रात को लिया गया था, उन्होंने प्रति डेटाबेस MySQL डंप का उपयोग किया। फिर अगले दिन सुबह दस बजे डेटाबेस क्रैश हो गया। मुझे बुलाए जाने से पहले घटनाओं की एक श्रृंखला हुई थी, लेकिन वे इसे डेटाबेस के एक संस्करण तक ले गए थे, जिसमें MyISAM तालिकाओं और तालिकाओं से गायब IBD फाइलें थीं।

तो विकल्प 1, बैकअप से बहाल करना हमें आधी रात को मिलेगा और हम घंटों डेटा खो देंगे। विकल्प 2, हम 1000 की ibd फ़ाइलों को फिर से जोड़ते हैं और सब कुछ रखते हैं। तब हमारे पास विकल्प 3 था, बैकअप से पुनर्स्थापित करें, फिर हाल के परिवर्तनों के लिए बिनलॉग लागू करें।

इसे और दिलचस्प बनाने के लिए, उनके पास मेरे द्वारा बताई गई सभी ibd फाइलें नहीं थीं, और मुझे कुछ याद नहीं था। तो यकीन नहीं है कि यह कैसे संभव था लेकिन विकल्प 2 एक अमान्य विकल्प बन गया। वे निश्चित रूप से, कम से कम डेटा हानि संभव चाहते थे, इसलिए हम विकल्प 3 के साथ गए।

इसे सुरक्षित रूप से करने के लिए मैंने पोर्ट 3307 के तहत MySQL का एक और उदाहरण शुरू किया। इससे मुझे काम करने के लिए एक सुरक्षित जगह मिल गई, जबकि यातायात ने बंदरगाह 3306 उदाहरण पर MyISAM डेटा तक पहुंच पढ़ी थी।

एक बार सभी बैकअप डंप फ़ाइलें असम्पीडित और 3307 उदाहरण में आयातित मैं Binlog फ़ाइलों पर ध्यान केंद्रित करने में सक्षम था।

पहले तो यह अवधारणा वास्तव में जितना कठिन है, उससे कहीं अधिक जोखिम भरा है। यह वास्तव में बहुत आगे और सरल है।

इसलिए सबसे पहले आपको अपने बाद का डेटा ढूंढना होगा। बिनलॉग फाइलों की समीक्षा आपको यह बताती है कि क्या फाइलें प्रासंगिक हैं। मेरे मामले में, किसी तरह वे बिनलॉग को रीसेट करने में कामयाब रहे, इसलिए 117 फ़ाइल में 2 तारीख सीमाएं थीं।

पहले बिनलॉग समीक्षा के लिए, निम्न कमांड मानव-पठनीय प्रारूप में डेटा को आउटपुट करता है।

mysqlbinlog --defaults-file=/root/.my.cnf --base64-output=DECODE-ROWS --verbose mysql-bin.000117 > review_mysql-bin.000117.sql

* नोट ... उपरोक्त कमांड को चलाने में सावधानी बरतें। ध्यान दें कि मेरे पास फ़ाइल को सीधे उसी स्थान पर डंप करना है जैसे कि बिनलॉग। इसलिए मान्य करें कि आपका फ़ाइल नाम मान्य है। यह mysql-bin.000117.sql, इस mysql-bin.000101 .sql से अलग है। आप अपने बिनलॉग को 2 विकल्प और .sql से पहले एक स्थान के साथ ढीला कर देंगे।

अब डेटा को बचाने के लिए इसे लागू किया जा सकता है। चूँकि मेरे पास कई सारे बैनॉगल्स थे, जिससे मैंने एक फाइल बनाई और मैं वैसे भी समय-सीमा की दोबारा जाँच करना चाहता था।


mysqlbinlog --defaults-file=/root/.my.cnf --start-datetime="2019-07-09 00:00:00" --stop-datetime="2019-07-10 00:00:00" mysql-bin.000117 > binlog_restore.sql
mysqlbinlog --defaults-file=/root/.my.cnf mysql-bin.000118 >> binlog_restore.sql
mysqlbinlog --defaults-file=/root/.my.cnf mysql-bin.000119 >> binlog_restore.sql
mysqlbinlog --defaults-file=/root/.my.cnf --start-datetime="2019-07-10 00:00:00" --stop-datetime="2019-07-10 10:00:00" mysql-bin.000117 >> binlog_restore.sql
mysqlbinlog --defaults-file=/root/.my.cnf --stop-datetime="2019-07-10 10:00:00" mysql-bin.000120 >> binlog_restore.sql
mysqlbinlog --defaults-file=/root/.my.cnf --stop-datetime="2019-07-10 10:00:00" mysql-bin.000121 >> binlog_restore.sql

mysql --socket=/var/lib/mysql_restore/mysql.sock -e "source /var/lib/mysql/binlog_restore.sql"


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

इस स्थिति के लिए कई अलग-अलग विकल्प मौजूद थे, यह क्लाइंट के साथ सबसे अच्छी कसरत करने के लिए हुआ।

एक बार जब सभी को पुनर्स्थापित किए गए संस्करण पर सभी मान्य थे, तो यह दोनों डेटाबेसों का एक सरल पड़ाव था, डेटा निर्देशिकाओं को स्थानांतरित कर दिया (डेटादिर डिफॉल्ट्स को अक्षुण्ण रखना चाहता था), निर्देशिकाओं को केवल सुरक्षित होने के लिए और MySQL को शुरू करने के लिए चुना। अब बहाल किया गया उदाहरण 3306 पोर्ट पर था।