phpMyAdmin ile Bozuk MySQL Tablosunu Onarma

Bir gün sitenizi açtığınızda karşınıza "Error establishing a database connection" ya da tarayıcıda "Table 'wp_options' is marked as crashed and should be repaired" gibi bir uyarı çıkabilir. WordPress, WooCommerce ya da özel bir PHP uygulaması çalıştırın fark etmez; bu satırlar veritabanınızdaki bir tablonun bozulduğu anlamına gelir. İyi haber şu ki, çoğu durumda bu bozulma verinizin kaybolduğu değil, tablo dosyasının tutarsız bir duruma düştüğü anlamına gelir ve büyük olasılıkla birkaç dakikalık bir onarım işlemiyle sitenizi eski hâline döndürebilirsiniz.

Bu rehberde tablo bozulmasının neden yaşandığını, "marked as crashed" hatasını nasıl tanıyacağınızı ve en yaygın araç olan phpMyAdmin üzerinden bir tabloyu adım adım nasıl onaracağınızı (Repair) ve toparlayacağınızı (Optimize) göstereceğiz. Ayrıca MyISAM ile InnoDB motoru arasındaki kritik farkı, onarım işe yaramadığında yedekten nasıl döneceğinizi ve bir daha aynı sorunu yaşamamak için hangi önlemleri alacağınızı anlatacağız. Veritabanı yönetiminin temellerine yeniyseniz önce MySQL veritabanı ve kullanıcı yönetimi rehberine göz atmanız, buradaki adımları daha rahat izlemenizi sağlar.

Tablo Neden Bozulur?#

MySQL tabloları, diskte gerçek dosyalar olarak durur. Bir tablonun "bozulması" genellikle bu dosyaların, veri ile içindeki indeks yapısının birbiriyle tutarsız hâle gelmesi demektir. Motor bir kaydı okumaya çalıştığında beklediği yapıyı bulamaz ve tabloyu "crashed" (çökmüş) olarak işaretleyerek daha fazla zarar vermemek için erişimi durdurur. Bu koruma mekanizması aslında iyi bir şeydir; size "burada bir sorun var, dokunma" der.

En sık karşılaşılan bozulma nedenleri şunlardır:

• Ani kapanma ve güç kesintisi: Sunucu, tabloya yazma işleminin tam ortasında beklenmedik şekilde kapanırsa dosya yarım kalır. VPS/VDS'in sert yeniden başlatılması, ana makinede yaşanan bir donanım sorunu ya da elektrik kesintisi bunun tipik sebepleridir.
• Disk dolması: Diskte boş alan kalmadığında MySQL yazma işlemini tamamlayamaz ve tablo yarım yazılmış hâlde kalır. Bu, paylaşımlı hosting ortamlarında en sık görülen sebeplerden biridir; disk kotanız dolduğunda tablolar aniden bozulmaya başlar.
• MySQL sürecinin öldürülmesi: kill -9 ile zorla sonlandırılan bir mysqld süreci, açık dosyaları düzgün kapatamadan ölür.
• Donanım ve dosya sistemi hataları: Bozuk bir disk sektörü, RAID sorunu ya da dosya sistemi hatası, tablo dosyasını fiziksel olarak zedeler.
• Aynı anda çok yoğun yazma: Özellikle eski MyISAM tabloları, yüksek eşzamanlı yazma yükü altında kilitlenme ve tutarsızlığa daha yatkındır.

Bu nedenlerin çoğu tek bir başlık altında toplanabilir: MySQL'in bir yazma işlemini güvenli biçimde tamamlayamadan kesintiye uğraması. Bu yüzden onarımdan önce, altta yatan sebebi (özellikle dolu disk) çözmezseniz sorun tekrar edecektir.

"Table Marked as Crashed" Hatasını Tanımak#

Bozulma birçok farklı yüzeyde kendini gösterebilir. En doğrudan işaret, uygulamanızın ya da phpMyAdmin'in verdiği açık hata mesajıdır. WordPress çalıştıranlar genellikle beyaz ekran ya da veritabanı bağlantı hatasıyla karşılaşır; ham hatayı görmek için sunucunun MySQL hata günlüğüne veya uygulamanın hata kayıtlarına bakmanız gerekir.

Tipik hata mesajları şöyle görünür:

Table './veritabani/wp_options' is marked as crashed and should be repaired
Table './veritabani/wp_posts' is marked as crashed and last (automatic?) repair failed
Incorrect key file for table 'wp_postmeta'; try to repair it

Bir sunucuya SSH erişiminiz varsa, bozulmayı komut satırından da hızlıca teşhis edebilirsiniz. mysqlcheck aracı, bir veritabanındaki tüm tabloları tarayıp durumlarını raporlar:

# Tek bir veritabanındaki tüm tabloları kontrol et
mysqlcheck -u root -p --check veritabani_adi

Çıktıda sağlıklı tablolar OK, bozuk olanlar ise Table is marked as crashed gibi bir not ile listelenir:

veritabani_adi.wp_comments        OK
veritabani_adi.wp_options         Table is marked as crashed and should be repaired
veritabani_adi.wp_posts           OK

Kök erişiminiz yoksa ve paylaşımlı bir web hosting paketi kullanıyorsanız endişelenmeyin; aynı teşhisi ve onarımı, birazdan anlatacağımız gibi tamamen görsel olarak phpMyAdmin üzerinden yapabilirsiniz. Hosting panelinizde (cPanel, DirectAdmin vb.) MySQL Databases bölümünde çoğu zaman "Repair Database" düğmesi de bulunur.

phpMyAdmin ile Tabloyu Onarma (Repair)#

phpMyAdmin, MySQL için en yaygın kullanılan görsel yönetim aracıdır ve neredeyse her hosting panelinde hazır gelir. Bozuk bir tabloyu onarmak, tek satır SQL bile yazmadan birkaç tıklamayla yapılabilir. Adımlar şöyledir:

1. Hosting kontrol panelinizden (cPanel > phpMyAdmin, DirectAdmin > phpMyAdmin) phpMyAdmin'i açın.
2. Sol taraftaki veritabanı listesinden ilgili veritabanının adına tıklayın. Ortada o veritabanındaki tüm tablolar listelenecektir.
3. Bozuk tablonun (veya emin değilseniz tüm tabloların) solundaki onay kutusunu işaretleyin. Hepsini seçmek için listenin altındaki Tümünü işaretle (Check all) bağlantısını kullanabilirsiniz.
4. Tablo listesinin hemen altındaki Seçili olanlar için (With selected) açılır menüsünü açın.
5. Menüden Tabloyu onar (Repair table) seçeneğini tıklayın.

phpMyAdmin, seçtiğiniz her tablo için arka planda REPAIR TABLE komutunu çalıştırır ve sonucu bir tablo hâlinde gösterir. Her satırın karşısında OK ifadesini görüyorsanız onarım başarılıdır; genellikle bu kadarı sitenizi tekrar açmaya yeter.

Aynı işlemi phpMyAdmin'in SQL sekmesinden komutla da yapabilirsiniz; hangi tablonun bozuk olduğunu biliyorsanız bu daha hızlıdır:

-- Tek bir tabloyu onar
REPAIR TABLE wp_options;

-- Birden fazla tabloyu tek komutta onar
REPAIR TABLE wp_options, wp_postmeta, wp_comments;

SSH erişiminiz varsa aynı işi tüm veritabanı için mysqlcheck ile toplu hâlde yaptırabilirsiniz; bu, tabloları tek tek seçmekten çok daha pratiktir:

# Bir veritabanındaki tüm bozuk tabloları onar
mysqlcheck -u root -p --repair veritabani_adi

# Sunucudaki tüm veritabanlarını onar
mysqlcheck -u root -p --repair --all-databases

Onarım sırasında phpMyAdmin ya da mysqlcheck "The storage engine for the table doesn't support repair" gibi bir uyarı verirse şaşırmayın; bu, tablonuzun MyISAM değil InnoDB motorunu kullandığı ve REPAIR TABLE komutunun bu motorda çalışmadığı anlamına gelir. InnoDB tablolarının onarımını birazdan ayrı bir başlıkta ele alacağız.

Optimize Table ile Tabloyu Toparlama#

Onarım, bozulmuş bir tabloyu tekrar okunabilir hâle getirir; Optimize ise farklı bir işi yapar. Zaman içinde çok sayıda DELETE ve UPDATE işlemi gören tablolarda diskte "boşluklar" (fragmentasyon) oluşur. Silinen kayıtların yeri hemen geri kazanılmaz, indeksler dağınıklaşır ve tablo hem gereksiz yer kaplar hem de yavaşlar. OPTIMIZE TABLE bu boşlukları toplar, tabloyu fiziksel olarak yeniden düzenler ve indeksleri tazeler.

Onarımın hemen ardından ilgili tabloları optimize etmek iyi bir alışkanlıktır. phpMyAdmin'de yöntem, onarımla birebir aynıdır:

1. Veritabanına tıklayıp tabloları listeleyin.
2. Optimize etmek istediğiniz tabloları işaretleyin.
3. Seçili olanlar için menüsünden Tabloyu iyileştir (Optimize table) seçeneğini tıklayın.

Aynısını SQL sekmesinden de yapabilirsiniz:

OPTIMIZE TABLE wp_options, wp_postmeta;

InnoDB tablolarında OPTIMIZE TABLE, arka planda aslında tabloyu yeniden oluşturur (ALTER TABLE ... FORCE) ve size bunu bir bilgi mesajıyla haber verir; bu tamamen normaldir ve tablonuz yine de düzgün biçimde toparlanır. Onarım ve optimizasyonun bir CMS bağlamında nasıl yapıldığını daha ayrıntılı görmek isterseniz WordPress veritabanı optimizasyonu rehberimiz, gereksiz kayıtları temizlemekten tablo bakımına kadar tüm süreci ele alıyor.

İpucu: Optimize işlemi tabloyu kısa süreliğine kilitleyebilir. Yoğun trafikli bir sitede bu işlemi mümkünse ziyaretçi sayısının düşük olduğu saatlerde yapın ve büyük tablolarda işlemin bitmesini sabırla bekleyin.

MyISAM ve InnoDB Farkı#

Bir tabloyu doğru şekilde onarmak için hangi depolama motorunu (storage engine) kullandığını bilmeniz gerekir, çünkü onarım yöntemi motora göre değişir. Bir tablonun motorunu şu komutla öğrenebilirsiniz:

SELECT table_name, engine
FROM information_schema.tables
WHERE table_schema = 'veritabani_adi';

İki motor arasındaki temel farklar, neden birinde REPAIR TABLE'ın çalışıp diğerinde çalışmadığını da açıklar:

MyISAM, MySQL'in eski varsayılan motorudur ve ani kapanmalarda kolayca bozulur. Neyse ki REPAIR TABLE ve mysqlcheck --repair tam olarak bu motor için tasarlanmıştır; yukarıda anlattığımız phpMyAdmin adımları MyISAM tablolarında birebir işe yarar.

InnoDB ise modern MySQL/MariaDB'nin varsayılan motorudur ve işlem günlüğü (redo log) sayesinde çökmelerden çoğu zaman kendi kendine, otomatik olarak toparlanır; MySQL yeniden başladığında yarım kalan işlemleri geri alır. Bu yüzden InnoDB tabloları REPAIR TABLE'ı desteklemez ve bu komutu çalıştırdığınızda "doesn't support repair" uyarısı alırsınız. Bir InnoDB tablosu gerçekten bozulduğunda genellikle şu yol izlenir:

• Önce OPTIMIZE TABLE (yani tabloyu yeniden oluşturma) denenir; hafif tutarsızlıkları çoğu zaman düzeltir.
• MySQL hiç başlamıyorsa, yapılandırmaya geçici olarak innodb_force_recovery değeri eklenir, sunucu bu modda başlatılır, bozuk tablonun verisi mysqldump ile dışa aktarılır, ardından mod kapatılıp veri temiz bir tabloya geri yüklenir.

# /etc/mysql/my.cnf — yalnızca acil kurtarma için, geçici olarak
[mysqld]
innodb_force_recovery = 1

innodb_force_recovery değerini 1'den başlatıp yalnızca gerektiğinde kademeli olarak artırın; 4 ve üzeri değerler kalıcı veri kaybına yol açabilir, bu yüzden bu düzeyde işlem yapmadan önce mutlaka disk düzeyinde bir kopya alın. Sunucu tarafındaki bu tür ileri kurtarma işlemlerinde kendinizi rahat hissetmiyorsanız, kök erişimli bir VDS sunucu yönetiminde profesyonel destek için sunucu yönetimi hizmetimiz devreye girebilir.

Onarım İşe Yaramazsa: Yedekten Geri Dönme#

Bazen tablo o kadar ağır zarar görmüştür ki REPAIR TABLE bile "repair failed" der ya da onarım sonrası bir kısım kayıt kaybolur. İşte tam bu noktada, sağlam bir yedeğin neden pazarlık konusu olmadığı ortaya çıkar. Onarım her zaman verinizi eksiksiz kurtarmayı garanti etmez; en güvenli geri dönüş, sorun çıkmadan önce alınmış bir yedektir.

Elinizde mysqldump ile alınmış bir .sql yedeği varsa, önce yeni ve boş bir veritabanı hazırlayıp yedeği oraya geri yükleyerek verinizi doğrulamak en güvenlisidir. Doğrudan üstüne yazmadan önce içeriği kontrol etmiş olursunuz:

# Boş bir kurtarma veritabanı oluştur ve yedeği ona yükle
mysql -u root -p -e "CREATE DATABASE kurtarma_db CHARACTER SET utf8mb4;"
mysql -u root -p kurtarma_db < site_yedek.sql

Yedekteki verinin sağlam olduğundan emin olduktan sonra, yalnızca bozuk olan tabloyu canlı veritabanına aktarabilirsiniz. Örneğin sadece wp_options tablosunu yedekten alıp geri yüklemek için:

# Yedekten yalnızca tek bir tabloyu dışa aktar
mysqldump -u root -p kurtarma_db wp_options > wp_options.sql

# Bozuk tabloyu canlı veritabanına geri yükle
mysql -u root -p canli_db < wp_options.sql

phpMyAdmin kullanıyorsanız aynı işlemi görsel olarak yapabilirsiniz: İçe Aktar (Import) sekmesinden yedek .sql dosyanızı seçip yüklemeniz yeterlidir. Yedekten geri yükleme konusunda daha derine inmek isterseniz MySQL veritabanı yönetimi rehberimizdeki mysqldump bölümü tüm senaryoları kapsıyor. Elinizde hiç yedek yoksa ve site kritikse, işleri daha da kötüleştirmeden önce durup yedekleme altyapısı kurmanızı ya da profesyonel bir kurtarma değerlendirmesi için destek almanızı öneririz.

Önlem: Düzenli Yedekleme ve Sağlıklı Sunucu#

Tablo bozulmasıyla başa çıkmanın en iyi yolu, onu baştan yaşamamaktır. Aşağıdaki alışkanlıklar, hem bozulma riskini azaltır hem de bozulma yaşandığında sizi tam donanımlı yakalar:

• Otomatik, sunucu dışı yedekler alın. Günlük ya da haftalık mysqldump yedeklerini bir cron göreviyle otomatikleştirin ve bu yedekleri sunucudan farklı bir konumda saklayın. Aynı diskte duran yedek, disk arızasında işe yaramaz.
• Diskin dolmasına izin vermeyin. Disk kullanımını düzenli izleyin; boş alan yüzde 10'un altına indiğinde uyarı alacak şekilde ayarlayın. Dolu disk, tablo bozulmasının bir numaralı sebebidir.
• Mümkünse InnoDB kullanın. Tablolarınız hâlâ MyISAM ise ve işlem/foreign key ihtiyacınız varsa, ALTER TABLE tablo_adi ENGINE=InnoDB; ile InnoDB'ye geçmek, ani kapanmalara karşı çok daha dayanıklı bir yapı sağlar.
• Güncel ve sağlıklı bir MySQL sürümü çalıştırın. Güncel sürümler hem daha kararlıdır hem de kurtarma mekanizmaları daha olgundur.
• Sunucuyu düzgün kapatın. VPS/VDS'inizi yeniden başlatırken mümkün olduğunca "sert reset" yerine düzgün kapatma (graceful shutdown) yöntemini tercih edin.

Basit bir günlük yedek cron görevi şöyle görünür:

# Her gece 03:00'te veritabanını yedekle (crontab -e ile ekleyin)
0 3 * * * mysqldump -u yedek_kullanici -pPAROLA canli_db | gzip > /yedek/canli_db_$(date +\%F).sql.gz

WordPress gibi kritik bir uygulama çalıştırıyor ve yedek/güncelleme yükünü kendiniz taşımak istemiyorsanız WordPress bakım hizmetimiz düzenli veritabanı bakımını, yedeğini ve güncellemesini üstlenir. Sunucu göçü sırasında verinizi bütün ve bozulmadan taşımak için ise site taşıma hizmetimizden yararlanabilirsiniz.

Sıkça Sorulan Sorular#

"Table is marked as crashed" tam olarak ne demek?#

Bu mesaj, MySQL'in bir tabloyu okurken dosya yapısında tutarsızlık tespit ettiği ve daha fazla zarar oluşmasın diye o tabloya erişimi güvenlik amacıyla durdurduğu anlamına gelir. Genellikle veriniz hâlâ oradadır; tablonun sadece onarılması, yani indeks ve veri yapısının yeniden tutarlı hâle getirilmesi gerekir. Çoğu durumda phpMyAdmin'de "Repair table" işlemi sorunu birkaç saniyede çözer.

Repair table işlemi verilerimi siler mi?#

Onarım işleminin amacı veriyi silmek değil, kurtarmaktır ve çoğu senaryoda hiçbir kayıp yaşanmaz. Ancak tablo çok ağır zarar gördüyse, onarım bozuk kalan bazı satırları geri getiremeyebilir ve bu kayıtlar kaybolabilir. Bu nedenle mümkünse onarımdan önce mevcut durumun bir kopyasını almanız ve elinizde daha eski, sağlam bir yedek bulundurmanız önerilir.

InnoDB tablomu neden Repair table ile onaramıyorum?#

InnoDB motoru, REPAIR TABLE komutunu desteklemez çünkü çökmelerden kendi işlem günlüğü sayesinde otomatik olarak toparlanacak şekilde tasarlanmıştır. Bu yüzden komutu çalıştırdığınızda "storage engine doesn't support repair" uyarısı alırsınız. InnoDB'de hafif sorunlar için OPTIMIZE TABLE deneyebilir, ciddi bozulmalarda ise innodb_force_recovery moduyla veriyi dışa aktarıp temiz bir tabloya geri yükleme yöntemine başvurabilirsiniz.

Paylaşımlı hostingte SSH erişimim yok, tabloyu nasıl onarırım?#

Kök ya da SSH erişimine ihtiyacınız yoktur; tüm onarım işlemini kontrol panelinizdeki phpMyAdmin üzerinden görsel olarak yapabilirsiniz. Veritabanını açıp bozuk tabloyu işaretleyin ve "Seçili olanlar için" menüsünden "Tabloyu onar" seçeneğini tıklamanız yeterlidir. Ayrıca cPanel ve DirectAdmin gibi panellerin MySQL Databases bölümünde çoğu zaman tek tıkla çalışan bir "Repair Database" düğmesi de bulunur.

Onarımdan sonra sorun tekrar ediyor, ne yapmalıyım?#

Tablo onardıktan kısa süre sonra tekrar bozuluyorsa, altta yatan asıl sebep hâlâ çözülmemiş demektir; en sık suçlu dolu disk ya da donanım/dosya sistemi hatasıdır. Önce diskte yeterli boş alan olduğundan emin olun ve sunucunun hata günlüklerini disk veya bellek sorunları için inceleyin. Tablonuz MyISAM ise, tekrarlayan bozulmaları önlemek için InnoDB motoruna geçmeyi ciddi biçimde değerlendirin.

Yedeğim yoksa bozuk bir tablodan veriyi kurtarabilir miyim?#

Yedeğiniz yoksa şansınız tamamen bozulmanın ağırlığına bağlıdır ve garanti veremeyiz; yine de denenecek adımlar vardır. Öncelikle tabloya hiç dokunmadan tüm veritabanı dizininin diskteki bir kopyasını alın, ardından REPAIR TABLE ... USE_FRM (MyISAM için) veya innodb_force_recovery (InnoDB için) gibi kurtarma yöntemlerini kademeli olarak deneyin. Bu tür işlemler risklidir ve bir yanlış hamle veriyi kalıcı olarak kaybettirebileceği için, kritik veriler söz konusuysa deneme yapmadan önce mutlaka bir kopya alın ve gerekirse profesyonel destek isteyin.

Kapanış#

Bozuk bir MySQL tablosu ilk anda paniğe yol açsa da, gördüğünüz gibi çoğu durumda phpMyAdmin'de birkaç tıklamayla ya da tek bir REPAIR TABLE komutuyla çözülebilen bir sorundur. Anahtar noktalar şunlardır: hangi motoru (MyISAM mı, InnoDB mi) kullandığınızı bilmek, onarım ve optimizasyonu doğru sırayla uygulamak, altta yatan sebebi (özellikle dolu disk) mutlaka çözmek ve her zaman elinizde güncel bir yedek bulundurmak. Bu dört alışkanlık, veritabanı kaynaklı kesintilerin çok büyük bölümünü daha yaşanmadan bertaraf eder.

Verilerinizin güvenliği, üzerinde çalıştığı altyapının kalitesiyle doğrudan bağlantılıdır. Disk sağlığı, düzenli yedek ve kararlı bir MySQL kurulumu isteyen siteler için altyapısı hazır gelen web hosting paketlerimizi ya da WordPress'e özel optimize edilmiş WordPress hosting çözümümüzü inceleyebilir; tam kontrol isteyenler ise kök erişimli VDS sunucu seçeneğine göz atabilir. Yedekleme ve göç süreçlerinde yalnız kalmamak için yedekleme ve site taşıma hizmetlerimiz her zaman yanınızda. Clou.TR ekibi olarak amacımız, siz içeriğinize odaklanırken veritabanınızın arka planda sorunsuz ve güvende çalışmasını sağlamaktır.