MySQL'de Kötü veya Bozuk Olarak İşaretlenmiş Tablolar Nasıl Onarılır

Bir yıldan fazla bir süredir WordPress için Counterizer eklentisini kullandık ve bu nedenle blog ve okuyucularının istatistiklerini tuttuk, bu eklentiyi birkaç gün önce devre dışı bıraktık çünkü (diğer şeylerin yanı sıra) veritabanında 600MB'den fazla veri kaydetti.

(Eklentiyi devre dışı bırakmadan ve DB'yi temizlemeden önce) veritabanının bir dökümünü yapmaya, yani .SQL'e aktarmaya ve böylece indirmeye çalıştım ve barındırma terminalinde aşağıdaki hata belirdi:

mysqldump: Hata var: 144: Tablo './dl_database/Counterize_Referers' kilitlendi olarak işaretlendi ve KİLİT TABLOLARI kullanılırken son (otomatik?) onarım başarısız oldu

Bu nedenle, çöplük gerçekleştirilmedi ve iyi bir şekilde yapılmadı ... sadece DB'nin olduğunu düşünme fikri DesdeLinux Bir sorun yaşadım, tüylerim diken diken oldu :)

Web üzerinde küçük bir araştırma yaparak bu problemi nasıl çözeceğimi öğrenebildim, görünüşe göre veritabanında tam olarak problem var DEĞİLDİR, basitçe bir tablo 'problemli' olarak işaretlenmiş, neyse ki bunu düzeltmek çok basit.

İlk önce MySQL sunucusuna erişelim:

mysql -u root -p

[Enter] tuşuna basıyoruz ve bizden MySQL kök şifresini soracak, onu girip tekrar [Enter] tuşuna basacağız.

Bu komut, MySQL sunucusunun aynı bilgisayara yüklenmesi durumunda geçerlidir, başka bir MySQL sunucusuna uzaktan bağlanmak istiyorsanız, satıra aşağıdakileri eklemeniz gerekir: -h SUNUCU'nun IP'si

MySQL'e girdikten sonra size hangi veritabanının kullanılacağını söyleyeceğiz, örneğin yukarıdaki hataya göre problem tablodadır. Counterize_Referers veritabanından  dl_veritabanı, Böylece:

use database dl_database;

Ve şimdi masa tabanını onarmak için:

repair table Counterize_Referers;

Bu satırların sonunda noktalı virgül olduğuna dikkat edin —– »  ;

Önceki komut yürütüldüğünde, her şey normale dönmüş olmalı, en azından benim durumumda birden fazla durumda böyle olmuştur 😉

Daha sonra sadece veritabanını ve işi dökmek için talimatı tekrar yürütmek kalır, daha fazlası değil.

Her neyse, bunu benim için bir not olarak her şeyden çok yapıyorum çünkü aynı şey bana iki kez oldu ve günü kurtarmak için talimatları unutmak istemiyorum 😀

Selamlar ve umarım başka birine yardımcı olur.


Yorumunuzu bırakın

E-posta hesabınız yayınlanmayacak. Gerekli alanlar ile işaretlenmiştir *

*

*

  1. Verilerden sorumlu: Miguel Ángel Gatón
  2. Verilerin amacı: Kontrol SPAM, yorum yönetimi.
  3. Meşruiyet: Onayınız
  4. Verilerin iletilmesi: Veriler, yasal zorunluluk dışında üçüncü kişilere iletilmeyecektir.
  5. Veri depolama: Occentus Networks (AB) tarafından barındırılan veritabanı
  6. Haklar: Bilgilerinizi istediğiniz zaman sınırlayabilir, kurtarabilir ve silebilirsiniz.

  1.   Aslan burcu dijo

    Çok iyi, her ne sebeple olursa olsun bu tür bir eşyayı elinizde bulundurmanız gerekiyor.

    1.    KZKG ^ Gaara dijo

      teşekkürler
      Evet… sorunun ortaya çıktığı anda çözümü elinizin altında bulundurmak veya en azından gecikmeden nerede bulacağını bilmek iyidir.

  2.   eliotime3000 dijo

    İyi KZKGGaara. Konsolun yapabildiği, PHPMyAdmin'in yapamadığı şeyler vardır.

    1.    KZKG ^ Gaara dijo

      teşekkürler

  3.   Santiago dijo

    Mükemmel, beni birden fazla kurtardı.

    Ama merak ediyorum, root -u root -p yerine mysql -u root -p olmaz mıydı? Kırmak istemem.

    Teşekkürler!

  4.   Santiago dijo

    Mükemmel, beni birden fazla kurtardı.
    Ama merak ediyorum, root -u root -p yerine mysql -u root -p olmaz mıydı? Kızma niyeti olmadan soruyorum.
    teşekkürler

    1.    KZKG ^ Gaara dijo

      LOL !!!! Tamamen doğru, benim hatam LOL!
      Oradan mysql yerine root yazmak için bir adım önde yazıyor ve düşünüyordum ... Uyarı için teşekkürler 🙂

      1.    Santiago dijo

        Rica ederim! Çift gönderi için özür dilerim; Birkaç kez göndermeye çalıştım ve bana zaten var olduğunu söyledi (Sayfayı yeniden yükledim ve hiçbir şey görmedim).
        Selamlar.

  5.   Leper_Ivan dijo

    Artık DB konusuna girdiğim için bu saçımdan çıkıyor.

  6.   alejandro dijo

    Merhaba iyi

    Bir soru, ne sıklıkla DB'den vazgeçersiniz? 600 MB'a kadar veriyi almanın ne kadar sürdüğünü bilmektir

    Saygılarımızla,

    1.    KZKG ^ Gaara dijo

      Ehm… Seni şimdi çok iyi anlamadım 🙂
      Veritabanında bir temizlik yapmadan önce DesdeLinux Bunun (yani DB'nin .sql'inin) ağırlığı 700 MB'tan fazlaydı çünkü tüm istatistikleri DB'de tutuyorduk. Yani neredeyse blogun başlangıcından beri.

      Şimdi Google A'yı kullanıyoruz, bu yüzden istatistik tablolarını DB'den siliyoruz ve şimdi .sql 80MB'ye ulaşmıyor

      Bu sorunuzu yanıtlıyor mu?

  7.   alejandro dijo

    Merhaba iyi

    Trol olmadan, ne sıklıkla DB'yi atarsınız?

    1.    KZKG ^ Gaara dijo

      Ayda birkaç kez 🙂
      Her zaman en son sürüme sahip olmaya çalışırım DesdeLinux

  8.   satın almayı seviyorsun !! dijo

    Bana iyi geliyor, bozuk tabloların genel bir revizyonunu yapmak artık mümkün değil mi?

  9.   Victoria dijo

    Çok teşekkür ederim arkadaşım, katkınız bana çok yardımcı oldu.
    selamlar

  10.   Juan Mollega dijo

    Çok teşekkür ederim canım, ipuçları için teşekkürler, bana yardımcı oldular !!
    Trujillo-Venezuela'dan selamlar.

  11.   Hernan Barra dijo

    tahmini
    İşlemin çalışıp çalışmadığını bildiğim gibi, onarım tablosunu içe aktarma komutunu yazdım; ve oradayım

  12.   André Cruz dijo

    Çok teşekkür ederim tenimi kurtardın 😀

  13.   Marco dijo

    Merhaba arkadaşım, bana yardım edip edemeyeceğinizi bilmiyorum, web sitemde benzer bir şey oldu, bu hatayı işaretleyin:
    Wp_posts tablosu doğru değil. Aşağıdaki hatayı bildirin: Tablo çöktü olarak işaretlendi ve son onarım başarısız oldu. WordPress bu tabloyu onarmaya çalışacak ...
    Wp_posts tablosu onarılamadı. Hata: Tablo çöktü olarak işaretlendi ve son onarım başarısız oldu

    Bunu düzeltmeme yardım edip edemeyeceğinizi bilmiyorum, gelişmiş WordPress'te yeniyim. Wp-post tablosunu onarmaya çalışırken, onarılamayacak bir hata gösteriyor. Teşekkür ederim. Web sitem: https://diarionoticiasweb.com