Hata: Tablo xxx için tablo alanı var. Lütfen İTHALAT'tan önce tablo alanını ATIN

MySQL için oldukça yeniyim ve google ve stackoverflow arama yoluyla herhangi bir yardım bulamadığım oldukça ilginç bir hata alıyorum.

MacOS 10.8.3 üzerinde yerel bir MySQL 5.6.10 sunucusu çalıştırıyorum ve veritabanımı MySQL için Navicat şartları üzerinden yönetiyorum.

Aldığım hata, birkaç gün / hafta boyunca veritabanımı çalıştırıp yönettikten sonra bir şeyin Navicat içinden sorguları kullanarak oluşturduğum bazı tabloları silmeye (tamamlanmamış görünüyor) tetiklemesidir.

Bu tabloları kullanarak sorgular çalıştırmayı denediğimde, Navicat bana belirli tablonun mevcut olmadığı konusunda uyarıyor. Şimdiye kadar iyi - işte iyi kısmı geliyor:

Tablo, örneğin "temp" adlı önceden oluşturmaya çalıştığımda, aşağıdaki hata iletisini alıyorum:

Error : Tablespace for table '`database`.`temp`' exists. Please DISCARD the tablespace before IMPORT.

Ancak, tabloyu bırakmaya çalışır veya bu tablo için tablo alanını atmaya çalışırsam,

DROP TABLE temp;
ALTER TABLE temp DISCARD TABLESPACE;

Aşağıdaki hata iletilerini alıyorum:

Error : Unknown table 'database.temp'
Error : Table 'database.temp' doesn't exist

Bu, tablo alanını atmamın tavsiye edildiği anlamına gelir, ancak bunu yapmaya çalıştığımda tablo mevcut değildir. DISCARD sorgusunun kontrol etmediği farklı bir yerde bu tablonun bir tür kalıntısı olabilir mi? Ve herkesin neyi tetikleyebileceğine dair bir fikri var mı - göründüğü kadarıyla rastgele?

Dediğim gibi, ben konuya yeni ve clueless. Dizüstü bilgisayarımı yeniden başlatmanın, yani yerel MySQL sunucumu sıfırlamanın veya belki de kullanıcı izni haklarının bununla ilgili olabileceğinden şüpheleniyorum, ancak burada sadece varsayımda bulunuyorum.

Biraz geç burada ama genellikle bir 'innodb_file_per_table' modunda çalışırken bir 'tablepace full' hatası aldığınızda bu sorunu gördüm. Çok fazla ayrıntıya girmeden (daha fazla burada ), veritabanı sunucusunun tablo alanı innodb_data_file_path ayarıyla tanımlanır ve varsayılan olarak oldukça küçüktür. Daha da büyütülmüş olsa da, 'tablo alanı dolu' daha büyük sorgular ile ortaya çıkabilir ve bu tür (tablo olmayan 'şeyler' orada saklanır, günlükleri, önbellekleri vb. Geri alır).

Her neyse, tablo başına dosyaların depolandığı OS dizinine bakarsanız, OSX'de varsayılan olarak / var / lib / mysql, homebrew iirc ile / usr / local / var / mysql, bir normal tamamlayıcı tablename.frm dosyası olmadan yetim tablename.ibd dosyası. Bu .ibd dosyasını güvenli bir geçici konuma taşırsanız (yalnızca güvenli olmak için) sorunu çözmesi gerekir.

$ ls /var/lib/mysql

table1.frm
table1.idb
table2.frm
table2.ibd
table3.idb <- problem table, no table3.frm
table4.frm
table4.idb

$ mkdir /tmp/mysql_orphans
$ mv /var/lib/mysql/table3.ibd /tmp/mysql_orphans/

Bir uyarı olsa da, soruna neyin yol açtığından emin olun, örneğin uzun süren sorgu, kilitli tablo vb. Aksi takdirde, ikinci kez denediğinizde başka bir artık .ibd dosyası ile sonuçlanırsınız.

Xampp ve Mamp Kullanıcıları

Bir veritabanını içe aktarırken (boşalttıktan sonra) MySQL ile aynı hatayla karşılaştık. tablename.ibdDiğerleri silinirken bir dosya kaldığını gördüm . Manuel olarak sildim mysql/data/database_nameve hata gitti.

WAMP [Windows 7 Ultimate x64-bit] Kullanıcıları için:

DangerDave'in söylediklerine katılıyorum ve bu yüzden WAMP Kullanıcıları için bir cevap hazırlıyorum .

Not: Her şeyden önce .. \ WAMP \ Bin \ MySQL \ MySQL [MySQL Sürümünüz] \ Data klasörünüze gitmelisiniz .

Şimdi, tüm veritabanlarınızın klasörlerini göreceksiniz

• Açmak için rahatsız edici tabloyu içeren veritabanının klasörünü çift tıklatın
• Bir dosya [Your offending MySQL table name].frmolmamalı, onun yerine bir dosya olmalı[Your offending MySQL table name].ibd
• Sil [Your offending MySQL table name].ibd
• Ardından, Geri Dönüşüm Kutusu'ndan da silin
• Sonra veritabanında MySQL sorgunuzu çalıştırın ve işiniz bitti

Yeniden .idbsildikten sonra yeniden oluşturursanız, bu yanıtı okuyun.

Benimle böyle çalıştı. .idbKarşılıksız dosya vardı ve dosyayı .frmher sildiğimde .idb, veritabanı yeniden oluşturun. ve çözümü MySQL belgelerinde bir satırda buldum ( Tablespace Existing part)

1- Başka bir veritabanı dizininde eşleşen bir .frm dosyası oluşturun ve yetim tablosunun bulunduğu veritabanı dizinine kopyalayın.

2- Orijinal tablo için DAMLA TABLOSU'nu düzenleyin. Bu başarıyla tablo bırakmalı ve InnoDB .ibd dosyasının eksik hata günlüğüne bir uyarı yazdırmalıdır.

Başka bir tablo .frmdosyasını kopyaladım ve eksik masam gibi adlandırdım, sonra normal bir açılan tablo sorgusu ve voila yapın, işe yaradı ve tablo normal olarak bırakıldı!

benim sistemim Windows MariaDB v 10.1.8 üzerinde XAMPP

Benim durumumda tek iş çözümü:

1. TABLO bad_tableMOTORU OLUŞTUR = MyISAM ...
2. rm bad_table.ibd
3. DAMLA TABLOSU bad_table

Bu tam olarak sanırım günlük dosyasında tam olarak aynı hataları gösteren bir tablo vardı fedora üzerinde mariadb 10.2.16 yaptım ...

2018-07-11  9:43:58 140323764213504 [Note] InnoDB: The file './database_name/innodb_table.ibd' already exists though the corresponding table did not exist in the InnoDB data dictionary. You can resolve the problem by removing the file.
2018-07-11  9:44:29 140323764213504 [Warning] InnoDB: Tablespace 'database_name/innodb_table' exists in the cache with id 2836 != 2918

Kilometre ve hatalarınız değişebilir, ancak varsaydığım en önemli şey

...already exists though the corresponding table did not exist in the InnoDB data dictionary...

açılan tablo ile çalışma değil tablo değiştirme ...

MariaDB [database_name]> drop table innodb_table;
ERROR 1051 (42S02): Unknown table 'database_name.innodb_table'

MariaDB [database_name]> alter table innodb_table discard tablespace;
ERROR 1146 (42S02): Table 'database_name.innodb_table' doesn't exist

tablo oluşturmak da böyle başarısız olur:

MariaDB [database_name]> create table  innodb_table(`id` int(10) unsigned NOT NULL);
ERROR 1813 (HY000): Tablespace for table '`database_name`.`innodb_table`' exists. Please DISCARD the tablespace before IMPORT

Bunu düzeltmek için ilk yaptığım şey

create table  innodb_table2(`id` int(10) unsigned NOT NULL);
Query OK, 0 rows affected (0.07 sec)

daha sonra / var / lib / mysql / database_name dizininde bize sorunlara neden olan innodb_table.ibd'nin üzerine yazılmasını kabul eden kök olarak aşağıdakileri yaptım

cp -a innodb_table2.frm innodb_table.frm
cp -a innodb_table2.ibd innodb_table.ibd
systemctl restart mariadb

daha sonra mysql konsolunda her iki tabloda başarılı bir bırak komutu verdim

MariaDB [database_name]> drop table innodb_table;
ERROR 2006 (HY000): MySQL server has gone away
No connection. Trying to reconnect...
Connection id:    8
Current database: database_name

Query OK, 0 rows affected (0.08 sec)

MariaDB [database_name]> drop table innodb_table2;
Query OK, 0 rows affected (0.25 sec)

ve her şey şimdi tüm kare ve tek bir tablo yeniden oluşturabilirsiniz ...

MariaDB [database_name]> create table  innodb_table (`id` int(10) unsigned NOT NULL);
Query OK, 0 rows affected (0.08 sec)

EDIT: Ben eklemek bir

restorecon -Rv /var/lib/mysql/database_name 

veritabanının kopyalanmasından sonra komut, tüm selinux bağlamlarını olması gerektiği gibi elde etmek için, onları veritabanından hemen siliyor olsak da, alternatif olarak --archive veya -a seçeneğini iki cp'ye ekleyebilirsiniz. komutları, yani evet aslında arşiv seçeneği bunu kısaltır:

cp innodb_table2.frm innodb_table.frm
cp innodb_table2.ibd innodb_table.ibd
chown mysql:mysql innodb_table.frm innodb_table.ibd
chmod 660 innodb_table.frm innodb_table.ibd
restorecon -Rv /var/lib/mysql/database_name
systemctl restart mariadb

sadece daha iyi olduğunu düşünüyorum aşağıdaki ve zaten yapılmış tablo için ayarlanmış selinux bağlam tutar.

cp -a innodb_table2.frm innodb_table.frm
cp -a innodb_table2.ibd innodb_table.ibd
systemctl restart mariadb

Daha kısa liste için daha uzun olan komutların listesini yine de kısaltılabilen bir * ile değiştirdim

Benim durumumda:

Önce tableName.ibdveritabanı dizininizden Mysql'den kaldırın ve ikinci çalıştırma:

ALTER TABLE tableName DISCARD TABLESPACE;
DROP TABLE tableName;

Bir kullanıcı tablosu oluşturmaya çalışırken wampserver üzerinde çalışan aynı hatayı aldım. Bir users.ibd dosyası buldum ve bu dosyayı sildikten sonra migrate komutunu tekrar çalıştırdım ve çalıştı. Windows makinemdeki dosya wamp / bin / mysql / mysql5.6.12 / data / myproject konumunda bulundu.

Çözüm

Ancak, daha kolay seçenek şudur: MySQL'i yeniden başlatın, ardından aşağıdaki dört adımı uygulayın:

1) created a dummy table in the database;
2) discarded its tablespace;
3) moved the .ibd file into the database folder on the system;
4) attached the tablespace back to the table

Bu şekilde, veri sözlüğündeki tablo alanı kimliği ve dosya eşleşti; böylece tablo alanının içe aktarılması başarılı oldu.

Bu, kurtarma işlemi sırasında ve hatta dosya aktarımları sırasında bazı InnoDB "gotcha's" işlemlerinde size daha fazla güven verebilir.

ref

İşte çözüm adımları:

1. veritabanınızı yedekleyin (bırakma seçeneği ve veri içeren yapı)
2. mysql motor servisini durdur
3. mysql / data içinden veritabanı dizinini el ile kaldırın
4. mysql motoru başlat
5. bozuk veritabanınızdan farklı herhangi bir adla yeni veritabanı oluşturun
6. Yeni veritabanındaki bozuk tablonun adıyla tek bir tablo oluşturun (bu sırdır). ve aynı yapıya sahip tablo oluşturmak daha iyidir.
7. veritabanını eski bozuk veritabanıyla yeniden adlandırma
8. yedeklemenizi geri yüklerseniz, tablonuz iyi çalışır.

Bu sorunu birkaç kez vardı. Büyük bir DB'niz varsa ve yedekleme / geri yükleme işleminden (eksik tablo eklenmiş olarak) kaçınmayı denemek istiyorsanız, birkaç kez ileri ve geri deneyin:

DROP TABLE my_table;

ALTER TABLE my_table DISCARD TABLESPACE;

-ve-

/ var / lib / mysql / my_db / dizininde bulunan rm my_table.ibd (karşılık gelen my_table.frm olmadan yetim)

-ve sonra-

VARSA TABLO OLUŞTUR my_table(...)

Tablename.ibd dosyasını silmek / taşımak kesinlikle benim için çalışmadı.

Nasıl çözdüm

Bozuk ve varolmayan tabloyu sileceğimden, phpmyadmin-> database-> export-> backup-> export (.sql) olarak seçilen tablolara giderek diğer tabloların yedeğini aldım.

Bundan sonra veritabanı adının yanındaki veritabanı simgesini seçip bıraktım. Yeni bir veritabanı oluşturuldu. Yeni veritabanınızı seçin -> içe aktar-> Daha önce indirdiğiniz dosyayı seçin-> içe aktar'a tıklayın. Şimdi eski çalışma tablolarım var ve bozuk tablo silindi. Şimdi sadece hatayı atan tabloyu oluşturuyorum.

Muhtemelen bozuk tabloyu daha önceki bir yedek vardı.

Bu hata, bazı işlevleri askıya aldığınızda oluşur. Aşağıdaki sorguyu yanlış yabancı anahtarla çalıştırmak gibi.

set foreign_key_checks=0

Tamamen aynı sorun vardı; Demledim mysql@5.6(daha önce 5.5 yaptıktan sonra).

5 için demlemek varsayılanı innodb_file_per_table=15.5 iken innodb_file_per_table=0.

Mevcut ibdata1dosyanızda (birleştirilmiş innodb verileri) oluşturmaya / bırakmaya çalıştığınız tablolara referanslar bulunmaya devam edecektir. Ya innodb_file_per_table0 olarak değiştirin ya da ibdata1 veri dosyasını silin ( bu size tüm verilerinizi kaybedecektir, bu yüzden önce mysqldump veya zaten bir .sql dökümü olduğundan emin olun ).

Diğer demlemek mysql@5.6beni biraz bit bir bağlantı noktası eksikliği olduğunu, bu yüzden ağ varsayılan unix soket ve mysql istemci rapor devam etti:

ERROR 2013 (HY000): Lost connection to MySQL server at 'sending authentication information', system error: 32

Eklediğim <string>--port=3306</string>için .plistdizinin, ama aynı zamanda belirtebilirsiniz port=3306içinde seninmy.cnf

Çalıştır brew services stop mysql@5.6değişikliklerini yap o zamanbrew services start mysql@5.6

Tablo alanını düşürmeye çalışmak size başka hatalar verebilir. Benim için şu hatayı aldım:

DROP TABLESPACE `tablename`

Error Code: 1478. Table storage engine 'InnoDB' does not support the create option 'TABLESPACE or LOGFILE GROUP' 

Benim çözüm veritabanını bırakmak oldu. Bu, ilişkili tüm tablo alanlarını kaldıracak ve tabloları yeniden oluşturmanıza izin verecektir.

Aynı tablonun iyi bir sürümüne sahip başka bir sunucunuz varsa, bir kopya (table_copy) oluşturabilir, table_copy dosyasını sorunlu sunucuya aktarabilirsiniz. Sonra sorun tablosunu silin ve table_copy öğesini tablo olarak yeniden adlandırın.

Benim için / var / lib / mysql / {db_name} (linux) altındaki MYSQL DATA dizinine gitmeye ve klasör adıyla aynı olan {table_name} .ibd dosyasını bırakmaya yardımcı oldu.

Sadece yerel ana bilgisayarımda bulunan eski DB'mi doğrudan wamp'tan siliyorum, Tüm hizmetleri durdurun, wamp / bin / mysql / mysql [sürüm] / veriye gidin ve problemli DB'yi buldum, siliyorum ve yeniden tüm hizmetleri yeniden başlattım, veritabanınızı yeniden oluşturun ve bitti, Artık tablolarınızı içe aktarabilirsiniz,

Bu sorunu "çözdüğümü" bulduğum yol oldukça can sıkıcı bir durum, ancak bu sorunu çözen bir senaryo var.

Esasen, ibdata1ve ib_logfile*dosyalara gitmeniz gerekir (diğer şeylerin yanı sıra yabancı anahtarların eşlemelerini içerir). Tek kasa yapmanın yolu tüm veritabanlarınızı dışa aktarmak, mysql'i durdurmak, dosyaları kaldırmak, mysql'yi başlatmak ve daha sonra dosyaları almaktır.

Bu sorunun çözülmesine yardımcı olan komut dosyası https://github.com/uberhacker/shrink-ibdata1 , bu komut dosyasının belirtilen amacı farklı olsa da sorunu çözüyor.

Benim için çalışmanın tek yolu şuydu:

1. Benzer bir tablo oluştur
2. Yeni benzer tablonun .frm ve .idb dosyalarını bozuk tablonun adına kopyalayın.
3. Düzeltme izinleri
4. MariaDB'yi yeniden başlat
5. Bozuk tabloyu bırakın

bu sorunla karşılaşırsanız ve başka bir seçeneğiniz yoksa motoru 'myisam' gibi başka bir motorla değiştirirseniz, tablo oluşturmayı deneyin.

yasal uyarı: başka bir depolama motoru tarafından desteklenmeyecek yabancı anahtar kısıtlamalarına sahip olabileceğiniz için geçerli bir yanıt değildir. Her depolama motorunun verileri saklama ve bunlara erişme konusunda kendi uzmanlıkları vardır, bu noktalar da dikkate alınmalıdır.

Lütfen İTHALAT'tan önce tablo alanını ATIN

Ben aynı sorunu var çözüm aşağıda

1. Önce veritabanı adınızı bırakmanız gerekir. eğer veritabanınız silinmiyorsa beni akıtmışsınız demektir. Windows sistemi için dizininiz C: / xampp / mysql / data / yourdabasefolder "yourdabasefolder" komutunu kaldırır

2. Yine yeni bir veritabanı oluşturmak ve eski sql dosyanızı almak zorunda. İş olacak

Teşekkürler

MySQL veri dizinimi bulmak zorunda kaldım:

Değişken_Adı "% dir" GİBİ DEĞİŞKENLERİ GÖSTER

Sonra bu veritabanını kaldırmaya zorlayın:

sudo rm -rf

Aşağıdaki sorguyu mysql kök kullanıcısı olarak çalıştırabilirsiniz

drop tablespace `tableName`

Hey Geliştiriciler zaman kaybetmeyin. Tabloları içeren veritabanını silin ve tüm tabloları tekrar içe aktarın. Zaman kazanın = zaman para demektir. Şerefe.