mysqldump, dökümün tutarlı olması için varsayılan olarak tabloları kilitler. Küçük bir veritabanında bu bir saniye sürer. Büyük bir veritabanında ise site dakikalarca donar ve gecelik yedek, gecelik kesintiye dönüşür.

Seçenek

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

--single-transaction, InnoDB'nin kendi sürümleme düzenini kullanarak tutarlı bir anlık görüntü alır: okuyanlar ve yazanlar işine devam eder, döküm yine de tek bir zaman noktasını görür.

İki koşulu

  • Yalnızca InnoDB. Aynı veritabanındaki bir MyISAM tablosu bu güvence olmadan dökülür. Onları dönüştürün: ALTER TABLE t ENGINE=InnoDB;
  • Döküm sürerken şema değişikliği olmasın. Çalışırken atılan bir ALTER TABLE dökümü bozabilir — bu yüzden göçlerle yedekleri aynı anda çalıştırmayın.

Veritabanı büyükse

# 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

Bir kopya, yükü yayındaki veritabanının üzerinden tümüyle alır. Fiziksel araçlar SQL üretmek yerine dosyaları kopyalar; birkaç on gigabaytın üstündeki her şey için geri yüklemesi çok daha hızlıdır.

Çalışırken neye mal olduğunu izleyin

mysql -e "SHOW PROCESSLIST" | head -20
mysql -e "SHOW ENGINE INNODB STATUS\G" | grep -A5 "TRANSACTIONS"
Uzun süren bir --single-transaction dökümü, InnoDB'yi bütün o süre boyunca eski satır sürümlerini tutmaya zorlar, dolayısıyla geri alma kaydı büyür. Dakikalar için sorun değildir, saatler için sorundur — ve tam o noktada yanıt bir kopya ya da fiziksel yedektir.

Bitmiş dosyada nelere bakılacağı Gerçekten geri yüklenebilen dökümler yazısında.