Secara bawaan mysqldump mengunci tabel supaya dump-nya runut. Pada basis data kecil itu makan waktu sedetik. Pada yang besar, situsnya membeku bermenit-menit, dan cadangan malam berubah menjadi gangguan malam.

Tandanya

mysqldump --single-transaction --quick --routines --triggers \
          --default-character-set=utf8mb4 shop | gzip > shop.sql.gz

--single-transaction mengambil citra yang runut lewat sistem pembuatan versi milik InnoDB sendiri: yang membaca dan yang menulis tetap berjalan, dan dump-nya tetap melihat satu titik waktu.

Dua syaratnya

  • Hanya InnoDB. Tabel MyISAM di basis data yang sama akan di-dump tanpa jaminan itu. Ubahlah: ALTER TABLE t ENGINE=InnoDB;
  • Tidak boleh ada perubahan skema selama dump. Sebuah ALTER TABLE saat ia berjalan bisa merusaknya — jadi jangan menjalankan migrasi dan pencadangan pada saat yang sama.

Kalau basis datanya besar

# 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

Sebuah salinan mengangkat bebannya sepenuhnya dari basis data yang sedang melayani. Perkakas fisik menyalin berkasnya alih-alih membangkitkan SQL, dan itu jauh lebih cepat dipulihkan untuk apa pun di atas beberapa puluh gigabita.

Awasi ongkosnya selagi berjalan

mysql -e "SHOW PROCESSLIST" | head -20
mysql -e "SHOW ENGINE INNODB STATUS\G" | grep -A5 "TRANSACTIONS"
Dump --single-transaction yang panjang memaksa InnoDB menyimpan versi baris lama selama seluruh durasinya, sehingga log pembatalannya membengkak. Untuk hitungan menit itu tak apa, untuk hitungan jam itu masalah — dan di titik itulah jawabannya adalah salinan atau cadangan fisik.

Apa yang harus diperiksa pada berkas yang sudah jadi ada di Dump yang benar-benar bisa dipulihkan.