الطريقتان الرئيسيتان للنسخ الاحتياطي لقاعدة البيانات هما استخدام برنامج mysqldump أو نسخ ملف قاعدة البيانات مباشرة (مثل استخدام cp أو cpio أو tar، وما إلى ذلك). توضح هذه المقالة تفاصيل خطة النسخ الاحتياطي لقاعدة بيانات منصة MySQL. في حالة فقدان أو تلف جدول قاعدة البيانات، فمن المهم عمل نسخة احتياطية من قاعدة البيانات الخاصة بك. في حالة حدوث عطل في النظام، فأنت بالتأكيد تريد أن تكون قادرًا على استعادة جداولك إلى الحالة التي كانت عليها عند حدوث العطل مع أقل قدر ممكن من فقدان البيانات. في بعض الأحيان، يكون مسؤول MySQL هو الذي يسبب الفوضى. يعلم المسؤول بالفعل أن الجداول تالفة وأن محاولة تحريرها مباشرةً باستخدام محرر مثل vi أو Emacs ليس بالأمر الجيد بالتأكيد بالنسبة للجداول.
الطريقتان الرئيسيتان للنسخ الاحتياطي لقاعدة البيانات هما استخدام برنامج mysqldump أو نسخ ملف قاعدة البيانات مباشرة (مثل استخدام cp أو cpio أو tar وما إلى ذلك). كل طريقة لها إيجابياتها وسلبياتها:
يعمل mysqldump مع خادم MySQL. يتم تنفيذ طريقة النسخ المباشر خارج الخادم، ويجب عليك اتخاذ الخطوات اللازمة للتأكد من عدم قيام أي عميل بتعديل الجدول الذي تقوم بنسخه. إذا كنت تريد استخدام النسخ الاحتياطي لنظام الملفات لعمل نسخة احتياطية من قاعدة البيانات، فستحدث نفس المشكلة: إذا تم تعديل جدول قاعدة البيانات أثناء عملية النسخ الاحتياطي لنظام الملفات، فسيكون موضوع ملف الجدول الذي تم نسخه احتياطيًا غير متسق، وسيكون الجدول لا معنى لها للتعافي في المستقبل. الفرق بين النسخ الاحتياطي لنظام الملفات والنسخة المباشرة من الملف هو أنه مع الأخيرة لديك سيطرة كاملة على عملية النسخ الاحتياطي، بحيث يمكنك اتخاذ الخطوات اللازمة للتأكد من أن الخادم يترك الجدول دون إزعاج.
mysqldump أبطأ من النسخ المباشر.
يقوم mysqldump بإنشاء ملفات نصية يمكن نقلها إلى الأجهزة الأخرى، حتى تلك التي تحتوي على بنيات أجهزة مختلفة. لا يمكن نقل نسخ الملفات مباشرة إلى أجهزة أخرى إلا إذا كان الجدول الذي تنسخه يستخدم تنسيق تخزين MyISAM. لا يمكن نسخ جداول ISAM إلا على الأجهزة ذات بنيات الأجهزة المشابهة. يعمل تنسيق تخزين جدول MyISAM الذي تم تقديمه في MySQL 3.23 على حل هذه المشكلة لأن التنسيق مستقل عن الجهاز، لذا يمكن نقل نسخ الملف مباشرة إلى أجهزة ذات هياكل أجهزة مختلفة. طالما تم استيفاء شرطين: يجب أن يعمل الجهاز الآخر أيضًا على MySQL 3.23 أو إصدار أحدث، ويجب تمثيل الملف بتنسيق MyISAM، وليس بتنسيق ISAM.
بغض النظر عن طريقة النسخ الاحتياطي التي تستخدمها، إذا كنت بحاجة إلى استعادة قاعدة البيانات الخاصة بك، فهناك العديد من المبادئ التي يجب اتباعها لضمان أفضل النتائج:
تنفيذ نسخ احتياطية منتظمة. ضع خطة والتزم بها.
اسمح للخادم بإجراء تسجيل التحديث. سيساعدك سجل التغيير عندما تحتاج إلى استعادة البيانات بعد حدوث عطل. بعد استخدام ملف النسخ الاحتياطي لاستعادة البيانات إلى الحالة التي كانت عليها وقت النسخ الاحتياطي، يمكنك إعادة تطبيق التغييرات التي تم إجراؤها بعد النسخ الاحتياطي عن طريق تشغيل استعلام في سجل التحديث، والذي سيؤدي إلى استعادة الجداول في قاعدة البيانات إلى الحالة التي كانوا عليها عندما وقع الحادث.
في مصطلحات النسخ الاحتياطي لنظام الملفات، يمثل ملف النسخ الاحتياطي لقاعدة البيانات تفريغًا كاملاً، بينما يمثل سجل التحديث تفريغًا تزايديًا.
استخدم نظام تسمية متسقًا ومفهومًا لملفات النسخ الاحتياطي. أشياء مثل backup1، buckup2، وما إلى ذلك ليست ذات معنى بشكل خاص. عند إجراء عملية الاسترداد، سوف تضيع الوقت في معرفة ما هو موجود في الملفات. قد تجد أنه من المفيد استخدام اسم قاعدة البيانات وتاريخها لتكوين اسم ملف النسخة الاحتياطية. على سبيل المثال:
%mysqldump samp_db >/usr/archives/mysql/samp_db.1999-10-02
%mysqldump menagerie >/usr/archives/mysql/menagerie.1999-10-02
قد ترغب في ضغط النسخ الاحتياطية بعد إنشائها. تميل النسخ الاحتياطية إلى أن تكون كبيرة الحجم، وتحتاج أيضًا إلى انتهاء صلاحية ملفات النسخ الاحتياطي لتجنب ملء القرص الخاص بك، تمامًا مثلما تنتهي صلاحية ملفات السجل الخاصة بك.
قم بعمل نسخة احتياطية من ملفات النسخ الاحتياطي باستخدام نسخة احتياطية لنظام الملفات. إذا واجهت عطلًا كاملاً لا يؤدي إلى مسح دليل البيانات الخاص بك فحسب، بل أيضًا محرك الأقراص الذي يحتوي على النسخ الاحتياطية لقاعدة البيانات، فستكون في مشكلة حقيقية.
قم أيضًا بعمل نسخة احتياطية من سجل التغيير الخاص بك.
ضع ملفات النسخ الاحتياطي على نظام ملفات مختلف عن النظام المستخدم لقاعدة البيانات الخاصة بك. سيؤدي ذلك إلى تقليل إمكانية ملء نظام الملفات الذي يحتوي على دليل البيانات نتيجة إنشاء النسخة الاحتياطية.
تعتبر التقنيات المستخدمة لإنشاء النسخ الاحتياطية مفيدة أيضًا لنسخ قاعدة البيانات إلى جهاز آخر. في أغلب الأحيان، يتم نقل قاعدة البيانات إلى خادم يعمل على مضيف آخر، ولكن يمكنك أيضًا نقل البيانات إلى خادم آخر على نفس المضيف.
1 استخدم mysqldump لعمل نسخة احتياطية من قاعدة البيانات ونسخها
عند استخدام برنامج mysqldumo لإنشاء ملف نسخة احتياطية لقاعدة البيانات، بشكل افتراضي، تحتوي محتويات الملف على عبارة CREATE التي تنشئ الجدول الذي يتم تفريغه وعبارة INSERT التي تحتوي على بيانات الصف في الجدول. بمعنى آخر، يمكن استخدام المخرجات التي ينتجها mysqldump لاحقًا كمدخل إلى mysql لإعادة بناء قاعدة البيانات.
يمكنك تفريغ قاعدة البيانات بأكملها في ملف نصي واحد كما يلي:
%mysqldump samp_db >/usr/archives/mysql/samp_db.1999-10-02
تبدو بداية ملف الإخراج كما يلي:
# MySQL Dump 6.0# # المضيف: قاعدة بيانات المضيف المحلي: samp_db
#---------------------------------------#
إصدار الخادم 3.23.2-alpha-log## بنية الجدول لغياب الجدول
#CREATE TABLEغياب (student_id int(10) unsigned DEFAULT 0 NOT NULL, date date DEFAULT 0000-00-00 NOT NUL L,
PRIMARY KEY (student_id,date));## تفريغ بيانات غياب الجدول #INSERT INTO VALUES (3,1999-09-03);INSERT INTO GALUE VALUE S (5,1999-09-03);INSERT INTO GALUEES (10,1999-09-08);......
يتكون باقي الملف من المزيد من عبارات INSERT وCREATE TABLE. إذا كنت تريد ضغط النسخة الاحتياطية، استخدم أمرًا مشابهًا لما يلي:
%mysqldump samp_db |.gzip >/usr/archives/mysql/samp_db.1999-10-02.gz
إذا كانت لديك قاعدة بيانات كبيرة، فستكون ملفات الإخراج كبيرة أيضًا وقد يكون من الصعب إدارتها. إذا كنت ترغب في ذلك، يمكنك إدراج أسماء الجداول الفردية بعد اسم قاعدة البيانات في سطر أوامر mysqldump لتفريغ محتوياتها، مما سيؤدي إلى تقسيم ملف التفريغ إلى ملفات أصغر وأكثر قابلية للإدارة. يوضح المثال التالي كيفية تفريغ بعض الجداول من قاعدة البيانات samp_db إلى ملفات منفصلة:
%mysqldump samp_db غياب حدث نتيجة الطالب >grapbook.sql
%mysqldump samp_db عضو الرئيس >hist-league.sql
إذا كنت تقوم بإنشاء ملفات نسخ احتياطي مخصصة للاستخدام لتحديث محتويات قاعدة بيانات أخرى بشكل دوري، فقد تحتاج إلى استخدام خيار --add-drop-table. هذا يخبر الخادم بكتابة عبارة DROP TABLE IF EXISTS إلى ملف النسخ الاحتياطي، وبعد ذلك، عندما تأخذ ملف النسخ الاحتياطي وتحميله في قاعدة البيانات الثانية، لن تحصل على خطأ إذا كان الجدول موجودًا بالفعل.
إذا قمت بتفريغ قاعدة بيانات حتى تتمكن من نقل قاعدة البيانات إلى خادم آخر، فلن تحتاج حتى إلى إنشاء ملف نسخة احتياطية. تأكد من وجود قاعدة البيانات على مضيف آخر، ثم استخدم أنبوبًا لتفريغ قاعدة البيانات حتى يتمكن mysql من قراءة مخرجات mysqldump مباشرة. على سبيل المثال: تريد نسخ قاعدة البيانات samp_db من المضيفpit-viper.snake.net إلى boa.snake.net، ويمكنك القيام بذلك بسهولة على النحو التالي:
%mysqladmin -h boa.snake.net أنشئ samp_db
%mysqldump samp_db |.mysql -h boa.snake.net samp_db
في المستقبل، إذا كنت تريد تحديث قاعدة البيانات على boa.snake.net مرة أخرى، فتخطى أمر mysqladmin، لكن أضف --add-drop-table إلى mysqldump لتجنب الحصول على خطأ الجدول الموجود بالفعل: %mysqldump --add- جدول منسدل samp_db |.mysql -h boa.snake.net samp_db
تتضمن خيارات mysqldump المفيدة الأخرى ما يلي: مجموعة --flush-logs و --lock-tables ستكون مفيدة للتحقق من قاعدة البيانات الخاصة بك. يقوم --lock-tables بتأمين جميع الجداول التي تقوم بإلقاءها، ويقوم --flush-logs بإغلاق ملف سجل التحديث وإعادة فتحه، وسيتضمن سجل التحديث الجديد فقط الاستعلامات التي عدلت قاعدة البيانات من نقطة النسخ الاحتياطي. سيؤدي هذا إلى ضبط وقت النسخ الاحتياطي لنقطة تفتيش سجل التحديث. (ومع ذلك، إذا كان لديك عملاء يحتاجون إلى إجراء تحديث، فإن تأمين كافة الجداول ليس فكرة جيدة لوصول العميل أثناء النسخ الاحتياطي.)
إذا كنت تستخدم --flush-logs للتحقق من النسخة الاحتياطية، فمن الأفضل تفريغ قاعدة البيانات بأكملها.
إذا قمت بتفريغ ملفات منفصلة، فسيكون من الصعب مزامنة نقاط فحص سجل التحديث مع ملفات النسخ الاحتياطي. أثناء عملية الاسترداد، عادةً ما تقوم باستخراج محتويات سجل التحديث على أساس كل قاعدة بيانات. لا يوجد خيار لاستخراج التحديثات للجداول الفردية، لذا يجب عليك استخراجها بنفسك.
افتراضيًا، يقرأ mysqldump محتويات الجدول بالكامل في الذاكرة قبل الكتابة. هذا عادةً ما يكون غير ضروري حقًا، وفي الواقع يكون فاشلًا تقريبًا إذا كان لديك طاولة كبيرة. يمكنك استخدام الخيار --quick لإخبار mysqldump بكتابة كل صف عندما يسترد واحدًا. لتحسين عملية الصب بشكل أكبر، استخدم --opt بدلاً من --quick. يقوم خيار --opt بتشغيل خيارات إضافية لتسريع عملية تفريغ البيانات وقراءتها مرة أخرى.
من المحتمل أن يكون تنفيذ النسخ الاحتياطية باستخدام --opt هو الأسلوب الأكثر شيوعًا نظرًا لميزة سرعة النسخ الاحتياطية. ومع ذلك، كن حذرًا، فإن خيار --opt له تكلفة. يعمل --opt على تحسين عملية النسخ الاحتياطي لديك، وليس وصول العملاء الآخرين إلى قاعدة البيانات. يمنع خيار --opt أي شخص من تحديث أي جدول تقوم بإلقائه عن طريق قفل جميع الجداول مرة واحدة. يمكنك بسهولة رؤية التأثير على الوصول إلى قاعدة البيانات العامة. عندما يتم استخدام قاعدة البيانات الخاصة بك بشكل متكرر جدًا، ما عليك سوى ضبط النسخة الاحتياطية مرة واحدة يوميًا.
الخيار الذي له التأثير المعاكس لـ --opt هو --dedayed. يؤدي هذا الخيار إلى قيام mysqldump بكتابة عبارات INSERT DELAYED بدلاً من عبارات INSERT. يعد --delayed مفيدًا إذا كنت تقوم بتحميل ملف بيانات إلى قاعدة بيانات أخرى وتريد أن يكون لهذه العملية تأثير ضئيل على الاستعلامات التي قد تظهر في قاعدة البيانات تلك.
يعد خيار --compress مفيدًا عند نسخ قاعدة البيانات إلى جهاز آخر لأنه يقلل من عدد البايتات المنقولة عبر الشبكة. فيما يلي مثال على ذلك. لاحظ أن --compress يُعطى للبرامج التي تتواصل مع خادم على مضيف بعيد، وليس للبرامج التي تتصل بالمضيف المحلي:
%mysqldump --opt samp_db |.mysql --compress -h boa.snake.net samp_db
يحتوي mysqldump على العديد من الخيارات، راجع "دليل MySQL المرجعي" للحصول على التفاصيل.
2 طريقة النسخ الاحتياطي والنسخ باستخدام قاعدة بيانات النسخ المباشر
هناك طريقة أخرى لعمل نسخة احتياطية من قاعدة البيانات والجداول التي لا تتضمن mysqldump وهي نسخ ملفات جدول قاعدة البيانات مباشرة. عادةً ما يتم ذلك باستخدام أدوات مساعدة مثل cp أو tar أو cpio. تستخدم الأمثلة الموجودة في هذه المقالة cp.
عند استخدام أسلوب النسخ الاحتياطي المباشر، يجب عليك التأكد من أن الجدول لم يعد قيد الاستخدام. إذا قام الخادم بتغيير جدول أثناء نسخه، فإن النسخة لا معنى لها.
أفضل طريقة لضمان سلامة نسختك هي إيقاف تشغيل الخادم، ونسخ الملفات، ثم إعادة تشغيل الخادم. إذا كنت لا تريد إيقاف تشغيل الخادم، فقم بقفل الخادم أثناء إجراء فحص الجدول. إذا كان الخادم قيد التشغيل، تنطبق نفس القيود على نسخ الملفات، ويجب عليك استخدام نفس بروتوكول القفل "لتهدئة" الخادم.
بافتراض أن الخادم معطل أو أنك قمت بتأمين الجدول الذي تريد نسخه، فإن ما يلي يوضح كيفية عمل نسخة احتياطية لقاعدة بيانات samp_db بأكملها إلى دليل النسخ الاحتياطي (يمثل DATADIR دليل بيانات الخادم): %cd DATADIR%cp -r samp_db /usr /أرشيف/mysql
يمكن عمل نسخة احتياطية لجدول واحد على النحو التالي:
%cd DATADIR/samp_db%cp member.* /usr/archive/mysql/samp_db%cp Score.* /usr/archive/mysql/samp_db ....
عند الانتهاء من النسخ الاحتياطي، يمكنك إعادة تشغيل الخادم (إذا قمت بإيقاف تشغيله) أو تحرير الأقفال الموضوعة على الطاولة (إذا تركت الخادم قيد التشغيل).
لنسخ قاعدة بيانات من جهاز إلى آخر باستخدام ملفات النسخ المباشر، ما عليك سوى نسخ الملفات إلى دليل البيانات المناسب على مضيف الخادم الآخر. تأكد من أن الملف بتنسيق MyIASM أو أن كلا الجهازين لهما نفس بنية الأجهزة، وإلا فستحتوي قاعدة البيانات الخاصة بك على محتويات غريبة على الجهاز الآخر. يجب عليك أيضًا التأكد من أن الخادم الموجود على جهاز آخر لا يصل إلى جداول قاعدة البيانات أثناء تثبيتها.
3 تكرار قاعدة البيانات
النسخ المتماثل يشبه نسخ قاعدة بيانات إلى خادم آخر، ولكن معناه الدقيق هو التأكد من مزامنة قاعدتي البيانات بالكامل في الوقت الفعلي. ستظهر هذه الميزة في الإصدار 3.23 وهي ليست ناضجة جدًا بعد، لذا لن تقدم هذه المقالة تفاصيل عنها.
4 استعادة البيانات من النسخة الاحتياطية
يمكن أن يحدث تلف قاعدة البيانات لأسباب عديدة وبدرجات متفاوتة. إذا كنت محظوظًا، فقد تتلف جدولًا واحدًا أو جدولين فقط (مثل انقطاع التيار الكهربائي)، وإذا لم تكن محظوظًا، فقد يتعين عليك استبدال دليل البيانات بالكامل (مثل تلف القرص). الاسترداد مطلوب أيضًا في مواقف معينة، مثل عندما يقوم المستخدم بحذف قاعدة بيانات أو جدول عن طريق الخطأ. بغض النظر عن سبب هذه الأحداث المؤسفة، سوف تحتاج إلى تنفيذ نوع من التعافي.
إذا كانت الجداول تالفة ولكن لم يتم فقدها، فحاول إصلاحها باستخدام myisamchk أو isamchk. إذا كان من الممكن إصلاح هذا الضرر بواسطة برنامج إصلاح، فقد لا تحتاج إلى استخدام ملف النسخ الاحتياطي على الإطلاق. للتعرف على عملية إصلاح الجدول، راجع "صيانة قاعدة البيانات وإصلاحها".
تتضمن عملية الاسترداد مصدرين للمعلومات: ملفات النسخ الاحتياطي وسجلات التغيير. يقوم ملف النسخ الاحتياطي باستعادة الجدول إلى الحالة التي كان عليها عند إجراء النسخ الاحتياطي، ومع ذلك، عادةً ما يتم تعديل الجدول في الوقت بين النسخ الاحتياطي والمشكلة، ويحتوي سجل التحديث على الاستعلامات المستخدمة لإجراء هذه التعديلات. يمكنك استخدام ملفات السجل كمدخل إلى MySQL لتكرار الاستعلامات. لهذا السبب يجب عليك تمكين سجل التغيير.
تختلف عملية الاسترداد اعتمادًا على مقدار المعلومات التي يتعين عليك استردادها. في الواقع، يعد استعادة قاعدة البيانات بأكملها أسهل من استعادة جدول واحد لأنه من الأسهل تطبيق سجل التحديث على قاعدة البيانات بدلاً من تطبيقه على جدول واحد.
4.1 استعادة قاعدة البيانات بأكملها
أولاً، إذا كانت قاعدة البيانات التي تريد استعادتها هي قاعدة بيانات mysql تحتوي على جدول المنح، فأنت بحاجة إلى تشغيل الخادم باستخدام خيار --skip-grant-table. وإلا فسوف يشكو من عدم إمكانية العثور على جدول التفويض. بعد استعادة الجدول، قم بتنفيذ امتيازات تدفق mysqladmin لإخبار الخادم بتحميل رموز التفويض المميزة واستخدامها.
انسخ محتويات دليل قاعدة البيانات إلى موقع آخر إذا كنت بحاجة إليها لاحقًا.
أعد تثبيت قاعدة البيانات باستخدام أحدث ملف نسخ احتياطي. إذا كنت تستخدم الملف الذي تم إنشاؤه بواسطة mysqldump، فاستخدمه كمدخل إلى mysql. إذا كنت تستخدم الملفات المنسوخة مباشرة من قاعدة البيانات، فقم بنسخها مباشرة إلى دليل قاعدة البيانات، ومع ذلك، في هذه الحالة ستحتاج إلى إغلاق قاعدة البيانات ثم إعادة تشغيلها قبل نسخ الملفات.
استخدم سجل التحديث لتكرار الاستعلامات التي تعدل جداول قاعدة البيانات بعد النسخ الاحتياطي. بالنسبة لأي سجلات تغيير قابلة للتطبيق، قم بتمريرها كمدخل إلى mysql. يؤدي تحديد خيار --one-database إلى قيام mysql بتنفيذ الاستعلامات فقط لقاعدة البيانات التي ترغب في استعادتها. إذا كنت تعلم أنك بحاجة إلى تطبيق كافة ملفات سجل التحديث، فيمكنك استخدام هذا الأمر في الدليل الذي يحتوي على السجلات:
% ls -t -r -1 update.[0-9]* |.xargs cat |
يقوم الأمر ls بإنشاء قائمة ذات عمود واحد لملفات سجل التحديث، مرتبة وفقًا للترتيب الذي أنشأها الخادم بها (الفكرة: إذا قمت بتعديل أي من الملفات، فسوف تقوم بتغيير ترتيب الفرز، مما يؤدي إلى ظهور سجل التحديث تستخدم في الترتيب الخاطئ.)
على الأرجح ستستخدم سجلات تغيير معينة. على سبيل المثال، إذا كانت سجلات التحديث التي تم إنشاؤها منذ نسختك الاحتياطية تحمل اسم update.392، وupdate.393، وما إلى ذلك، فيمكنك إعادة التشغيل على النحو التالي:
%mysql --قاعدة بيانات واحدة db_name <update.392
%mysql --قاعدة بيانات واحدة db_name <update.393
.....
إذا كنت تجري عملية استرداد وتستخدم سجل التحديث لاستعادة المعلومات المفقودة بسبب عبارة DROP DATABASE أو DROP TABLE أو DELETE الموصى بها بشكل غير صحيح، فتأكد من حذف هذه العبارات من سجل التحديث قبل استخدامه.
4.2 استعادة جدول واحد
تعد استعادة جدول واحد أكثر تعقيدًا. إذا كنت تستخدم ملف نسخ احتياطي تم إنشاؤه بواسطة mysqldump ولا يحتوي على بيانات للجداول التي تهتم بها، فستحتاج إلى استخراجها من الصفوف ذات الصلة واستخدامها كمدخلات في mysql. هذا هو الجزء السهل. الجزء الصعب هو سحب الجزء من سجل التحديث الذي ينطبق فقط على هذا الجدول. قد تجد الأداة المساعدة mysql_find_rows مفيدة لهذا الغرض، والتي تستخرج استعلامات متعددة الصفوف من سجل التغيير.
الاحتمال الآخر هو استخدام خادم آخر لاستعادة قاعدة البيانات بأكملها ثم نسخ ملفات الجدول التي تريدها إلى قاعدة البيانات الأصلية. قد يكون هذا أمرًا سهلاً حقًا! عند نسخ الملفات مرة أخرى إلى دليل قاعدة البيانات، تأكد من إيقاف تشغيل خادم قاعدة البيانات الأصلي.