MySQL "Table is marked as crashed" Hatası ve phpMyAdmin İle Tablo Onarma

MySQL "Table is marked as crashed" hatası, çoğunlukla MyISAM depolama motoru kullanan bir tablonun bozulduğunu ve MySQL tarafından güvenli şekilde okunamadığını gösterir. En hızlı çözüm, veritabanı yedeği aldıktan sonra phpMyAdmin üzerinden ilgili tabloyu seçip Tabloyu onar işlemini çalıştırmaktır. Ancak bu hata her zaman yalnızca tek tıklamayla geçiştirilecek bir uyarı değildir; ani sunucu kapanması, disk doluluğu, hatalı sorgular, yoğun yazma trafiği veya eski MySQL yapılandırmaları nedeniyle tekrar edebilir. Bu rehberde hatanın nedenlerini, phpMyAdmin ile güvenli onarım adımlarını, işlem öncesi yedekleme kontrolünü ve kalıcı önleme yöntemlerini adım adım bulacaksınız.

Web siteniz WordPress, OpenCart, özel PHP yazılımı ya da forum sistemi kullanıyor olabilir; MySQL tablosu bozulduğunda ziyaretçileriniz beyaz ekran, 500 hatası, bağlantı zaman aşımı veya yönetim panelinde beklenmeyen veritabanı hataları görebilir. Özellikle e-ticaret sitelerinde sipariş, ürün, oturum veya sepet tabloları etkilenirse birkaç dakikalık kesinti bile gelir kaybına yol açabilir. Bu nedenle onarım işlemi yapılırken hem verinin korunması hem de hatanın kök nedeninin anlaşılması gerekir. Güvenilir bir barındırma altyapısı, düzenli yedekleme ve doğru veritabanı motoru seçimi bu tür riskleri ciddi ölçüde azaltır. Bu noktada yönetilebilir ve izlenebilir bir altyapı için Hostragons web hosting veya yüksek kaynak ihtiyacı olan projelerde Hostragons VPS sunucu seçenekleri değerlendirilebilir.

Table is marked as crashed hatası nedir?

Table is marked as crashed hatası, MySQL sunucusunun bir tabloyu bozuk olarak işaretlediğini ve ilgili tablo üzerinde okuma ya da yazma işlemlerinde sorun yaşadığını ifade eder. Hata mesajı genellikle şu biçimlerde görülür: Table './veritabani/tablo_adi' is marked as crashed and should be repaired veya Incorrect key file for table. Bu mesaj, tablo dosyasında, indekslerde veya tablo bütünlüğünde problem olduğunu gösterir.

Bu hata en sık MyISAM tablolarında görülür. MyISAM, eski ve hızlı okuma odaklı bir depolama motorudur; ancak çökme kurtarma kabiliyeti InnoDB kadar güçlü değildir. Sunucu aniden kapanırsa, disk yazma işlemi yarıda kalırsa veya MySQL servisi doğru kapanmadan sonlanırsa MyISAM tabloları kolayca bozulabilir. InnoDB ise transaction log ve crash recovery mekanizmaları sayesinde genellikle daha dayanıklıdır; fakat bu InnoDB tablolarında hiç sorun yaşanmayacağı anlamına gelmez. InnoDB tarafında benzer durumlar daha çok tablo alanı, disk, transaction log veya veri sözlüğü problemleri olarak görünür.

Hatanın en yaygın nedenleri

Bir tablo bozulduğunda yalnızca phpMyAdmin ile onarım yapmak çoğu zaman yeterli görünse de hatanın nedenini bulmazsanız aynı sorun günler veya saatler içinde tekrar edebilir. Aşağıdaki nedenler saha deneyiminde en sık karşılaşılan senaryolardır:

• Ani sunucu kapanması: Elektrik kesintisi, donanım reseti veya işletim sistemi çökmesi sırasında MySQL tabloya yazıyorsa tablo bozulabilir.
• Disk alanının dolması: MySQL geçici dosya, indeks veya tablo güncellemesi yazamazsa veri bütünlüğü zarar görebilir. Disk kullanımının yüzde 90 üzerine çıkması risklidir.
• MySQL servisinin zorla durdurulması: kill -9 gibi sert sonlandırmalar, özellikle yoğun yazma anında MyISAM tablolarında sorun oluşturur.
• Yoğun yazma trafiği: Log, sayaç, oturum veya arama tablosu gibi sürekli güncellenen tablolar MyISAM kullanıyorsa daha hassastır.
• Hatalı eklenti veya tema: WordPress gibi sistemlerde kötü yazılmış eklentiler aşırı sorgu üretebilir ve tablo kilitlenmelerine neden olabilir.
• Donanım veya dosya sistemi sorunları: Disk bad sector, I/O hataları veya bozuk dosya sistemi veritabanı dosyalarını etkileyebilir.
• Eski MySQL sürümü: Güncel olmayan sürümlerde performans, kilitlenme ve kurtarma davranışları daha zayıf olabilir.

Onarım öncesi kritik güvenlik adımları

Veritabanı onarma işlemi çoğu zaman güvenlidir; ancak bozuk tablo üzerinde yapılan her işlem veri kaybı riskini tamamen ortadan kaldırmaz. Özellikle üretim ortamında, yani canlı sitede işlem yapıyorsanız öncelik her zaman yedek olmalıdır.

1. Mevcut veritabanı yedeğini alın

phpMyAdmin ile onarıma başlamadan önce veritabanının anlık yedeğini dışa aktarın. Tablo bozuk olsa bile okunabilen verilerin yedeklenmesi önemlidir. phpMyAdmin içinde veritabanını seçin, Dışa aktar sekmesine tıklayın, hızlı yöntem yerine mümkünse özel yöntemi seçin ve SQL formatında yedek alın. Büyük veritabanlarında dışa aktarma zaman aşımına düşebilir; bu durumda hosting kontrol paneli yedekleme aracı veya SSH üzerinden mysqldump daha sağlıklı olabilir. Düzenli yedekleme politikası olmayan projelerde hosting yedekleme çözümleri gibi kaynakları incelemek faydalıdır.

2. Hangi tablonun bozulduğunu belirleyin

Hata mesajında genellikle tablo adı yer alır. Örneğin WordPress sitesinde wp_options, wp_posts, wp_comments veya wp_actionscheduler_actions tabloları karşınıza çıkabilir. Özel yazılımlarda tablo adı uygulama loglarında, PHP hata günlüklerinde veya MySQL error log içinde görülür. Hangi tablonun bozuk olduğunu belirlemek, tüm veritabanı üzerinde gereksiz işlem yapmanızı önler.

3. Siteyi kısa süre bakım moduna alın

Onarım yapılırken tabloya yeni yazma işlemi gelirse süreç başarısız olabilir veya veri tutarsızlığı yaşanabilir. Yoğun trafikli sitelerde 2-5 dakikalık bakım modu, işlemi daha güvenli hale getirir. WordPress kullanıyorsanız bakım eklentisiyle, özel yazılım kullanıyorsanız geçici bir bakım sayfası veya web sunucusu yönlendirmesiyle kullanıcı işlemlerini durdurabilirsiniz. Güvenli ziyaretçi deneyimi için bakım sayfasında SSL aktif olmalıdır; sertifika tarafında sorun yaşıyorsanız SSL sertifikası seçeneklerini inceleyebilirsiniz.

phpMyAdmin ile MySQL tablosu nasıl onarılır?

phpMyAdmin, teknik komut satırı bilgisi olmayan kullanıcılar için MySQL tablo onarımını kolaylaştırır. Aşağıdaki adımlar genel cPanel, Plesk ve benzeri hosting panellerinde benzerdir.

Adım 1: Hosting panelinden phpMyAdmin'e giriş yapın

Hosting kontrol panelinize giriş yaptıktan sonra veritabanları bölümünde phpMyAdmin bağlantısını açın. Birden fazla hosting hesabı veya alan adı kullanıyorsanız doğru hesapta işlem yaptığınızdan emin olun. Yanlış veritabanında işlem yapmak genellikle doğrudan zarar vermez; ancak zaman kaybettirir ve canlı site yerine test ortamını onarmanıza neden olabilir. Alan adı ve hosting eşleşmeleriniz karışıksa domain yönetimi konusunu da gözden geçirebilirsiniz.

Adım 2: Doğru veritabanını seçin

Sol menüden sitenizin kullandığı veritabanını seçin. WordPress için veritabanı adını wp-config.php dosyasındaki DB_NAME satırından öğrenebilirsiniz. Özel PHP projelerinde veritabanı adı genellikle config.php, .env veya database.php dosyalarında yer alır. Aynı sunucuda birden fazla site varsa bu kontrol çok önemlidir.

Adım 3: Bozuk tabloyu işaretleyin

Veritabanı açıldığında tablolar listelenir. Hata mesajında geçen tabloyu bulun ve solundaki kutucuğu işaretleyin. Birden fazla tablo için aynı hata alıyorsanız hepsini seçebilirsiniz; ancak önce en kritik tabloyla başlamak daha kontrollü bir yöntemdir. Tablonun MyISAM olup olmadığını görmek için satırdaki Tür veya Engine alanına bakın.

Adım 4: Tabloyu onar seçeneğini çalıştırın

Tabloyu seçtikten sonra sayfanın altındaki açılır menüden Tabloyu onar seçeneğini seçin. phpMyAdmin arka planda genellikle REPAIR TABLE tablo_adi komutunu çalıştırır. İşlem tamamlandığında başarılı, uyarılı veya başarısız sonucu görürsünüz. Başarılı sonuç çoğunlukla status OK şeklindedir. Büyük tablolarda işlem birkaç saniye yerine birkaç dakika sürebilir; bu sırada sayfayı yenilemeyin ve tarayıcıyı kapatmayın.

Adım 5: Tabloyu kontrol edin ve siteyi test edin

Onarım bittikten sonra aynı açılır menüden Tabloyu kontrol et işlemini çalıştırabilirsiniz. Ardından web sitenizin ana sayfasını, yönetim panelini, arama fonksiyonunu, ürün listelemelerini ve kullanıcı giriş alanını test edin. WordPress kullanıyorsanız yönetim panelinde kalıcı bağlantıları kaydetmek, önbelleği temizlemek ve hata günlüğünü kontrol etmek iyi bir pratiktir.

phpMyAdmin onarım seçenekleri ne anlama gelir?

phpMyAdmin içinde yalnızca onarım değil, tablo bakımına yönelik farklı seçenekler de bulunur. Her seçeneğin amacı farklıdır; yanlış beklentiyle kullanılmamalıdır.

Özetle, Table is marked as crashed hatası için doğrudan ilgili seçenek Tabloyu onar işlemidir. Optimize ve analiz işlemleri faydalı bakım araçlarıdır; fakat bozuk tabloyu tek başına düzeltmeyebilir.

InnoDB tablolarda durum neden farklıdır?

phpMyAdmin'de InnoDB tabloları için Tabloyu onar seçeneği her zaman beklenen şekilde çalışmaz. Bunun nedeni InnoDB'nin MyISAM gibi basit dosya tabanlı onarım mantığıyla çalışmamasıdır. InnoDB transaction log, redo log, undo log ve tablo alanı yapılarıyla veri bütünlüğünü korur. Bu yüzden InnoDB sorunlarında çözüm genellikle MySQL servis loglarını incelemek, disk durumunu kontrol etmek, yedekten geri dönmek veya ileri seviye kurtarma modlarını kullanmaktır.

Eğer hata mesajınız MyISAM tablosunu gösteriyorsa phpMyAdmin onarımı yüksek ihtimalle sonuç verir. Ancak InnoDB tarafında corrupt, tablespace, cannot open table gibi mesajlar alıyorsanız doğrudan onarım denemeleri yerine önce yedek alınmalı ve sunucu logları incelenmelidir. Bu durumda hosting sağlayıcınızdan destek istemek daha güvenlidir. Özellikle kritik e-ticaret verilerinde rastgele deneme yapmak yerine profesyonel müdahale tercih edilmelidir.

Onarım başarısız olursa ne yapılmalı?

phpMyAdmin ile tablo onarma işlemi her zaman başarılı olmayabilir. Büyük tablo boyutu, ciddi dosya bozulması, disk problemi veya yetki kısıtı nedeniyle işlem yarıda kalabilir. Böyle bir durumda aşağıdaki adımlar izlenebilir:

• Yedekten geri yükleme: En güvenilir yöntem, hatanın oluşmadığı en yakın tarihli yedeği geri yüklemektir. Geri yükleme öncesi mevcut bozuk veritabanını ayrı bir dosya olarak saklayın.
• SSH ile myisamchk kullanımı: MyISAM tabloları için sunucu erişimi varsa myisamchk aracı kullanılabilir. Bu işlem MySQL servisi durdurularak veya tabloya erişim kesilerek yapılmalıdır.
• REPAIR TABLE komutu: phpMyAdmin SQL sekmesinden REPAIR TABLE tablo_adi; komutu çalıştırılabilir. Geniş tablolar için QUICK veya EXTENDED seçenekleri değerlendirilebilir.
• Disk ve inode kontrolü: Disk alanı veya inode doluysa onarım başarısız olur. Önce gereksiz yedek, log ve geçici dosyalar temizlenmelidir.
• Sunucu hata günlüklerini inceleme: MySQL error log, web server log ve PHP error log kök nedeni belirlemede kritik veri sağlar.

Paylaşımlı hosting kullanıyorsanız SSH veya servis durdurma yetkiniz olmayabilir. Bu durumda destek ekibine hata mesajını, tablo adını, yaklaşık oluşma zamanını ve aldığınız son yedek tarihini iletmek çözümü hızlandırır.

Hatanın tekrar etmesini nasıl önlersiniz?

Tek seferlik onarım, sorunu geçici olarak ortadan kaldırır; kalıcı çözüm ise altyapı ve bakım disiplinidir. Aşağıdaki önlemler, MySQL tablo bozulması riskini belirgin şekilde azaltır.

MyISAM tablolarını InnoDB'ye dönüştürmeyi değerlendirin

Güncel web uygulamalarında InnoDB genellikle daha güvenli ve dayanıklı bir tercihtir. Satır seviyesinde kilitleme, transaction desteği ve çökme sonrası kurtarma özellikleri sayesinde yoğun yazma trafiğinde MyISAM'e göre avantaj sağlar. Dönüştürme işlemi basitçe ALTER TABLE tablo_adi ENGINE=InnoDB; komutuyla yapılabilir; ancak canlı sitede uygulamadan önce mutlaka test ortamında denenmeli ve tam yedek alınmalıdır. Bazı eski yazılımlar fulltext indeks veya özel MyISAM davranışlarına bağımlı olabilir.

Düzenli ve geri yüklenebilir yedekleme kullanın

Yedek yalnızca alınmış olmakla değil, geri yüklenebilir olmakla değerlidir. Günlük yedekler, haftalık tam yedekler ve önemli güncellemelerden önce manuel yedek almak iyi bir politikadır. En az 7 günlük yedek saklama, çoğu küçük ve orta ölçekli web sitesi için makul bir başlangıçtır. E-ticaret sitelerinde sipariş kaybını azaltmak için daha sık yedek veya binlog tabanlı kurtarma gerekebilir.

Disk kullanımını ve kaynakları izleyin

Disk alanı yüzde 85-90 seviyelerine ulaştığında alarm üretmek gerekir. MySQL geçici tablolar, log dosyaları ve indeks işlemleri için boş alana ihtiyaç duyar. Ayrıca CPU, RAM ve I/O bekleme süreleri düzenli izlenmelidir. Sürekli kaynak limitine takılan bir site, veritabanı hatalarına daha yatkındır. Trafiğiniz büyüdüyse paylaşımlı plandan daha güçlü bir pakete geçmek mantıklı olabilir; bu konuda kurumsal hosting veya yüksek performanslı hosting sayfaları değerlendirilebilir.

Eklenti, tema ve yazılım güncellemelerini kontrol edin

Eski yazılımlar yalnızca güvenlik açığı oluşturmaz; veritabanına verimsiz sorgular da gönderebilir. WordPress'te bakım yapılırken kullanılmayan eklentiler kaldırılmalı, veritabanı şişiren log tabloları temizlenmeli ve güvenilir olmayan eklentilerden kaçınılmalıdır. Yazılım güncellemeden önce staging ortamında test yapmak, canlı sitede beklenmeyen tablo veya indeks problemlerini önler.

Sunucuyu doğru kapatın ve bakım planı oluşturun

VPS veya dedicated sunucu yönetiyorsanız MySQL servisini zorla sonlandırmaktan kaçının. Bakım öncesinde servisleri kontrollü durdurmak, güncellemeleri düşük trafik saatlerinde yapmak ve reboot sonrası logları kontrol etmek önemlidir. Planlı bakım disiplini, özellikle yüksek trafikli veritabanlarında bozulma riskini azaltır.

WordPress sitelerde özel notlar

WordPress, MySQL hatalarını çoğu zaman genel veritabanı bağlantısı kurulurken hata oluştu mesajıyla gösterir. Ancak hata günlüğüne bakıldığında bozuk tablo ayrıntısı görülebilir. WordPress'te sık etkilenen tablolar arasında wp_options, wp_posts, wp_postmeta, wp_comments ve bazı eklentilerin oluşturduğu zamanlayıcı veya log tabloları bulunur. wp_options tablosu bozulursa site genel ayarları okunamayabilir; wp_posts bozulursa içerikler listelenmeyebilir; eklenti log tabloları bozulursa yönetim paneli yavaşlayabilir.

WordPress'in yerleşik veritabanı onarım özelliği de vardır. wp-config.php dosyasına geçici olarak define('WP_ALLOW_REPAIR', true); satırı eklenip /wp-admin/maint/repair.php adresinden onarım çalıştırılabilir. Ancak işlem tamamlandıktan sonra bu satır mutlaka kaldırılmalıdır; aksi halde onarım sayfası yetkisiz erişime açık kalabilir. phpMyAdmin yöntemi genellikle daha kontrollüdür çünkü doğrudan hangi tabloya işlem yaptığınızı görebilirsiniz. WordPress projeleri için optimize edilmiş altyapı arıyorsanız WordPress hosting kaynağına göz atabilirsiniz.

Ne zaman profesyonel destek almalısınız?

Her MySQL hatası kendi başınıza çözülecek kadar basit değildir. Aşağıdaki durumlardan biri varsa profesyonel destek almak daha güvenlidir:

• Bozuk tablo sipariş, ödeme, üyelik veya finans verisi içeriyorsa.
• Onarım denemesi sonrası hata devam ediyorsa veya tablo kaybolmuş görünüyorsa.
• Veritabanı boyutu birkaç GB üzerindeyse ve phpMyAdmin zaman aşımına düşüyorsa.
• InnoDB tablespace veya redo log hataları görülüyorsa.
• Disk hatası, I/O error veya dosya sistemi uyarısı varsa.
• Yakın tarihli temiz bir yedeğiniz yoksa.

Destek talebi oluştururken hata mesajının tam metnini, etkilenen veritabanı ve tablo adını, hatanın ne zaman başladığını, son yapılan güncelleme veya taşıma işlemini ve varsa yedek tarihini paylaşın. Bu bilgiler çözüm süresini ciddi şekilde kısaltır.

Kısa kontrol listesi

Acil durumda hızlı hareket etmek için şu sırayı izleyebilirsiniz:

• Hata mesajından bozuk tablo adını belirleyin.
• Mevcut veritabanının yedeğini alın.
• Siteyi kısa süre bakım moduna alın.
• phpMyAdmin'de doğru veritabanını seçin.
• İlgili tabloyu işaretleyip Tabloyu onar işlemini çalıştırın.
• Tabloyu kontrol edin ve site fonksiyonlarını test edin.
• Disk, kaynak, yedek ve tablo motoru kontrolleriyle tekrar riskini azaltın.

Sıkça Sorulan Sorular

MySQL Table is marked as crashed hatası veri kaybı anlamına gelir mi?

Her zaman veri kaybı anlamına gelmez. Çoğu MyISAM tablo, phpMyAdmin üzerinden Tabloyu onar işlemiyle kurtarılabilir. Ancak tablo ciddi şekilde bozulduysa bazı kayıtlar zarar görmüş olabilir. Bu yüzden onarım öncesinde mevcut durumun yedeğini almak önemlidir.

phpMyAdmin ile tablo onarma işlemi güvenli mi?

Genellikle güvenlidir; fakat canlı veritabanında yapılan her bakım işlemi risk taşır. İşlem öncesinde yedek almak, doğru tabloyu seçmek ve mümkünse siteyi bakım moduna almak güvenliği artırır. Büyük veya kritik tablolarda profesyonel destek tercih edilmelidir.

InnoDB tablolar için Tabloyu onar kullanmalı mıyım?

InnoDB tablolar MyISAM gibi klasik REPAIR TABLE mantığıyla onarılmaz. InnoDB sorunlarında MySQL loglarını incelemek, disk durumunu kontrol etmek ve gerekirse yedekten geri dönmek daha doğru yaklaşımdır. Rastgele onarım denemeleri veri kaybı riskini artırabilir.

Bu hata neden sürekli tekrarlıyor?

Hata tekrar ediyorsa altta yatan neden çözülmemiş olabilir. Disk alanı doluluğu, ani servis kapanmaları, yoğun yazma trafiği, bozuk eklentiler, eski MySQL sürümü veya MyISAM kullanımının devam etmesi en yaygın nedenlerdir. Kök nedeni bulmak kalıcı çözüm için şarttır.

Onarım yapmadan önce hosting firmama başvurmalı mıyım?

Basit MyISAM tablo hatalarında yedek alıp phpMyAdmin ile onarım yapabilirsiniz. Ancak tablo kritik veri içeriyorsa, yedeğiniz yoksa, veritabanı çok büyükse veya InnoDB hataları görüyorsanız hosting destek ekibine başvurmanız daha güvenlidir.

Sonuç

MySQL "Table is marked as crashed" hatası, özellikle MyISAM tablolarında görülen ve çoğu durumda phpMyAdmin ile giderilebilen bir veritabanı bozulma uyarısıdır. Doğru yaklaşım; önce yedek almak, bozuk tabloyu belirlemek, phpMyAdmin üzerinden onarım yapmak ve ardından hatanın nedenini ortadan kaldırmaktır. Düzenli yedekleme, yeterli sunucu kaynağı, InnoDB kullanımı ve güncel yazılım altyapısı bu sorunun tekrar etme ihtimalini azaltır. Eğer sitenizde benzer hatalar sık yaşanıyorsa altyapınızı gözden geçirmek ve ihtiyaçlarınıza uygun hosting çözümünü değerlendirmek için Hostragons kaynaklarını inceleyebilir veya destek ekibinden yönlendirme alabilirsiniz.