في هذا الدرس 6تصفّح المواضيع
تعتمد خطط التعافي من الكوارث (Disaster Recovery) في بيئات الإنتاج على التمييز الهندسي الدقيق بين نوعين أساسيين من النسخ الاحتياطي في MySQL:
- 1. النسخ الاحتياطي المنطقي (Logical Backups — مثل أداة
mysqldump): يستخرج هيكل الجداول والبيانات على هيئة أوامر SQL نصية قياسية (CREATE TABLEوINSERT INTO).- المزايا: مستقل عن نظام التشغيل، وسهل الفحص النصي، ومثالي لنقل قواعد البيانات بين الإصدارات أو استعادة جدول واحد بعينه.
- التكلفة: يستغرق وقتاً أطول عند استعادة قواعد البيانات الضخمة جداً لأنه يعيد تنفيذ جمل الإدراج وبناء الفهارس.
- 2. النسخ الاحتياطي الفيزيائي (Physical Backups — مثل
Clone Pluginو Percona XtraBackup): ينسخ ملفات محرك التخزين الخام (.ibd) وسجلاتRedo Logمباشرةً على مستوى القرص.- المزايا: سرعة فائقة في نسخ واستعادة قواعد البيانات التي تتجاوز مئات الجيجابايتات.
- القاعدة الذهبية 3-2-1 للنسخ الاحتياطي: احتفظ بـ 3 نسخ من بياناتك، على وسيلتي تخزين (2) مختلفتين، مع نسخة واحدة (1) مشفرة في موقع جغرافي أو سحابي معزول تماماً.
SELECT TABLE_SCHEMA AS db_name,
COUNT(*) AS table_count,
ROUND(SUM(DATA_LENGTH + INDEX_LENGTH) / 1024 / 1024, 2) AS total_mb
FROM information_schema.TABLES
WHERE TABLE_SCHEMA = 'shop_db'
GROUP BY TABLE_SCHEMA;عند أخذ نسخة احتياطية من قاعدة بيانات إنتاجية تعمل بمحرك InnoDB عبر أداة mysqldump، فإن الخيار الأهم على الإطلاق هو --single-transaction:
- كيف يعمل الخيار
--single-transactionداخلياً؟ يقوم برنامجmysqldumpبضبط مستوى عزل الجلسة علىREPEATABLE READثم يبدأ معاملة موحدة عبر الأمرSTART TRANSACTION WITH CONSISTENT SNAPSHOTقبل قراءة أي جدول. - نسخ احتياطي متسق دون إيقاف الموقع (Online Backup): بفضل تقنية تعدد النسخ (MVCC) في محرك InnoDB، تقرأ أداة
mysqldumpلقطة زمنية متسقة تماماً لجميع الجداول في نفس اللحظة دون قفل الجداول أو تعطيل عمليات الشراء والتحديث الجارية في الموقع. --quick: يسحب الصفوف من الخادم صفاً تلو الآخر مباشرة إلى ملف النسخة الاحتياطية بدلاً من تحميل الجدول الضخم بالكامل في الذاكرة العشوائية (RAM).--databases shop_db: يكتب أوامرCREATE DATABASE IF NOT EXISTSوUSE shop_dbتلقائياً في مطلع ملف النسخة.
-- الأمر المنفذ في طرفية النظام (OS Terminal):
mysqldump -u root -p --single-transaction --quick --databases shop_db > shop_db_full.sql-- What mysqldump --single-transaction executes on the server:
SET SESSION TRANSACTION ISOLATION LEVEL REPEATABLE READ;
START TRANSACTION WITH CONSISTENT SNAPSHOT;
-- Shell command to create an online compressed InnoDB backup:
-- mysqldump -u root -p --single-transaction --quick --databases shop_db > shop_db_full.sqlمحاكي النسخ الاحتياطي والاستعادة (mysqldump & PITR) في MySQL 8
من أشهر الأخطاء الكارثية في بيئات الإنتاج الاكتفاء بالأمر الافتراضي لـ mysqldump ثم اكتشاف اختفاء الإجراءات المخزنة والدوال والأحداث المجدولة عند استعادة النسخة! لذا يجب معرفة الخيارات الإلزامية لتضمين كافة الكائنات البرمجية:
--triggers(مُفعّل افتراضياً): يتم نسخ المشغلات التلقائية (Triggers) المرتبطة بالجداول افتراضياً دون الحاجة لكتابة الخيار.--routines(يجب إضافته صراحةً): ضروري لتضمين كافة الإجراءات المخزنة (PROCEDURES) والدوال (FUNCTIONS) في ملف النسخة.--events(يجب إضافته صراحةً): ضروري لتضمين المهام الزمنية المجدولة (EVENTS).--no-data(أو الاختصار-d): ينسخ هيكل الجداول والفهارس والقيود فقط (CREATE TABLE) دون أي صفوف بيانات، وهو مثالي لإنشاء بيئات الاختبار الفارغة.--no-create-info(أو الاختصار-t): ينسخ بيانات الصفوف (INSERT) فقط دون جمل إنشاء الجداول.
-- Verify routines, triggers, and events in shop_db before dumping:
SELECT ROUTINE_TYPE, ROUTINE_NAME
FROM information_schema.ROUTINES
WHERE ROUTINE_SCHEMA = 'shop_db';
-- Complete production mysqldump command including routines & events:
-- mysqldump -u root -p --single-transaction --routines --events --triggers shop_db > shop_complete.sql
-- Schema-only dump (no row data):
-- mysqldump -u root -p --no-data --routines --events shop_db > shop_schema_only.sqlلا قيمة لأي نسخة احتياطية ما لم تتقن خطوات استعادتها والتحقق من سلامتها عملياً. وبما أن مخرجات أداة mysqldump عبارة عن ملف أوامر SQL قياسي، يمكنك استعادته بطريقتين أساسيتين:
- الطريقة الأولى — الأمر التفاعلي
SOURCEداخل عميل MySQL: اتصل بالخادم، أنشئ قاعدة البيانات المستهدفة واخترها بأمرUSE، ثم نفّذSOURCE /backups/shop_complete.sql;. - الطريقة الثانية — إعادة التوجيه من طرفية النظام: نفّذ الأمر
mysql -u root -p shop_db < shop_complete.sqlمباشرة من سطر الأوامر. - تسريع الاستعادة التلقائي: يضيف
mysqldumpفي بداية الملف تلقائياً أوامرSET FOREIGN_KEY_CHECKS = 0;لتعطيل فحص المفاتيح الأجنبية مؤقتاً أثناء تحميل الجداول المترابطة بأقصى سرعة، ثم يعيد تفعيلها (= 1) في نهاية الملف. - اختبار الاستعادة الدوري (Restore Drill): استعد النسخة دورياً داخل قاعدة بيانات تجريبية منفصلة (
shop_db_restore_test) للتأكد من اكتمال الجداول والصفوف.
Database changed
Query OK, 0 rows affected (0.02 sec)
+---------------+-----------+
| table_name | row_count |
+---------------+-----------+
| customers | 1250 |
| orders | 8420 |
+---------------+-----------+CREATE DATABASE IF NOT EXISTS shop_db_restore_test
CHARACTER SET utf8mb4
COLLATE utf8mb4_0900_ai_ci;
USE shop_db_restore_test;
-- Inside the mysql interactive client, execute the SQL dump file:
-- SOURCE /backups/shop_complete.sql;
SHOW TABLES;ماذا لو أُخذت النسخة الاحتياطية اليومية الساعة 03:00 فجراً، وفي الساعة 14:30 ظهراً نفّذ أحدهم أمر حذف خاطئ؟ إن الاكتفاء باستعادة نسخة الفجر سيعني ضياع مبيعات 11 ساعة ونصف! وهنا تبرز أهمية الاستعادة إلى نقطة زمنية محددة (Point-in-Time Recovery — PITR) بالجمع بين النسخة الاحتياطية والسجل الثنائي (Binary Log):
- 1. تسجيل موقع السجل الثنائي لحظة النسخ: تمرير الخيار
--source-data=2لأداةmysqldumpيسجل كتعليق داخل ملف النسخة اسم ملف السجل الثنائي ورقم الموقع الدقيق (Position) لحظة أخذ اللقطة. - 2. استعادة النسخة الأساسية (03:00 فجراً): نستعيد ملف
mysqldumpأولاً لإرجاع قاعدة البيانات إلى حالة الساعة الثالثة فجراً. - 3. إعادة تطبيق السجل الثنائي حتى الثانية التي سبقت الخطأ: نستخدم أداة
mysqlbinlogمع تحديد نقطة البداية وتحديد وقت التوقف--stop-datetime="2026-11-01 14:29:59"(قبل الحذف بثانية واحدة) لتمرير جميع العمليات السليمة إلى الخادم. SHOW BINARY LOGS;: يعرض قائمة ملفات السجل الثنائي المتاحة في الخادم.
+------------------+----------+--------------+------------------+
| File | Position | Binlog_Do_DB | Binlog_Ignore_DB |
+------------------+----------+--------------+------------------+
| binlog.000042 | 104856 | | |
+------------------+----------+--------------+------------------+SHOW VARIABLES LIKE 'log_bin';
SHOW BINARY LOGS;
-- 1. Take nightly dump with binlog coordinates recorded as comment:
-- mysqldump -u root -p --single-transaction --source-data=2 shop_db > shop_base.sql
-- 2. Replay binlog events up to 14:29:59 (before accidental DELETE at 14:30:00):
-- mysqlbinlog --start-position=157 --stop-datetime="2026-11-01 14:29:59" binlog.000042 | mysql -u root -p shop_dbيلخص الجدول المرجعي التالي أهم خيارات أداة mysqldump وأدوات الاستعادة الكاملة والزمنية في MySQL 8:
| الخيار / الأداة | الصياغة القياسية | الوظيفة الهندسية في بيئة الإنتاج |
|---|---|---|
--single-transaction | mysqldump --single-transaction ... | أخذ نسخة متسقة لجداول InnoDB عبر MVCC دون قفل الجداول |
--routines --events | mysqldump --routines --events ... | تضمين الإجراءات المخزنة والدوال والأحداث المجدولة |
--no-data | mysqldump --no-data shop_db | تصدير هيكل الجداول والفهارس فقط دون صفوف البيانات |
--source-data=2 | mysqldump --source-data=2 ... | تسجيل اسم وموقع السجل الثنائي داخل النسخة لعمليات PITR |
SOURCE / الاستعادة | SOURCE dump.sql; أو mysql < dump.sql | إعادة بناء الجداول والبيانات من ملف النسخة المنطقية |
mysqlbinlog | mysqlbinlog --stop-datetime=... | الاستعادة الزمنية الدقيقة (PITR) حتى لحظة ما قبل الخطأ |
ملخص الدرس: تعلمت في هذا الدرس الفرق بين النسخ المنطقي والفيزيائي، وكيفية أخذ نسخ احتياطية حية متسقة عبر mysqldump --single-transaction --routines --events، واستعادتها بأمر SOURCE، وتنفيذ الاستعادة الزمنية (PITR) بالسجل الثنائي.
الخطوة التالية والدرس القادم: انتقل إلى الدرس الختامي للدورة لتعلّم الحماية الشاملة من ثغرات حقن قواعد البيانات (SQL Injection) واستخدام الاستعلامات المحضرة (PREPARE / EXECUTE).
ملخص الدرس
حصاد الدرسمراجعة مركّزة لأهم المفاهيم والقواعد الهندسية التي أتقنتها في هذا الدرس قبل التطبيق العملي
ماذا تعلّمت في هذا الدرس؟
يضمن الدمج بين النسخ الاحتياطي الدوري عبر mysqldump --single-transaction --routines --events --source-data=2 والسجل الثنائي (Binary Log) حماية البيانات واستعادتها حتى مستوى الثانية الواحدة. الخطوة التالية: انتقل الآن إلى الدرس الختامي «الحماية من حقن قواعد البيانات SQL Injection والاستعلامات المحضرة في MySQL».
سجّل الدخول لحفظ تقدمك
تابع إنجاز المواضيع والمصطلحات والمهام، وكمّل من آخر خطوة على أي جهاز.
المصطلحات4
راجع المعنى، اشرحه لنفسك، ثم علّم البطاقة كمفهومة.
- 01 Database Backups النسخ الاحتياطي
- تعلّم النسخ الاحتياطي واستعادة قواعد البيانات عبر أداة mysqldump والخيار --single-transaction والاستعادة الزمنية (PITR) في MySQL 8.
- للمراجعة
- 02 Logical vs Physical Database Backups النسخ المنطقي مقابل الفيزيائي
- المفهوم الهندسي الأساسي والصياغة التطبيقية لقسم النسخ المنطقي مقابل الفيزيائي في خادم MySQL 8.4.
- للمراجعة
- 03 Online InnoDB Dump Single Transaction النسخ المتسق بـ mysqldump
- المفهوم الهندسي الأساسي والصياغة التطبيقية لقسم النسخ المتسق بـ mysqldump في خادم MySQL 8.4.
- للمراجعة
- 04 Backing Up Routines and Schema نسخ الإجراءات والمشغلات والهيكل
- المفهوم الهندسي الأساسي والصياغة التطبيقية لقسم نسخ الإجراءات والمشغلات والهيكل في خادم MySQL 8.4.
- للمراجعة
لا توجد بطاقات تطابق البحث والتصفية.
اقرأ البطاقات بحرية. سجّل الدخول لحفظ تقدم مراجعتك.
الاختصارات4
راجع المعنى، اشرحه لنفسك، ثم علّم البطاقة كمفهومة.
- 01 PITR PITR
- Point-in-Time Recovery
- الاستعادة إلى نقطة زمنية محددة عبر دمج النسخة الاحتياطية الأساسية مع إعادة تطبيق أحداث السجل الثنائي حتى اللحظة المطلوبة.
- للمراجعة
- 02 RPO RPO
- Recovery Point Objective
- الحد الأقصى المقبول زمنياً للبيانات التي قد تُفقد عند وقوع عطل (ويُقلص إلى ثوانٍ معدودة عبر السجل الثنائي).
- للمراجعة
- 03 RTO RTO
- Recovery Time Objective
- الزمن الأقصى المستهدف لاستعادة تشغيل قاعدة البيانات بالكامل بعد التوقف.
- للمراجعة
- 04 GTID GTID
- Global Transaction Identifier
- المعرّف العالمي الفريد لكل معاملة معتمدة في خادم MySQL لتتبع النسخ المتماثل والنسخ الاحتياطي.
- للمراجعة
لا توجد بطاقات تطابق البحث والتصفية.
اقرأ البطاقات بحرية. سجّل الدخول لحفظ تقدم مراجعتك.
مهامك قبل الاختبار
خطوة صغيرة كل مرة. وإنجاز تقدر ترجع له.
-
نفّذ جمل SQL الواردة في قسم النسخ المنطقي مقابل الفيزيائي داخل بيئة MySQL 8 المحلية وتحقق من المخرجات.
-
جرّب الحالات الثلاث داخل محاكي النسخ الاحتياطي والاستعادة (mysqldump & PITR) في MySQL 8 في قسم النسخ المتسق بـ mysqldump وقارن سلوك المحرك.
تأشير المهمة إقرار منك بإتمامها، وليس تصحيحًا آليًا للكود. يُحفظ تقدمك في حسابك.
اختبر فهمك.
ووصلها للإتقان.
كل سؤال خطوة لقدّام. اختار، اكتب كود، وشوف نتيجتك فورًا.
أكمل المهام، واجمع كل الإجابات الصحيحة. أقل من 100%؟ راجع وأعد المحاولة.
الأسئلة متاحة للاطلاع. سجّل الدخول للتفاعل وحفظ تقدمك.
لمحة عن التحدي6 أسئلة تنتظرك ＋
أي خيار في أداة mysqldump يبدأ معاملة لقطة متسقة (REPEATABLE READ) لنسخ جداول InnoDB أثناء عمل الموقع دون قفل الجداول؟
يعتمد الخيار --single-transaction على تقنية MVCC في محرك InnoDB لأخذ نسخة متسقة دون إيقاف عمليات القراءة والكتابة.
ما الخياران اللذان يجب إضافتهما صراحةً لأمر mysqldump لتضمين الإجراءات والدوال المخزنة والأحداث المجدولة داخل ملف النسخة الاحتياطية؟
يضمّن mysqldump المشغلات افتراضياً، لكنه يتطلب إضافة --routines و --events لتصدير الإجراءات والدوال والأحداث المجدولة.
أي خيار في أداة mysqldump يصدر هيكل الجداول (CREATE TABLE) فقط دون تصدير أي صفوف بيانات؟
يصدر الخيار --no-data هيكل الجداول والفهارس فقط دون جمل إدراج البيانات.
داخل جلسة عميل mysql التفاعلية، أي أمر يُستخدم لتشغيل واستعادة ملف نسخة احتياطية بصيغة SQL؟
يقرأ الأمر SOURCE مسار ملف SQL وينفذ كافة الجمل الموجودة بداخله لاستعادة قاعدة البيانات.
أي أداة في MySQL تُستخدم مع النسخة الاحتياطية الأساسية لإعادة تطبيق أحداث السجل الثنائي حتى لحظة زمنية محددة (PITR)؟
تُستخدم أداة mysqlbinlog لقراءة ملفات السجل الثنائي وإعادة تطبيق العمليات حتى اللحظة المحددة عبر --stop-datetime.
تحتوي النسخة الاحتياطية المنطقية الناتجة عن أداة mysqldump على أوامر SQL قياسية مثل CREATE TABLE و INSERT INTO لإعادة بناء الجداول والبيانات.
صواب؛ يحفظ النسخ الاحتياطي المنطقي هيكل الجداول والصفوف على هيئة أوامر SQL قابلة للتنفيذ.