GERÇEKLER
Kullandığını söyledin ext4. Dosya boyutu sınırı 16TB'dir. Bu nedenle, Sample.ibddolu olmamalıdır.
Eğer söz konusu innodb_data_file_pathIS ibdata1:10M:autoextend. Bu nedenle, ibdata1 dosyasının kendisi işletim sistemi dışında boyutuna sahip değildir.
Bu mesaj neden geliyor? "Masa ... dolu" mesajı değil, "Disk ... dolu" değil. Bu tablo tam koşulu, mantıksal bir bakış açısındandır . InnoDB'yi düşünün. Hangi etkileşimler devam ediyor?
Tahminimce InnoDB 93GB veriyi tek bir işlem olarak yüklemeye çalışıyor. Nerede olacağını Table is Fullmesajı kaynaklanmıyor? İbdata1'a, fiziksel boyutuna (zaten ekarte ettiğin) değil, hangi işlem limitlerine ulaşıldığına bakacağım.
İnnodb_file_per_table etkinleştirildiğinde ve MySQL'e yeni veriler yüklediğinizde ibdata1'in içinde ne var ?
Şüphelerim bana Undo Logs ve / veya Redo Logs'un suçlu olduğunu söylüyor.
Bu kayıtlar nedir? Göre Kitabı
Bölüm 10: "Depolama Motorları" Sayfa 201 Paragraf 3,4 şunları söylüyor:
InnoDB motoru iki tür kütüğü tutar: bir geri alma günlüğü ve bir geri yükleme günlüğü. Geri alma günlüğünün amacı, işlemleri geri almak ve onu gerektiren işlem yalıtım düzeyinde çalışan sorgular için verilerin eski sürümlerini görüntülemektir. Geri alma günlüğünü işleyen kod storage / innobase / buf / log / log0log.c dosyasında bulunabilir. .
Yineleme günlüğünün amacı, kilitlenme kurtarmasında kullanılacak bilgileri depolamaktır. Kurtarma işleminin, çökmeden önce tamamlanmış veya tamamlanmamış işlemleri tekrar gerçekleştirmesine izin verir. Bu işlemleri tekrar yaptıktan sonra veritabanı tutarlı bir duruma getirilir. Yineleme günlüğü ile ilgili kod storage / innobase / log / log0recv.c dosyasında bulunabilir .
ANALİZ
İbdata1 içinde 1023 Geri Alma Günlüğü vardır (Bkz. Geri Alma Segmentleri ve Geri Alma Alanı) . Geri alma günlükleri, yeniden yüklemeden önce göründükleri gibi verilerin kopyalarını sakladığından, tüm 1023 Geri Al Günlükleri sınırına ulaşmıştır. Başka bir açıdan bakıldığında, 1023 Geri Al Kayıtlarının tümü, yükü alan bir işleme tahsis edilebilir.Sample tabloyu .
FAKAT BEKLE...
Muhtemelen "Boş bir Samplemasa yüklüyorum" diyorsunuz . Geri Al günlükleri nasıl dahil edilir? SampleTablo 93GB'lık veri ile yüklenmeden önce boştu. Varolmayan her sırayı temsil etmek, Geri Al Günlüklerinde bazı ev temizliği alanını almak zorundadır. 1023'ü doldurun Geri Alma Günlükleri, içine dökülen veri miktarı göz önüne alındığında önemsiz görünmektedir ibdata1. Bundan şüphelenen ilk kişi ben değilim:
MySQL 4.1 Dokümantasyonundan not Posted by Chris Calender on September 4 2009 4:25pm:
5.0'da (5.0.85 öncesi) ve 5.1'de (5.1.38 öncesi), InnoDB'de geri alma yuvalarının bitmesi durumunda bir InnoDB tablosu için "tablo dolu" hatası alabileceğinize dikkat edin (hata # 18828).
İşte MySQL 5.0 için hata raporu: http://bugs.mysql.com/bug.php?id=18828
ÖNERİLER
SampleTablonun mysqldump'unu oluşturduğunuzda , lütfen --no-autocommit kullanın.
mysqldump --no-autocommit ... mydb Sample > Sample.sql
Bu COMMIT;her şeyden sonra açık bırakacak INSERT. Sonra tabloyu yeniden yükleyin.
Bu işe yaramazsa ( bundan hoşlanmayacaksınız ), bunu yapın
mysqldump --no-autocommit --skip-extended-insert ... mydb Sample > Sample.sql
Bu her INSERT'in sadece bir satır olmasına neden olur. MySQLDump çok daha büyük olacak (10+ kat daha büyük) ve yeniden yüklenmesi 10 ila 100 kat daha uzun sürebilir.
Her iki durumda da, bu Geri Al Günlüklerinin su altında kalmasını önler.
Bir şans ver !!!
GÜNCELLEME 2013-06-03 13:05 EDT
EK ÖNERİ
InnoDB sistem tablosu (aka ibdata1) bir dosya boyutu sınırına uyuyorsa ve Geri Al Günlükleri kullanılamıyorsa, başka bir sistem tablo alanı (ibdata2) ekleyebilirsiniz.
Bu duruma daha iki gün önce rastladım. Bkz: Ben yaptım ne benim eski yazı güncellenen Çoklu veritabanlarını oluşturma tablo boyutuna limit baş ağrısı önlemek için - Veritabanı Tasarımı
Özünde, yeni bir sistem tablo alanı dosyası yerleştirmek için innodb_data_file_path değiştirmelisiniz . Nasıl açıklayayım:
SENARYO
Diskte (ext3) müşterimin sunucusunda aşağıdakiler vardı:
[root@l*****]# ls -l ibd*
-rw-rw---- 1 s-em7-mysql s-em7-mysql 362807296 Jun 2 00:15 ibdata1
-rw-rw---- 1 s-em7-mysql s-em7-mysql 2196875759616 Jun 2 00:15 ibdata2
Ayar yapıldı
innodb_data_file_path=ibdata1:346M;ibdata2:500M:autoextend:max:10240000M
Bu ibdata22196875759616 olan büyüdü ki 2145386484M.
' ibdata2İn dosya boyutunu innodb_data_file_path içine gömmek ve eklemek zorunda kaldımibdata3
innodb_data_file_path=ibdata1:346M;ibdata2:2196875759616;ibdata3:10M:autoextend
MySQL'i yeniden başlattığımda, işe yaradı:
[root@l*****]# ls -l ibd*
-rw-rw---- 1 s-em7-mysql s-em7-mysql 362807296 Jun 3 17:02 ibdata1
-rw-rw---- 1 s-em7-mysql s-em7-mysql 2196875759616 Jun 3 17:02 ibdata2
-rw-rw---- 1 s-em7-mysql s-em7-mysql 32315015168 Jun 3 17:02 ibdata3
40 saat ibdata3içinde 31G'ye çıktı. MySQL bir kez daha çalışıyordu.