الأمر mysqldump يُقفل الجداول افتراضيًّا كي تكون النسخة متّسقة. وعلى قاعدة صغيرة يستغرق ثانية. أمّا على كبيرة فيتجمّد الموقع دقائق، وتصير النسخة الليلية انقطاعًا ليليًّا.
الراية
mysqldump --single-transaction --quick --routines --triggers \
--default-character-set=utf8mb4 shop | gzip > shop.sql.gz
الراية --single-transaction تأخذ لقطةً متّسقة عبر نظام الإصدارات في InnoDB نفسه: القارئون والكاتبون يواصلون، والنسخة ترى مع ذلك لحظة زمنية واحدة.
وشرطاها
- InnoDB وحده. وجدول MyISAM في القاعدة نفسها يُنسَخ بلا ذلك الضمان. حوّلها:
ALTER TABLE t ENGINE=InnoDB; - ولا تغيير في البنية أثناء النسخ. فـALTER TABLE وهو يعمل قد يكسره — فلا تُشغّل الترحيلات والنسخ الاحتياطي في وقت واحد.
وإن كانت القاعدة كبيرة
# dump from a replica instead of production
mysqldump --single-transaction -h replica.internal shop | gzip > shop.sql.gz
# or use a physical tool
xtrabackup --backup --target-dir=/srv/backup/full
نسخةٌ تابعة ترفع الحِمل عن القاعدة الحيّة تمامًا. والأدوات الفيزيائية تنسخ الملفّات بدل توليد SQL، وهي أسرع بكثير في الاستعادة لأي شيء فوق بضع عشرات من الجيغابايت.
وراقب ما يكلّفه وهو يعمل
mysql -e "SHOW PROCESSLIST" | head -20
mysql -e "SHOW ENGINE INNODB STATUS\G" | grep -A5 "TRANSACTIONS"
نسخةٌ طويلة بـ--single-transaction تجعل InnoDB يحتفظ بإصدارات الصفوف القديمة طوال مدّتها، فينمو سجلّ التراجع. لا بأس بذلك لدقائق، ويصير مشكلة لساعات — وعند تلك النقطة تكون النسخة التابعة أو النسخ الفيزيائيّ هي الجواب.
وما يُفحَص في الملفّ المكتمل موجود في النسخ التي تُستعاد فعلًا.