Eksik mysqldump

Ben bir veritabanı anlık görüntü oluşturmak için mysqldump çalıştırmak için çalışıyorum ve rastgele herhangi bir hata bildirmeden, yarıda duracak buluyorum. Veritabanım nispeten küçük (yaklaşık 100 MB) ve InnoDB kullanıyor.

Ben şu şekilde çalıştırıyorum:

mysqldump --force --single-transaction --quick --user myuser --password=mypass -h mydatabasehost mydb > /tmp/snapshot.sql

Çıkış kodu raporlarını kontrol etme 0.

Benim sürümüm: mysqldump Ver 10.13 Dağılım 5.1.52, redhat-linux-gnu için (i386)

Bazı benzer yayınlar ve hatta resmi bir hata raporu gördüm , ancak her iki çözüm de geçerli görünmüyor.

Tam bir veritabanı anlık görüntüsü almak için mysqldump nasıl alabilirim?

DÜZENLEME: Veritabanım şu anda Amazon'un RDS'sinde bulunuyor.

max_allowed_packetHem istemcide (yani mysqldump) hem de sunucuda (yani Amazon RDS) yeterince yüksek ayarlanmama sorunu olabilir . Bunu her ikisinde de 500M'ye ayarladım ve bu sorunu çözmüş görünüyor .

InnoDB'nin bilgi şeması tabloları yalnızca satır sayısı tahminleri verdiğinden, anlık görüntümün gerçekten RDS'den her şeyi içerip içermediğini söylemek zor. Tüm tablolar orada, ancak satır sayıları farklı. Daha ayrıntılı bir analiz için biraz zamanım olduğunda daha kesin bir cevapla güncelleyeceğim.

Denedin mi?

mysqldump --compress --add-drop-table data --routines --events  --comments --extended-insert -h {host} -u {user} -p {database} > dbdump.sql

Bu her zaman sorunsuz bir şekilde yaptığım gibi basit. Temel olarak dökümü bu şekilde yaparak, sahip olduğunuz her şeyi (veriler, nesneler ve bazen değerli yorumlar) belirli bir anda taahhüt edilmemiş işlemleri görmezden gelirsiniz.

Mysql dokümanlar anladığım kadarıyla - damping sırasında masada bir okuma yapılırsa tek işlem başarısız olur. "--Force --single-transaction --quick" olmadan çalışmanın sonucu nedir?

Tablonun bozuk olması tamamen mümkündür. Veri ve / veya dizin sayfalarının hasarlı olduğu anlamına gelmez. Kırılmış çok basit bir şey olabilir.

Yakın zamanda birden çok veritabanını mysqldumped paralel bir Slave Server yedekleme komut dosyası ile ilgili bir sorun yaşadım. Bir veritabanında mysqldump çalıştırmak çok küçük bir mysqldump ile sonuçlandı. DB 80 + tabloları vardı. Ancak, mysqldump DB beşinci masada durdu. SHOW CREATE TABLE tblname\GSlave masaya koştuğumda , "Table Not Found" hatasını aldım. SHOW CREATE TABLE tblname\GMaster'da koştuğumda , tablo açıklaması beklendiği gibi görüntüleniyordu.

Olanlar biraz çılgınca oldu: Bir müşteri tablonun geri yüklenmesini istedi ve bir mühendis InnoDB tablosunun .ibd dosyasını bir disk yedeklemesinden geri yükledi. .İbd dosyasının (25 olan) tablo alanı kimliği, ibdata1'e (28 olan) kaydedilen tablo alanı kimliğiyle eşleşmedi.

Ben köle hosing, ustası mysqldumping ve sıfırdan çoğaltma kurarak sorunu çözdüm. Neyse ki, veri ve endeks toplam 7GB çıktı. Dolayısıyla rstore süreci büyük bir mesele değildi.

HİKAYEDEN ÇIKARILACAK DERS

Temel sorun, tablo alanı kimliği yanlış olduğunda mysqldump bir InnoDB hata bildirmez olmasıdır. Bir mysqldump, her tabloyu alfabetik sırayla bitirdiğinde ve dökmediğinde, bunun bir hata ile sonlandığını ve bir hata mesajı yazdırmadan yaptığını gösterir.

Emin olmak için kontrol edin

• kullanarak tablonun yapısını görüntüleyebilirsiniz SHOW CREATE TABLE
• bir tablo hakkındaki her şeyi BİLGİ_SCHEMA.TABLES'den sorgulayabilirsiniz

Aşağıdaki sadece mysqldump ve InnoDB üzerinde beyin fırtınası:

Lütfen mysqldump'ın bir InnoDB tablosuna karşı davranışını düşünün. InnoDB Arabellek Havuzu'nda, döktüğünüz bir tabloya ait kirli sayfalar varsa, o tablonun kirli sayfaları, SELECT /* SQL_NO_CACHE */yürütülebilmesi için önce diske boşaltılmalıdır .

Amazon RDS kullandığınız için, bağırsak hissim, veritabanınızın çok yönlü bir altyapıda olmasıdır (Bunu aşırı basitleştiriyorsam bu ifadeyi düzeltmekten çekinmeyin). Diğer veritabanları paylaşılan bir InnoDB Arabellek Havuzu, paylaşılan bir meta veri dosyası (ibdata1) ve paylaşılan bir tablo alanı (innodb_file_per_table devre dışı bırakılmışsa ibdata1 ) kullanıyor olabilir.

Küçük bir veri kümesi olmasına rağmen, veritabanında MVCC'yi etkileyebilecek bazı veritabanı yedekliliği de olabilir .

Amazon RDS üzerinde herhangi bir etkisi olup olmadığını (veya Amazon'un bu sınırı artırmasını) görmek için mysqldump oturumunuzda innodb_lock_wait_timeout'u (varsayılan 50 saniye) artırmak isteyebilirsiniz . Ayrıca, tabloları tek tek dökerek denemeyi deneyin.

GÜNCELLEME 2011-11-14 17:58 EDT

Bunu DB Oturumunuzda yürütmeyi deneyin (iki dakikaya ayarlar):

SET innodb_lock_wait_timeout = 120;