WordPress Veritabani Onarimi ve Bozuk Tablo Cozumu

WordPress sitenizi bir sabah kontrol ettiginizde ekranda tek satirlik "Veritabani baglanti hatasi kuruluyor" yazisi gordunuzse, panige kapilmadan once sunu bilin: bu hatalarin buyuk cogunlugu geri donusu olmayan bir kayip degildir. Veritabani, WordPress'in kalbidir; her yaziniz, her yorumunuz, her ayariniz MySQL ya da MariaDB tablolarinin icinde durur. Bu tablolardan biri bozulduginda ya da baglanti kopdugunda site aninda erisilemez hale gelir, ama tablonun kendisi cogu zaman hala oradadir ve onarilabilir.

Bu rehberde, kidemli bir sistem yoneticisinin bir musteriye omuz basinda anlatacagi netlikte ilerleyecegiz. Once belirtileri dogru okumayi, sonra sorunun gercekten veritabaninda mi yoksa yapilandirmada mi oldugunu ayirt etmeyi ogreneceksiniz. Ardindan WordPress'in kendi dahili onarim aracindan phpMyAdmin ve WP-CLI komutlarina, en sonda da yedekten geri yuklemeye kadar dort ayri cozum yolunu adim adim uygulayacagiz. Amac sadece siteyi ayaga kaldirmak degil; ayni hatanin tekrar etmesini onlemek ve onarim sonrasi guvenlik acigina yol acacak ayrintilari (ozellikle o meshur onarim satirini kaldirmayi) atlamamak.

Bozuk Veritabaninin Belirtilerini Tanimak#

WordPress'in veritabani sorunlari genellikle iki farkli yuzle karsiniza cikar ve bu ikisini karistirmak, saatlerinizi yanlis yerde harcamaniza neden olur.

Birinci yuz, klasik "Error establishing a database connection" yani "Veritabani baglantisi kurulurken hata" mesajidir. Bu mesaj tek basina bir tablonun bozuk oldugunu soylemez; cogunlukla WordPress'in veritabani sunucusuna hic ulasamadigini anlatir. Sebep, yanlis kullanici adi/parola, calismayi durdurmus MySQL servisi, dolmus disk alani ya da asiri trafik altinda tukenmis baglanti limiti olabilir.

Ikinci yuz daha sinsidir: site kismen calisir ama bazi sayfalar bos gelir, yonetici panelinde "One or more database tables are unavailable" uyarisi belirir ya da belirli bir yazi/urun acilmaz. Bu tablo cokmesinin (table crash) tipik gorunumudur. Ozellikle MyISAM depolama motorunu kullanan eski wp_options veya wp_postmeta gibi tablolar, sunucu aniden kapandiginda ya da disk dolduginda "marked as crashed" durumuna duser.

Belirtileri hizlica siniflandirmak icin su tabloyu bir baslangic haritasi olarak kullanabilirsiniz.

Son satira dikkat: yavaslik cogu zaman onarim degil, optimizasyon konusudur. Sisme, parcalanma ve gereksiz veri birikimi ayri bir bakim disiplinidir; onlari WordPress veritabani optimizasyonu rehberinde derinlemesine ele aldik. Bu makale, gercekten bozulmus tablolara ve baglanti kopmalarina odaklanir.

Once Baglanti mi Bozuldu, Tablo mu? Teshis Adimlari#

Cozume gecmeden once sorunu dogru kutuya koymalisiniz. Yanlis teshis, saglam bir tabloyu bosuna onarmaya calismak ya da servis kapali oldugu halde saatlerce SQL komutu denemek demektir.

Ilk olarak wp-config.php dosyasindaki dort degeri gozden gecirin. Hosting parolanizi degistirdiyseniz ya da siteyi tasidiktan sonra bu hata cikdiysa, neden neredeyse her zaman buradadir.

define( 'DB_NAME', 'cloutr_wp' );
define( 'DB_USER', 'cloutr_wpuser' );
define( 'DB_PASSWORD', 'guclu-bir-parola' );
define( 'DB_HOST', 'localhost' );

Cogu paylasimli hosting ortaminda DB_HOST degeri localhost olur; bazi kurulumlarda ise 127.0.0.1 ya da localhost:3306 gerekebilir. Bu degerlerin dogrulugunu, ayni kimlik bilgileriyle komut satirindan baglanarak sinamak en kesin yoldur.

mysql -u cloutr_wpuser -p -h localhost cloutr_wp

Bu komut sizi MySQL istemine dusuruyorsa kimlik bilgileri saglamdir ve sorun tablodadir. "Access denied" aliyorsaniz parola ya da yetki sorunudur; "Can't connect to local MySQL server" aliyorsaniz servis calismiyordur. Sunucuya SSH erisiminiz varsa servisin durumunu da hizlica dogrulayin.

systemctl status mysql
# ya da MariaDB kullaniyorsaniz:
systemctl status mariadb

Bir diger sik neden dolan disktir: veritabani gecici dosya yazamaz hale gelince tablolar okunamaz gorunur. df -h ile bos alani, dolu bir disk gorurseniz once log ve gecici dosyalari temizleyin.

df -h

Eger MySQL istemine girebiliyorsaniz, hangi tablonun sorunlu oldugunu tek komutla gorebilirsiniz. CHECK TABLE size bozuk olani net soyler.

USE cloutr_wp;
CHECK TABLE wp_options, wp_posts, wp_postmeta;

Ciktida Msg_text sutunu OK yerine corrupt ya da Table is marked as crashed diyorsa hedefiniz belli demektir. Artik hangi onarim yontemini secmeniz gerektigine gecebiliriz.

Yontem 1: WordPress Dahili Onarim Araci (WP_ALLOW_REPAIR)#

WordPress'in cogu kullanicinin bilmedigi gizli bir onarim sayfasi vardir. Bu sayfa varsayilan olarak kapalidir; cunku dogrulama gerektirmeden calisir ve acik birakilirsa herkes tetikleyebilir. Acmak icin wp-config.php dosyasina tek bir satir eklersiniz.

Bu satiri wp-config.php icinde /* That's all, stop editing! */ yorum satirinin hemen ustune ekleyin.

define( 'WP_ALLOW_REPAIR', true );

Kaydettikten sonra tarayicidan asagidaki adrese gidin. Kendi alan adinizi yazmayi unutmayin.

https://orneksite.com/wp-admin/maint/repair.php

Karsiniza iki dugme cikar: "Repair Database" ve "Repair and Optimize Database". Ilk seferde sadece Repair Database secin. Optimize secenegi tablolari onardiktan sonra bir de yeniden duzenler; bu, bozuk bir tabloda gereksiz risk ve ekstra sure demektir. Once sadece onarin, site ayaga kalkinca optimizasyonu ayri bir zamanda yapin.

Bu yontemin en buyuk avantaji, MySQL komut satirina ya da phpMyAdmin'e erismeniz gerekmeden calismasidir. Dezavantaji ise WordPress'in tum tablolarini toptan tarayip onarmaya calismasi ve InnoDB motorundaki tablolarda REPAIR TABLE desteginin sinirli olmasidir. MyISAM tablolar icin mukemmel bir ilk basvurudur; InnoDB icin bir sonraki yontemlere gecmeniz gerekebilir.

Cok onemli guvenlik uyarisi: Onarim bittiginde WP_ALLOW_REPAIR satirini wp-config.php dosyasindan derhal silin. Bu satir acik kaldigi surece, repair.php sayfasi giris yapmamis herhangi biri tarafindan calistirilabilir. Bu, hem sunucunuza gereksiz yuk bindiren hem de bir DoS vektoru yaratabilecek bir aciktir. Islem biter bitmez satiri kaldirmak, bu yontemin ayrilmaz parcasidir. Bu ayrintiyi atlayan sitelerin loglarinda, aylar sonra bu URL'ye gelen otomatik istekleri gormek siradan bir olaydir.

Yontem 2: phpMyAdmin Uzerinden Repair Table#

Dahili arac sonuc vermediyse ya da tek bir tabloyu hedefli sekilde onarmak istiyorsaniz, hosting kontrol panelinizdeki (cPanel/DirectAdmin) phpMyAdmin en pratik cozumdur. Grafik arayuz sayesinde SQL bilmeden de ilerleyebilirsiniz. phpMyAdmin arayuzunun genel mantigini phpMyAdmin kullanimi rehberinde ayrintili anlattik; burada dogrudan onarim adimina odaklaniyoruz.

phpMyAdmin'e girdikten sonra sol menuden WordPress veritabaninizi secin. Tablo listesinin altinda bir acilir menu bulunur. Bozuk tablonun ya da tum tablolarin yanindaki kutuyu isaretleyin, ardindan alttaki "With selected" (Secilenlerle) menusunden Repair table secenegini tiklayin. phpMyAdmin arka planda gerekli SQL komutunu sizin adiniza calistirir.

Ayni islemi SQL sekmesinden dogrudan komutla da yapabilirsiniz; bu, hangi tabloya dokundugunuzu net gormek istediginizde daha guvenlidir.

REPAIR TABLE wp_options;
REPAIR TABLE wp_postmeta;

Birden fazla tabloyu tek satirda da onarabilirsiniz.

REPAIR TABLE wp_options, wp_posts, wp_postmeta, wp_comments;

Burada kritik bir teknik ayrinti var: REPAIR TABLE komutu yalnizca MyISAM, ARCHIVE ve CSV motorlarinda calisir. Modern WordPress kurulumlari cogunlukla InnoDB kullanir ve InnoDB bir tabloda bu komutu calistirdiginizda "The storage engine for the table doesn't support repair" uyarisi alirsiniz. InnoDB tablolari icin dogru yaklasim farklidir: cogu InnoDB bozulmasi, MySQL servisinin yeniden baslamasiyla otomatik kurtarma (crash recovery) sirasinda cozulur. Agir durumlarda innodb_force_recovery parametresiyle servisi guvenli modda baslatip veriyi disari aktarmak gerekir; bu ise sunucu yonetimi seviyesinde bir mudahaledir ve dikkatsiz kullanildiginda veri kaybina yol acabilir.

Tablonuzun hangi motoru kullandigini merak ediyorsaniz phpMyAdmin'in SQL sekmesinde su sorguyu calistirin.

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

Motor MyISAM ise REPAIR TABLE gonul rahatligiyla islerinizi gorur; InnoDB ise yol haritaniz servis yeniden baslatma ve gerekirse yedekten geri donme yonunde olmalidir.

Yontem 3: WP-CLI ile Komut Satirindan Onarim#

Sunucuya SSH erisiminiz varsa, WP-CLI bu isin en hizli ve en temiz yoludur. Tek komutla WordPress'in kendi onarim mantigini calistirir, ayrica tarayici arayuzune ya da wp-config.php duzenlemesine ihtiyac birakmaz. WP-CLI, ozellikle birden fazla siteyi yoneten ya da sik sik ayni islemi tekrarlayan sistem yoneticileri icin vazgecilmezdir.

WordPress dizinine gecip su komutu calistirin.

cd /var/www/orneksite.com
wp db repair

Bu komut, mysqlcheck aracini WordPress'in veritabani ayarlariyla otomatik olarak besleyerek tum tablolari tarar ve onarir. Ciktida her tablo icin OK ya da onarim sonucu satir satir listelenir; bu sayede hangi tablonun sorunlu oldugunu da gormus olursunuz.

Onarim oncesi hizli bir saglik kontrolu icin check komutunu da kullanabilirsiniz.

wp db check

WP-CLI'nin guzelligi, ayni oturumda hemen bir de dogrulama yapabilmenizdir. Onarimdan sonra sitenin gercekten yanit verdigini test etmek icin basit bir sorgu calistirin.

wp db query "SELECT COUNT(*) FROM wp_posts;"

Bir sonuc donuyorsa veritabani erisilebilir demektir. WP-CLI kurulu degilse ve kuramiyorsaniz, dogrudan MySQL'in kendi arac takimindaki mysqlcheck ile de ayni isi yapabilirsiniz.

mysqlcheck -u cloutr_wpuser -p --auto-repair --optimize cloutr_wp

Bu komut once bozuklugu tarar, --auto-repair bayragi sayesinde sorunlu tablolari onarir, --optimize ise onarim sonrasi tablolari yeniden duzenler. Paylasimli hosting kullaniyorsaniz ve SSH erisiminiz kisitliysa, hosting saglayicinizin sundugu terminal ozelligini ya da destek ekibini devreye alabilirsiniz. Clou.TR sunucu yonetimi hizmetinde bu tur mudahaleleri ekibimiz sizin adiniza gerceklestirir.

Yontem 4: Son Care - Yedekten Geri Yukleme#

Uc yontemin hicbiri ise yaramadiysa ya da CHECK TABLE ciktisi "Table is marked as crashed and last (automatic?) repair failed" gibi umutsuz bir mesaj veriyorsa, artik onarimla ugrasmayi birakip saglam bir yedege donmenin zamani gelmistir. Tablo yapisi fiziksel olarak bozulduginda, zorlamak yerine bilinen iyi bir kopyaya donmek hem daha hizli hem daha guvenlidir.

Elinizde bir .sql yedek dosyasi varsa, geri yukleme tek komutla yapilir. Once bozuk tablolarin cakismamasi icin mevcut veritabanini yeni bir isimle yedekleyip, ardindan iceri aktarin.

# Once mevcut (bozuk) hali arsivleyin, ne olur ne olmaz
mysqldump -u cloutr_wpuser -p cloutr_wp > bozuk_yedek_$(date +%F).sql

# Saglam yedegi iceri aktarin
mysql -u cloutr_wpuser -p cloutr_wp < saglam_yedek.sql

phpMyAdmin uzerinden geri yuklemeyi tercih ediyorsaniz, once bozuk tablolari silip (Drop) ardindan "Import" sekmesinden .sql dosyanizi yukleyin. Buyuk yedeklerde tarayicidan yukleme zaman asimina ugrayabilir; bu durumda komut satiri her zaman daha guvenilirdir.

Geri yuklemenin en can alici noktasi, yedeginizin ne kadar guncel oldugudur. Dun geceki bir yedek, son 24 saatte gelen yorumlari ve siparisleri kaybettirir. Iste tam da bu yuzden duzenli, otomatik yedekleme bir tercih degil zorunluluktur. Yedekleme hizmetimiz gunluk otomatik yedekler alarak "keske dun yedek almis olsaydim" anini tamamen ortadan kaldirir. Siteyi baska bir sunucuya tasirken benzer bir veritabani islemi yapiyorsaniz, site tasima rehberimizdeki kontrol listesi de isinizi kolaylastirir.

Geri yukleme sonrasi wp-config.php icindeki veritabani bilgilerinin yeni ortamla uyumlu oldugundan ve site adresinin dogru oldugundan emin olun; aksi halde saglam bir veritabaniyla bile "baglanti hatasi" gormeye devam edebilirsiniz.

Onarim Sonrasi Yapilacaklar ve Tekrari Onleme#

Site ayaga kalkti diye is bitmez. Onarim, altta yatan nedeni cozmediyse ayni hata birkac gun icinde geri doner. Kalici bir cozum icin sunlari sirayla gecirin.

Ilk olarak, eger dahili araci kullandiysaniz WP_ALLOW_REPAIR satirini sildiginizi bir kez daha teyit edin. Bu, en cok atlanan ve en cok risk yaratan adimdir.

Ikinci olarak, tekrarlayan tablo cokmelerinin en yaygin nedeni MyISAM motorudur. Modern, islem guvenli ve satir bazli kilitleme sunan InnoDB'ye gecmek, bozulma olasiligini ciddi olcude azaltir. Motoru donusturmek tek komutla mumkundur, ama once mutlaka yedek alin.

ALTER TABLE wp_options ENGINE=InnoDB;
ALTER TABLE wp_postmeta ENGINE=InnoDB;

Ucuncu olarak, cokmelerin arkasinda cogu zaman fiziksel bir neden yatar: dolan disk, yetersiz bellek yuzunden aniden kapanan MySQL servisi ya da kalitesiz bir sunucudaki kaynak cakismalari. Disk alaninizi izleyin, wp_options icindeki sismis transient kayitlarini duzenli temizleyin ve sunucunuzun yeterli belleğe sahip oldugundan emin olun. Paylasimli bir ortamda sik sik kaynak sinirina carpiyorsaniz, daha izole bir yapiya, ornegin bir VDS sunucuya ya da WordPress icin optimize edilmis WordPress hosting paketine gecmek kok nedeni ortadan kaldirir.

Son olarak, bir izleme aliskanligi edinin. Bir tablo cokdugunde bunu ziyaretcilerinizden once sizin ogrenmeniz gerekir. Basit bir uptime izleme, site "baglanti hatasi" verdigi an size haber verir; boylece saatlerce erisilemez kalmak yerine dakikalar icinde mudahale edersiniz. WordPress bakiminin tamamini elden birakmak isteyenler icin WordPress bakim hizmetimiz bu izleme, yedekleme ve onarim dongusunu sizin adiniza yurutur.

Sıkça Sorulan Sorular#

WP_ALLOW_REPAIR satirini kaldirmazsam ne olur?#

Bu satir acik kaldigi surece wp-admin/maint/repair.php sayfasi hicbir kimlik dogrulamasi olmadan calisir; yani giris yapmamis herhangi biri bu URL'yi cagirarak veritabani onarimini tetikleyebilir. Bu, sunucunuza kasitli olarak yuk bindirebilen bir hizmet reddi (DoS) vektorudur ve otomatik botlar zamanla bu adresi tarar. Onarim biter bitmez satiri silmek, bu nedenle islemin zorunlu son adimidir.

REPAIR TABLE komutu neden InnoDB tablolarimda calismiyor?#

Cunku REPAIR TABLE yalnizca MyISAM, ARCHIVE ve CSV depolama motorlarinda desteklenir; InnoDB bu komutu kabul etmez ve "storage engine doesn't support repair" uyarisi doner. InnoDB'nin kendi otomatik kurtarma mekanizmasi vardir ve cogu bozulma, MySQL servisinin yeniden baslamasiyla crash recovery sirasinda kendiliginden cozulur. Agir durumlarda innodb_force_recovery ile guvenli modda baslatip veriyi disari aktarmak gerekir ki bu da sunucu yonetimi seviyesinde dikkatli bir islemdir.

Onarim sirasinda veri kaybi yasar miyim?#

Cogu onarim islemi tablo yapisini duzeltir ve kayitlariniza dokunmaz, dolayisiyla veri kaybi beklenmez. Ancak tablo fiziksel olarak agir hasar gormusse onarim sirasinda bazi satirlar okunamaz hale gelip atlanabilir. Bu riski sifira indirmek icin her onarimdan once mysqldump ile mevcut halin bir kopyasini almak en dogru yaklasimdir; boylece bir sey ters giderse baslangic noktasina donebilirsiniz.

"Veritabani baglanti hatasi" her zaman bozuk tablo anlamina mi gelir?#

Hayir, cogu zaman tam tersidir. Bu mesaj genellikle WordPress'in veritabani sunucusuna hic ulasamadigini gosterir; en yaygin nedenler yanlis kullanici adi/parola, durmus MySQL servisi, dolmus disk ya da tukenmis baglanti limitidir. Once wp-config.php bilgilerini ve servisin calisip calismadigini dogrulamadan tablo onarimina girismek zaman kaybi olur. Teshis her zaman baglanti kontroluyle baslamalidir.

WP-CLI kurulu degilse tablolari nasil onaririm?#

En pratik alternatif, MySQL ile birlikte gelen mysqlcheck aracidir. mysqlcheck -u kullanici -p --auto-repair --optimize veritabani_adi komutu bozuklugu tarar, sorunlu tablolari onarir ve ardindan yeniden duzenler. SSH erisiminiz yoksa hosting kontrol panelinizdeki phpMyAdmin'in "Repair table" secenegi ya da WordPress'in dahili WP_ALLOW_REPAIR araci ayni isi grafik arayuzle gorur. Hicbirine erisemiyorsaniz hosting saglayicinizin destek ekibi mudahaleyi sizin adiniza yapabilir.

Ayni tablo tekrar tekrar cokuyor, ne yapmaliyim?#

Tekrarlayan cokmelerin en yaygin nedeni eski MyISAM depolama motorudur; tablolari ALTER TABLE ... ENGINE=InnoDB ile InnoDB'ye tasimak islem guvenligi getirir ve bozulmayi buyuk olcude azaltir. Bunun disinda dolan disk, yetersiz bellek yuzunden aniden kapanan servis ve kalitesiz paylasimli ortamlardaki kaynak cakismalari da sik gorulen fiziksel nedenlerdir. Disk ve bellek kullaniminizi izleyin, sismis transient kayitlarini temizleyin ve sorun kok nedeni kaynak yetersizligiyse daha izole bir sunucuya gecmeyi degerlendirin.

Kapanış#

WordPress veritabani onarimi, ilk bakista goronen kadar korkutucu bir konu degil. Dogru teshisle basladiginizda, cozum genellikle dort adimdan birine iniyor: WordPress'in dahili WP_ALLOW_REPAIR araci, phpMyAdmin'in Repair Table secenegi, WP-CLI'nin wp db repair komutu ya da en kotu ihtimalle saglam bir yedekten geri donmek. Onemli olan panige kapilmadan once baglanti mi tablo mu sorunu oldugunu ayirt etmek, her mudahale oncesi yedek almak ve o kritik WP_ALLOW_REPAIR satirini onarim biter bitmez silmek.

Uzun vadede en iyi onarim, hic onarima ihtiyac duymamaktir. Duzenli otomatik yedekleme, saglikli bir sunucu altyapisi ve surekli izleme, bu makaledeki senaryolari yasama olasiliginizi neredeyse sifira indirir. Sitenizi bu kaygidan tamamen kurtarmak isterseniz, Clou.TR'nin WordPress hosting paketleri gunluk yedekleme ve izleme ile gelir; daha fazla kontrol isteyenler icin VDS sunucu secenekleri ve tum bakim yukunu ustlenen WordPress bakim hizmetimiz hazir. Veritabaniniz saglamsa, siteniz de saglamdir.