Schrödingers MySQL tablosu: var, ancak yok

En tuhaf hatayı yaşıyorum.

Bazen tabloları oluştururken veya değiştirirken 'tablo zaten var' hatası alıyorum. Ancak DROP TABLE, '# 1051 - bilinmeyen tablo' döndürür. Yani yaratamadığım, düşemediğim bir masam var.

Veritabanını bırakmaya çalıştığımda mysqld çöküyor. Bazen farklı bir adla başka bir db oluşturmak yardımcı olur, bazen yaramaz.

~ 50 tablo içeren bir DB kullanıyorum, tümü InnoDB. Bu sorun, farklı tablolarda ortaya çıkar.

Bunu Windows, Fedora ve Ubuntu, MySQL 5.1 ve 5.5'te yaşadım. PDO, PHPMyAdmin veya komut satırı kullanırken aynı davranış. Şemamı yönetmek için MySQL Workbench kullanıyorum - bazı ilgili hatalar gördüm (bitiş çizgileri ve şeyler), ancak bunların hiçbiri benim için geçerli değildi.

Hayır, bu bir manzara değil, bir masadır. Tüm isimler küçük harflidir.

Google yapabildiğim her şeyi denedim - tabloları temizlemek, .frm dosyalarını db'den db'ye taşımak, mysql günlüğünü okumak, lanet olası şeyi yeniden yüklemek dışında hiçbir şey yardımcı olmadı.

'Tabloları göster' hiçbir şey göstermez, 'açıklama' tablosu 'tablo yok' diyor, .frm dosyası yok, ancak 'tablo oluştur' hala bir hatayla bitiyor (ve 'yoksa tablo oluştur' da öyle) ve bırakarak veritabanı çöküyor mysql

Alakalı, ancak yararsız sorular:

• Mysql 1050 Hatası "Tablo zaten var", aslında değil

• MySQL Tablosu hata yok, ancak mevcut

Düzenle:

mysql> use askyou;
Database changed

mysql> show tables;
Empty set (0.00 sec)

mysql> create table users_has_friends (id int primary key);
ERROR 1050 (42S01): Table '`askyou`.`users_has_friends`' already exists

mysql> drop table users_has_friends;
ERROR 1051 (42S02): Unknown table 'users_has_friends'

Ve böyle, hepsi aynı: tablo mevcut değil, henüz oluşturulamaz;

mysql> drop database askyou;
ERROR 2013 (HY000): Lost connection to MySQL server during query

Adlar değişiyor, sorun yaşadığım tek tablo / veritabanı bu değil

Bu sorunu, veri dosyası veri dizininde eksik, ancak tablo tanımlama dosyası mevcut veya tam tersi olduğunda gördüm. İnnodb_file_per_table kullanıyorsanız, .frmsöz konusu tablo için hem bir dosyaya hem de .ibd dosyasına sahip olduğunuzdan emin olmak için veri dizinini kontrol edin . MYISAM ise, bir .frm, .MYIve bir .MYDdosya olmalıdır.

Sorun genellikle sahipsiz dosyayı manuel olarak silerek çözülebilir.

Burada çılgınca bir tahmine gidiyorum, ancak görünüşe göre innodb hala bir tablo alanındaki tablolarınız için bir girişe sahip, muhtemelen ibdata. Eğer varsa gerçekten gerek yok herhangi veri veya yedekleme varsa, aşağıdakileri deneyin:

1. Tüm şemaları sil (mysql hariç)
2. veritabanını kapat
3. Veri dizininizdeki tüm klasörlerin düzgün bir şekilde kaldırıldığından emin olun (yine mysql hariç)
4. ibdata ve günlük dosyalarını sil
5. veritabanını yeniden başlatın. Tablo alanını ve günlükleri sıfırdan yeniden oluşturmalıdır.

Düzeltmenin kolay olduğu ortaya çıktı; en azından çalıştığım şey benim için çalıştı. Başka bir MySQL örneğinde bir "zzz" tablosu oluşturun; burada zzz, sorun tablosu adıdır. (yani, tabloya schrodinger adı veriliyorsa, onu yazılan yerde zzz yerine koyun.) Tablonun tanımının ne olduğu önemli değildir. Geçici bir kukla; Zzz.frm dosyasını, dosya sahipliğinin ve dosya üzerindeki izinlerin hala doğru olduğundan emin olarak tablonun olması gereken sunucudaki veritabanı dizinine kopyalayın. MySQL'de artık "tabloları göster" yapabilirsiniz ve zzz tablosu orada olacaktır. mysql> tabloyu düşür zzz; ... şimdi çalışmalı. Gerekirse dizindeki tüm zzz.MYD veya ZZZ.MYI dosyalarını silin.

Bunun buradaki soru durumuna doğrudan bir cevap olduğundan şüpheliyim, ancak OS X Lion sistemimde bu tam olarak algılanan sorunu nasıl çözdüğümü burada bulabilirsiniz .

Planladığım bazı analiz işleri için sık sık tablolar oluşturuyor / bırakıyorum. Bir noktada, komut dosyamın ortasında tablo zaten var olan hataları almaya başladım. Sunucunun yeniden başlatılması genellikle sorunu çözdü, ancak bu bir çözüm olarak çok can sıkıcıydı.

Sonra yerel hata günlüğü dosyasında bu belirli satırı fark ettim:

[Warning] Setting lower_case_table_names=2 because file system for /usr/local/mysql/data/ is case insensitive

Bu bana, tablolarımda büyük harfler olsaydı, MySQL'in onları düşürdükten sonra bile hala orada olduklarını düşünerek aldatılacağı fikrini verdi. Durumun böyle olduğu ortaya çıktı ve tablo adları için yalnızca küçük harf kullanmaya geçmek sorunu ortadan kaldırdı.

Muhtemelen benim durumumdaki bazı yanlış yapılandırmaların sonucudur, ancak umarım bu hata durumu, birisinin bir çözüm bulmaya çalışırken daha az zaman harcamasına yardımcı olur.

Bu eski bir soru ama ben sadece aynı soruna çarptım ve en üstteki bağlantılı sorunlardan birinin cevabı tam da ihtiyacım olan şeydi ve dosyaları, tabloları silmekten, sunucuyu kapatmaktan vb. Çok daha az zorlayıcıydı.

mysqladmin -uxxxxxx -pyyyyy flush-tables

Benim durumumda sorun, mysql veri dizininin sahipliğini uygulamayı çalıştıran kullanıcıya değiştirerek çözüldü. (Benim durumumda, Jetty web sunucusunu çalıştıran bir Java uygulamasıydı.)

Mysql çalışıyor ve diğer uygulamalar onu düzgün bir şekilde kullanabilse de, bu uygulamanın bununla ilgili bir sorunu vardı. Veri dizini sahipliğini değiştirdikten ve kullanıcının şifresini sıfırladıktan sonra, her şey düzgün çalıştı.

Bu hata 1051 ile stok olacaksa ve yalnızca veritabanını silmek ve bunu tekrar içe aktarmak istiyorsanız, bu adımları uygulayın ve hepsi iyi olacak ...

Unix ortamında AS kökü :

• rm -rf / var / lib / mysql / YOUR_DATABASE;
• İSTEĞE BAĞLI -> mysql_upgrade --force
• mysqlcheck -uUSER -PASS YOUR_DATABASE
• mysqladmin -uUSER -PASS, YOUR_DATABASE bırak
• mysqladmin -uUSER -pASS YOUR_DATABASE oluştur
• mysql -uUSER -pASS YOUR_DATABASE <IMPORT_FILE

Saygılarımızla, Christus

Bu sorunu yaşadım ve IBD dosyasını silmenin yukarıda belirtildiği gibi yardımcı olacağını umdum, ancak hiçbir fark yaratmadı. MySQL yalnızca yeni bir IBD dosyasını yeniden oluşturdu. Benim durumumda, aynı MySQL örneğindeki diğer veritabanlarında aslında benzer tablolar var. FRM dosyası eksik olduğundan, FRM dosyasını başka bir veritabanındaki benzer tablodan kopyaladım, MySQL'i yeniden başlattım ve tablo düzgün çalıştı.

Bir tablo oluşturup sildikten sonra bu hatayla karşılaştım, sonra tekrar oluşturmak istedim. Benim durumumda, kendi kendine yeten bir döküm dosyam vardı, bu yüzden şemamı bıraktım, yeniden oluşturdum ve döküm dosyasını kullanarak tabloları ve verileri içe aktardım.

Sitemizde (ancak nadiren), çok sayıda yeniden oluşturma yapan belirli komut dosyalarını çalıştırırken bir "olay" meydana geldiğinde meydana gelir. Olaylar, ağ kesintilerini veya güç sorunlarını içerir.
Bunun için çok nadir durumlarda yaptığım şey - sert yaklaşımı kullanıyorum:

• Belirli bir masadan kurtulup yeniden inşa etmem gerekiyordu. Genelde masa inşa edildiğinden beri bunun sorun olmadığı bir konumdayım. (Verileri kurtarmanız gerekirse durumunuz farklı olabilir)
• Bir yönetici olarak, mysql kurulumuna gidin (Windows'ta "... program dosyaları / mysql / MySQL Sunucusu xx / data / <schemaname> olabilir
• <schemaname> klasöründe tablo adına sahip sorunlu dosyayı bulun - ve silin.
• Sahipsiz geçici dosyaları kontrol edin ve bunları da silin. # ... frm dosyaları varsa.
• MySQL, tabloyu yeniden OLUŞTURMANIZA izin verecek

Uzun zamandır (yıllar) birkaç farklı veritabanında bu sorunu yaşadım. Çelişkili mesajlar yüzünden bir felaketti. İlk kez diğer cevaplarda açıklandığı gibi veritabanını silme / yeniden oluşturma / yeniden adlandırma işleminin bir varyasyonunu yaptım ve işlerin ilerlemesini sağladım, ancak bu şekilde kesinlikle daha uzun sürüyor. Şanslıyım ki, genellikle sabahları yeniden oluşturulan - DROP'd ve CREATEd - referans tabloları olmuştur. Nadiren sorunla karşılaştı, ancak sorunu özel bir tuhaf vaka olarak kabul etti. (Tekrar belirteceğim: Verileri kurtarmanız gerekirse diğer çözümlere bakın.)

• başka bir kullanıcıya veya başka bir veritabanına ait bir tablo değil
• bu büyük / küçük harf sorunu değil, tüm küçük harfleri kullanıyorum, ama bu ilginç bir konuydu!
• "Kesinlikle <oradaydı / orada / orada değil / başka bir kullanıcı masası durumu> ve siz bunu doğru yapmıyorsunuz" gibi yanıtları görmek ekstra sinir bozucuydu :)
• tablo "tabloları göster" te gösterilmedi
• tablo bir INNODB tablosuydu (her zaman öyleydi / olmuştu).
• tabloyu DROP yapmaya çalışmak , tablonun bulunmadığına dair hata mesajı verdi.
• ancak tablo OLUŞTURULMAYA çalışmak , tablonun zaten mevcut olduğu hata mesajını verdi.
• mysql 5.0 veya 5.1 kullanarak
• ONARIM bu problem için etkisizdir

Bu sorunu belirli bir tabloyla yaşıyordum. Olası çözümleri okurken aşağıdaki gibi bazı adımlar attım:

• Yetim dosyaları ara: kimse yoktu;
• execute:: show full tables in database;sorunlu olanı görmedi;
• çalıştır:: describe table;döndürüldü table doesn't exist;
• çalıştır:: SELECT * FROM information_schema.TABLES WHERE TABLE_NAME='table';döndürüldü Empty set;
• PhpMyAdmin tarafından manuel olarak arayın, yukarıdaki sorgu: mevcut değildi;

Ve bu adımlardan sonra, tekrar kontrol show tables;ediyorum ve ... vualá! sorunlu masa gitmişti. Onu oluşturup aynı sorunlu adla sorunsuz bir şekilde bırakabilirim ve sunucuyu yeniden başlatmam bile gerekmedi! Tuhaf...