WordPress Veritabanı Bağlantı Hatası: 5 Çözüm

WordPress veritabanı bağlantı hatası neden çıkar?

Gece yarısı gelen “Error establishing a database connection” ekranı, WordPress yöneticisinin görmek isteyeceği son şeylerden biridir. Ziyaretçi siteyi göremez, yönetim paneli açılmaz ve hata mesajı çoğu zaman sorunun hangi katmanda olduğunu söylemez. Web sunucusu çalışıyor olabilir; asıl problem MariaDB veya MySQL servisi, kullanıcı bilgileri, disk alanı ya da bozulmuş bir tablo tarafında bulunabilir.

Destek biletlerinde sık gördüğüm hata, bu ekran gelir gelmez wp-config.php dosyasının rastgele değiştirilmesi. Bazen doğru yere bakılıyor, bazen de çalışan site yeni bir sorunla baş başa bırakılıyor. Ben önce hatanın tüm ziyaretçilerde mi, yalnızca yönetim panelinde mi görüldüğünü ayırırım. Ardından web sunucusu, PHP ve veritabanı loglarını aynı zaman aralığında incelerim.

Şöyle anlatayım: WordPress veritabanı bağlantı hatası tek bir arıza değildir; aynı ekranı üreten birkaç farklı problem sınıfıdır. Aşağıdaki kontrolleri düşük riskliden daha müdahaleci olana doğru sıraladım. Tablo onarımı ve dosya değişiklikleri için önce yedek durumunu doğrulayın.

İlk dakikalarda neyi kontrol etmeli?

Önce kesintinin kapsamını belirleyin. Siteyi gizli sekmede açın, farklı bir ağdan deneyin ve /wp-admin/ adresini kontrol edin. Yalnızca bir eklentinin kullandığı özel sayfa açılmıyorsa sorun veritabanı bağlantısından çok eklentinin sorgusunda olabilir.

Sunucuya SSH erişiminiz varsa şu kontroller ilk resmi çizer:

df -h
free -m
systemctl status mariadb --no-pager
systemctl status mysql --no-pager

İlk komut disk doluluğunu, ikincisi bellek durumunu, son iki komut da sisteminizde kullanılan veritabanı servisinin durumunu gösterir. Dağıtıma göre servis adı mysql veya mariadb olabilir. İkisini de körlemesine yeniden başlatmayın; önce çıktıyı okuyun.

Bir gece rotasyonu unutulan access log sunucunun diskini doldurmuştu. Bilette yalnızca “site açılmıyor” yazıyordu. df -h çıktısında kök dosya sistemi yüzde 100 dolu görünce veritabanı arızası sandığımız şeyin aslında log yönetimi problemi olduğunu gördük. O günden beri disk doluluğu ilk kontrollerimden biridir.

İnternette gördüğünüz bir komutu ne yaptığını anlamadan sudo ile çalıştırmayın. Özellikle curl | sudo bash biçimindeki kurulum önerileri, veritabanı arızasını çözmek için güvenilir bir başlangıç değildir.

1. wp-config.php içindeki bilgileri doğrulayın

WordPress veritabanı bilgilerini genellikle sitenin kök dizinindeki wp-config.php dosyasından okur. Beş değer özellikle önemlidir:

DB_NAME: Veritabanının adı
DB_USER: Veritabanı kullanıcısı
DB_PASSWORD: Kullanıcının parolası
DB_HOST: Veritabanı sunucusunun adresi veya soketi
$table_prefix: Tabloların öneki

Taşıma sonrasında sık karşılaştığım durum, veritabanının yeni sunucuya aktarılması ama DB_NAME veya DB_USER değerinin eski sunucuya göre bırakılmasıdır. Panelden yeni bir veritabanı parolası üretip wp-config.php dosyasını güncellememek de aynı sonucu doğurur.

Dosyayı görüntülerken parolayı destek talebine, ekran görüntüsüne veya ortak sohbet kanalına koymayın. Değerleri sunucuda kontrol etmek için:

cd /home/kullanici/public_html
grep -E "DB_NAME|DB_USER|DB_HOST|table_prefix" wp-config.php

Bu komut parolayı yazdırmadan temel ayarları gösterir. Çıktıdaki veritabanı adıyla paneldeki adın gerçekten aynı olduğuna bakın. cPanel veya CyberPanel gibi panellerde hesap kullanıcı adı veritabanı adına otomatik olarak eklenebilir; örneğin site_wp yerine kullanici_site_wp kullanılması gerekebilir.

Parolanın doğru olup olmadığını WordPress üzerinden değil, doğrudan istemciyle sınayabilirsiniz:

mysql -h 127.0.0.1 -u veritabani_kullanici -p veritabani_adi

Parola sorulduğunda girin. Welcome to the MariaDB monitor benzeri bir karşılama görürseniz kimlik bilgileri ve ağ erişimi çalışıyor demektir. Access denied çıkarsa kullanıcı, parola veya yetki tarafına dönün. Parolayı komut satırına doğrudan yazmayın; kabuk geçmişinde kalabilir.

2. Veritabanı servisi çalışıyor mu?

Doğru bilgilerle bile servis durmuşsa WordPress bağlanamaz. Bu durum bakım sonrasında veya belleği tüketen bir sorgunun ardından görülebilir. Servis durumunu ve son logları birlikte kontrol edin:

sudo systemctl status mariadb --no-pager
sudo journalctl -u mariadb -n 80 --no-pager

Loglarda InnoDB: Unable to lock, Too many connections, Out of memory veya disk yazma hataları gibi ifadeleri arayın. systemctl status servisin çalışıp çalışmadığını söyler; neden durduğunu çoğu zaman journalctl gösterir.

Disk doluysa MariaDB yeni geçici dosya veya binary log oluşturamayabilir. Önce df -h ile hangi bağlama noktasının dolduğunu bulun, ardından ncdu ile alan tüketen dizinleri inceleyin. Rastgele log veya veritabanı dosyası silmek yerine rotasyon ayarını düzeltin. Özellikle /var/lib/mysql altındaki dosyaları elle silmek, kurtarılabilir bir arızayı veri kaybına çevirebilir.

Servis durmuş ve loglar yapılandırma hatası göstermiyorsa yeniden başlatma denenebilir:

sudo systemctl restart mariadb
sudo systemctl status mariadb --no-pager

Yeniden başlatma kısa süreli erişim sağlayabilir; fakat kök neden bellek veya disk problemiyse aynı hata geri gelir. Paylaşımlı hosting kullanıyorsanız bu işlemi siz yapamazsınız. Hosting firmasından servis durumu, disk kullanımı ve ilgili zaman aralığındaki veritabanı loglarını istemeniz gerekir.

3. DB_HOST ve bağlantı soketini inceleyin

Birçok Linux sunucusunda DB_HOST değeri localhost olduğunda WordPress TCP yerine Unix soketi kullanır. Veritabanı servisi farklı bir soket yolu ile çalışıyorsa veya sağlayıcı uzak bir veritabanı sunucusu kullanıyorsa bağlantı başarısız olabilir.

Yerel veritabanlarında sık kullanılan deneme, DB_HOST değerini 127.0.0.1 yapmaktır:

define( 'DB_HOST', '127.0.0.1' );

localhost ile 127.0.0.1 aynı davranmaz. İlki çoğu istemcide Unix soketine yönlenebilir, ikincisi TCP bağlantısı kurar. Değişiklikten önce dosyanın yedeğini alın ve PHP sözdizimini bozmadığınızdan emin olun.

Veritabanı ayrı bir sunucudaysa DB_HOST, sağlayıcının verdiği hostname ile yazılmalıdır. Uzak sunucunun güvenlik duvarında kaynak IP’ye izin verilmesi, MariaDB’nin dinleme adresinin uygun olması ve kullanıcının doğru host üzerinden yetkilendirilmesi gerekir. user@localhost ile [email protected].% farklı yetkilerdir.

Bağlantı portu standart değilse değer şu biçimde yazılabilir:

define( 'DB_HOST', 'db.internal.example:3307' );

Bu ayarı değiştirirken bağlantının gerçekten hangi sunucuya gittiğini doğrulayın. Bir destek biletinde bunu ben de öğrendim: Taşıma sonrası tüm bilgiler doğru görünüyordu, fakat DB_HOST eski sağlayıcının özel hostname’i olarak kalmıştı. Yeni sağlayıcının dahili adresini kullandığımızda site açıldı. Aynı sunucuda olduğunu varsaymak yerine bağlantıyı doğrudan test etmek daha hızlıdır.

4. Tabloları ve bakım durumunu kontrol edin

Veritabanı servisi çalışıyor ve kimlik bilgileri doğru olduğu halde bazı sayfalarda hata görüyorsanız tablo bozulması ihtimali vardır. Elektrik kesintisi, dolan disk, hatalı depolama veya yarım kalan işlem bu duruma yol açabilir.

Önce veritabanının dışa aktarımını alın. SSH üzerinden wp-cli kullanıyorsanız:

cd /home/kullanici/public_html
wp db export /home/kullanici/backup-$(date +%F-%H%M).sql

Bu işlem WordPress veritabanını tarih ve saat içeren bir SQL dosyasına aktarır. Dosyanın oluştuğunu, boyutunun makul olduğunu ve farklı bir depolama alanına kopyalandığını kontrol edin. Aynı diskte duran tek kopya, arıza anında güvence değildir.

Ardından tablo kontrolü yapın:

wp db check

Çıktıda tüm tabloların kontrol edildiğini ve hata bulunmadığını görürseniz tablo bozulması ihtimali azalır. Hatalı tablolar listelenirse hosting sağlayıcınızın veya veritabanı yöneticinizin önerisini alın. MySQL istemcisiyle tablo onarımı, özellikle InnoDB tablolarında, MyISAM için kullanılan basit REPAIR TABLE yaklaşımından farklıdır.

WordPress’in yerleşik onarım ekranı da kullanılabilir. Bunun için geçici olarak wp-config.php içine şu satırı ekleyin:

define( 'WP_ALLOW_REPAIR', true );

Ardından https://alanadiniz.example/wp-admin/maint/repair.php adresini açın. Bu ekran giriş yapmadan erişilebildiği için işlem biter bitmez satırı kaldırın. Önce yalnızca kontrol seçeneğini kullanın; ne yaptığını bilmeden onarım çalıştırmak yerine tam yedek ve log ile ilerleyin.

WordPress güncellemesi yarıda kaldıysa kök dizinde .maintenance dosyası bulunabilir. Bu dosya genellikle veritabanı bağlantı hatası üretmez, ancak siteyi bakım ekranında bırakır. Hata gerçekten Error establishing… ise .maintenance dosyasını silmek çözüm olmayacaktır.

5. Eklenti ve ağır sorguları ayırın

Veritabanına bağlantı kuruluyor olsa bile bir eklenti çok sayıda bağlantı açabilir, ağır sorgular çalıştırabilir veya PHP sürecini zaman aşımına uğratabilir. Ziyaretçi genel WordPress hata ekranını görürken kök neden belirli bir eklenti olabilir.

Yönetim paneli açılmıyorsa eklentileri geçici olarak yeniden adlandırabilirsiniz:

cd /home/kullanici/public_html/wp-content
mv plugins plugins.off

Site açılırsa eklenti klasörünü eski adına döndürüp eklentileri tek tek etkinleştirin. Bu işlem eklenti dosyalarını silmez; WordPress’in klasörü tarayamamasını sağlayarak hepsini geçici olarak devre dışı bırakır.

WP-CLI erişiminiz varsa daha kontrollü yöntem şudur:

wp plugin deactivate --all
wp plugin list --status=active

İlk komut etkin eklentileri kapatır, ikinci komut mevcut durumu gösterir. Üretim sitesinde toplu devre dışı bırakma kısa süreli işlev kaybı yaratabilir; WooCommerce mağazasında ödeme ve sepet akışını ayrıca test edin.

PHP ve WordPress loglarını da kontrol edin. WP_DEBUG değerini üretimde açık bırakmak ziyaretçilere hassas hata bilgisi sızdırabilir. Geçici teşhis için loglamayı ekrana basmadan açabilirsiniz:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );

Ardından wp-content/debug.log dosyasını inceleyin ve işiniz bitince hata ayıklamayı kapatın. Logda aynı eklenti dosyasının tekrar tekrar görünmesi, veritabanı servisinin sağlıklı olduğu anlamına gelmez; o eklenti bağlantı havuzunu veya sorgu kaynaklarını tüketiyor olabilir.

Belirtiye göre başlangıç noktasını daraltın

Belirti	Muhtemel neden	İlk kontrol
Site ve wp-admin birlikte açılmıyor	Servis durmuş, kimlik bilgileri yanlış veya disk dolu	`df -h`, servis durumu ve `wp-config.php`
Yalnızca bazı sayfalar hata veriyor	Bozuk tablo, eklenti veya ağır sorgu	`wp db check` ve eklenti izolasyonu
Taşıma sonrası hata başladı	DB adı, kullanıcı yetkisi veya DB_HOST değişti	Yeni sunucuda doğrudan MySQL bağlantısı
Aralıklı bağlantı hatası oluşuyor	Kaynak sınırı, bağlantı limiti, ağ veya yoğun sorgu	MariaDB logları, PHP-FPM logları ve süreç kullanımı

Bu tablo tanı koymaz; yalnızca nereden başlayacağınızı daraltır. Aralıklı hatalarda tek bir başarılı bağlantı testi sizi yanıltmasın. Site yoğunken Too many connections görülüyorsa limiti artırmadan önce bağlantıları tüketen sorguyu veya eklentiyi bulun.

Hosting desteğine hangi bilgileri iletmelisiniz?

Destek talebine yalnızca “sitem açılmıyor” yazmak, iki tarafın da zamanını uzatır. Hatanın başladığı saat, etkilenen alan adı, sitenin tamamen mi yoksa aralıklı mı kapandığı, son yapılan değişiklik ve görülen hata metni iyi bir başlangıçtır.

wp-config.php dosyasını göndermeyin; parola ve anahtarları paylaşmayın.
Hata zamanını İstanbul saatiyle yazın.
Son eklenti, tema, PHP veya sunucu değişikliğini belirtin.
Varsa hata ekranını ve ilgili log satırlarını hassas bilgileri maskeleyerek ekleyin.
Site WooCommerce kullanıyorsa ödeme, sipariş ve yönetim panelinin ayrı ayrı etkilenip etkilenmediğini söyleyin.

Hosting tarafı servis loglarını, disk kotasını, MySQL süreçlerini ve hesap limitlerini görebilir. Siz de belirtileri net verirseniz, “sunucu mu site mi?” tartışması yerine doğrudan kanıta bakılır.

Aynı hatayı yeniden yaşamamak için

WordPress güncellemesinden önce wp db export almak bende refleks haline geldi. Evdeki Proxmox lab’ımda bir güncellemenin önce test VM’inde patlamasını, müşteri sunucusunda patlamasına tercih ederim. Yedeğin varlığı kadar geri yüklenebilir olması da önemlidir; ayda bir rastgele bir SQL dosyasını ve birkaç WordPress dosyasını geri yükleyerek bunu sınayın.

Sunucuda disk kullanımını, MariaDB servis durumunu ve SSL yenileme cron’unu izleyin. Raspberry Pi üzerindeki Uptime Kuma kurulumum tam da bu yüzden çalışıyor: izlemediğiniz cron, çalışmayan cron olabilir. Paylaşımlı hostingte panel uyarılarını ve sağlayıcının kaynak kullanım ekranını düzenli kontrol edin.

WordPress çekirdeğini, temaları ve eklentileri güncel tutun; fakat güncellemeyi yedeksiz ve kontrolsüz yapmayın. Yönetici hesabında admin ve tahmin edilebilir parolalar kullanmayın. Güvenlik tarafındaki temel kontroller için Küçük İşletmeler İçin Web Hosting Güvenlik Kontrol Listesi başlığına bakabilirsiniz.

Veritabanı hatası sonrasında dosya izinlerini rastgele chmod 777 yapmak çözüm değildir. Sorunun adını değiştirir, kendisini değil. Web sunucusu kullanıcısının doğru sahiplik ve izinlerle çalışmasını sağlayın; değişiklik yapacaksanız önce mevcut durumu kaydedin.

Alan adı veya sunucu taşıması yapıyorsanız DNS tarafını işlem planına dahil edin. DNS Kayıt Türleri Nedir? A, AAAA, MX, CNAME, TXT, SRV ve CAA İçin Uygulamalı Rehber içinde A kaydı, TTL ve doğrulama adımlarını karşılaştırmıştım. Veritabanı hazır olsa bile ziyaretçiler eski sunucuya gidiyorsa yaptığınız düzeltmeyi hemen göremeyebilirsiniz.

Sık Sorulan Sorular

WordPress veritabanı bağlantı hatası hosting kaynaklı olabilir mi?

Evet. MariaDB servisinin durması, disk alanının bitmesi, hesap kaynak limitleri veya ağ erişimi bu hataya yol açabilir. Aynı sunucudaki diğer siteler de etkileniyorsa hosting tarafındaki servis ve kaynak kontrolleri önceliklidir.

wp-config.php dosyasında hangi satırları kontrol etmeliyim?

DB_NAME, DB_USER, DB_PASSWORD ve DB_HOST değerlerini kontrol edin. Ayrıca veritabanı kullanıcısının ilgili veritabanına yetkisi olduğunu doğrulayın; yalnızca dosyadaki metinlerin doğru görünmesi yeterli değildir.

Veritabanını onarmak için repair.php kullanmak güvenli mi?

Önce çalışan bir veritabanı yedeği alın ve WP_ALLOW_REPAIR satırını işlemden sonra mutlaka kaldırın. Bu sayfa giriş gerektirmeden erişilebildiği için açık bırakılması güvenlik riski oluşturur; InnoDB sorunlarında onarım yöntemini ayrıca dikkatle seçmek gerekir.

Bağlantı hatası aralıklı oluyorsa neye bakmalıyım?

MariaDB loglarında bağlantı limiti, bellek ve zaman aşımı mesajlarını arayın. PHP-FPM süreçleri, ağır eklenti sorguları, ani trafik ve disk gecikmesi de aralıklı kesintilere neden olabilir; yalnızca DB_HOST değerini değiştirmek her zaman çözüm getirmez.

Ben böyle bir hatada ilk olarak ekrana değil, katmanlara bakıyorum: disk, servis, kimlik bilgileri, bağlantı adresi ve sorgu. Her kontrolden sonra çıktıyı kaydederseniz, gece yarısı paniği yerini takip edilebilir bir arızaya bırakır.

Post Views: 28