WordPress Veritabanı Bağlantı Hatası Nasıl Çözülür?

WordPress veritabanı bağlantı hatası; yanlış DB_HOST, hatalı kullanıcı parolası, durmuş MySQL servisi, bozuk socket, yetersiz yetki veya dolu disk nedeniyle oluşabilir. Önce wp-config.php değerlerini doğrulayın, ardından MySQL servisini ve aynı bilgilerle komut satırı bağlantısını test edin. Böylece sorunun uygulamada mı, veritabanında mı olduğunu daraltabilirsiniz.

WordPress veritabanı bağlantı hatası neden görünür?

WordPress veritabanı bağlantı hatası, uygulamanın MySQL veya MariaDB sunucusuna bağlanamadığı ya da bağlandıktan sonra gerekli veritabanını kullanamadığı anlamına gelir. İlk kontrol wp-config.php içindeki dört değerdir: veritabanı adı, kullanıcı adı, parola ve sunucu adresi. Ardından veritabanı servisinin çalıştığı, kullanıcının yetkili olduğu ve sunucunun erişilebilir olduğu doğrulanır.

Hata ekranındaki Error establishing a database connection mesajı tek başına nedeni göstermez. Yanlış parola, durmuş servis, dolu disk, hatalı socket yolu, DNS problemi veya MySQL bağlantı sınırına ulaşılması aynı ekrana çıkabilir. Rastgele parola değiştirmek ya da sunucuyu yeniden başlatmak yerine katman katman ilerlemek daha güvenlidir.

WordPress’in dosya yapısı ve temel kurulum adımları için VPS’te WordPress Kurulumu: Adım Adım Rehber içeriğindeki yapılandırma bölümüne bakabilirsiniz. Buradaki kontroller, çalışan bir kurulumda bağlantı kesildiğinde uygulanır.

Önce hata mesajını ve erişim durumunu doğrulayın

Tarayıcıdaki genel hata ekranı, yönetim panelinin açılmaması ve HTTP 500 yanıtı birbirine benzeyebilir. Önce web sunucusunun cevap verip vermediğini, ardından PHP’nin ve veritabanının durumunu ayrı ayrı inceleyin.

curl -I https://example.com

Yanıtta 500 Internal Server Error görmeniz, isteğin web sunucusuna ulaştığını fakat uygulama katmanında sorun yaşandığını gösterir. 502 Bad Gateway ise Nginx ile PHP-FPM veya başka bir upstream arasındaki iletişime de bakılması gerektiği anlamına gelir. Bu durumda yalnızca MySQL’e odaklanmayın.

Uygulama logları dağıtıma ve web sunucusuna göre değişir. Nginx için genellikle /var/log/nginx/error.log, PHP-FPM için systemd journal, Apache içinse /var/log/apache2/error.log kullanılır.

sudo journalctl -u php8.2-fpm --since "30 minutes ago" --no-pager
sudo tail -n 50 /var/log/nginx/error.log

mysqli_real_connect(): (HY000/1045) ifadesi kimlik doğrulama veya yetki sorununa, Can't connect to local server through socket ifadesi servis ya da socket sorununa, Too many connections ise bağlantı kapasitesine işaret eder.

Hata türünü belirleyin – Tarayıcı mesajıyla yetinmeden PHP-FPM, web sunucusu ve veritabanı loglarında aynı dakikadaki kayıtları karşılaştırın.

wp-config.php içindeki dört değeri kontrol edin

WordPress bağlantı bilgilerinin ana kaynağı kurulum dizinindeki wp-config.php dosyasıdır. Dosyanın konumu çoğu kurulumda /var/www/html/wp-config.php veya alan adına özel bir web köküdür. Değerleri kopyalarken başta ya da sonda boşluk bırakmayın.

define( 'DB_NAME', 'wordpress' );
define( 'DB_USER', 'wp_user' );
define( 'DB_PASSWORD', 'guclu-ve-dogru-parola' );
define( 'DB_HOST', '127.0.0.1' );

DB_NAME veritabanının adını, DB_USER MySQL kullanıcısını, DB_PASSWORD parolayı ve DB_HOST bağlantı hedefini belirtir. Dosyadaki tırnak işaretlerini ve noktalı virgülleri koruyun.

DB_HOST her zaman yalnızca bir alan adı değildir. Aynı makinede TCP üzerinden bağlanmak için 127.0.0.1, yerel Unix socket için localhost kullanılabilir. MySQL istemcisi bazı sistemlerde localhost değerini TCP yerine socket bağlantısı olarak yorumlar. Socket yolu yanlışsa 127.0.0.1 ile test etmek, sorunun bağlantı yönteminden kaynaklanıp kaynaklanmadığını gösterir.

sudo grep -nE "DB_(NAME|USER|HOST)" /var/www/html/wp-config.php

Parolayı terminal çıktısına bastırmayın. Dosya izinlerini de kontrol edin; web sunucusu hesabının dosyayı okuyabilmesi gerekir, fakat dosya herkes tarafından yazılabilir olmamalıdır.

stat -c '%A %U:%G %n' /var/www/html/wp-config.php

chmod 777 bu problemi çözmez. Yanlış izin veya sahiplik varsa web sunucusu kullanıcısını, dağıtımın varsayılanlarını ve hosting panelinin oluşturduğu yapıyı birlikte doğrulayın.

Yapılandırmayı düzeltin – DB_NAME, DB_USER, DB_PASSWORD ve DB_HOST değerlerini veritabanı sunucusundaki gerçek bilgilerle eşleştirin.

MySQL veya MariaDB servisi çalışıyor mu?

Sunucuda veritabanı servisi durmuşsa WordPress’in doğru kullanıcı bilgileriyle bağlanması mümkün değildir. Debian ve Ubuntu sistemlerinde servis adı çoğunlukla mysql, bazı kurulumlarda mariadb olur.

sudo systemctl status mysql --no-pager
sudo systemctl status mariadb --no-pager

Unit could not be found mesajı, servisin çalışmadığını değil farklı bir servis adı kullanıldığını da gösterebilir. Paketleri listeleyin:

systemctl list-units --type=service | grep -Ei 'mysql|maria'

Servis durmuşsa önce neden durduğunu okuyun. systemctl start komutunu doğrudan çalıştırmadan önce journal kaydına bakmak; bozuk tabloyu, disk doluluğunu veya başarısız yapılandırmayı ayırt etmeye yardım eder.

sudo journalctl -u mysql -b --no-pager -n 100
sudo journalctl -u mariadb -b --no-pager -n 100

Disk doluluğu özellikle önemlidir. MySQL’in redo logları, geçici tabloları veya binary logları için boş alan kalmadığında servis açılmayabilir.

df -h
sudo du -sh /var/lib/mysql /var/log/mysql 2>/dev/null

Journal kaydındaki ilk hatayı bulun. Sadece son satıra bakmak, bazen asıl nedeni değil onun ardından oluşan ikincil hatayı gösterir.

Servisi teşhis edin – MySQL’i yeniden başlatmadan önce journal kayıtlarını ve df -h çıktısını inceleyin.

Komut satırından bağlantıyı test etmek neden önemli?

WordPress, PHP ve veritabanı arasında birden fazla katman vardır. Aynı kullanıcıyla komut satırından bağlantı kurmak, sorunun WordPress yapılandırmasında mı yoksa MySQL tarafında mı olduğunu daraltır.

mysql -h 127.0.0.1 -u wp_user -p wordpress

Komut parola sorar; parolayı komut satırına yazmayın. Böylece shell geçmişinde kalma ve süreç listesinde görünme riskini azaltırsınız. Bağlantı başarılıysa SELECT 1; ve SELECT DATABASE(); ile oturumun gerçekten kullanılabildiğini kontrol edin.

SELECT 1;
SELECT DATABASE();

ERROR 1045 (28000): Access denied alırsanız kullanıcı-parola eşleşmesi, kaynak host veya yetkiler incelenmelidir. ERROR 1049 (42000): Unknown database veritabanı adının yanlış olduğunu gösterir. ERROR 2002 ise çoğunlukla socket, TCP veya servis erişimiyle ilgilidir.

Uygulama sunucusu ile veritabanı farklı makinelerdeyse 127.0.0.1 yalnızca uygulama sunucusunu ifade eder. Bu durumda DB_HOST veritabanı sunucusunun özel IP adresi veya DNS adı olmalı; TCP portu varsayılan 3306 değilse bağlantı ayrıca belirtilmelidir.

mysql -h db.internal.example -P 3306 -u wp_user -p wordpress

Bağlantı ağ üzerinden kuruluyorsa firewall, MySQL’in bind-address ayarı ve kullanıcı hesabının izin verdiği kaynak host birlikte kontrol edilir. İnternete açık şekilde 3306/tcp yayınlamak yerine özel ağ veya VPN tercih edin.

Aynı hesabı deneyin – WordPress’te kullanılan host, kullanıcı ve veritabanı adıyla CLI bağlantısını başarıyla kurmadan uygulama dosyalarını değiştirmeyin.

MySQL kullanıcısının yetkilerini ve host bilgisini düzeltin

MySQL hesapları yalnızca kullanıcı adıyla değil, host bilgisiyle de değerlendirilir. 'wp_user'@'localhost' ile 'wp_user'@'127.0.0.1' farklı hesap kayıtları olabilir. Parola doğru olduğu hâlde erişimin reddedilmesinin nedeni bu ayrım olabilir.

sudo mysql -e "SELECT User, Host, plugin FROM mysql.user WHERE User='wp_user';"

Yetkileri uygulamanın gereksinimi kadar sınırlı tutun. WordPress’in mevcut veritabanında tablo oluşturma, değiştirme ve sorgulama işlemleri için gerekli izinlere ihtiyaç duyduğu durumlar vardır. Kullanıcıya tüm sunucuda GRANT OPTION vermek gerekmez.

SHOW GRANTS FOR 'wp_user'@'localhost';

Yetki düzeltmesi gerekiyorsa veritabanı adını doğru yazarak işlem yapın:

GRANT ALL PRIVILEGES ON `wordpress`.* TO 'wp_user'@'localhost';

Bu komut, kullanıcının yalnızca ilgili veritabanına erişmesini hedefler; yine de üretim sisteminde mevcut yetkileri kaydetmeden geniş bir GRANT uygulamayın. MySQL hesaplarında localhost ve 127.0.0.1 kayıtlarını ayrı ayrı doğrulayın. MySQL 8 ve MariaDB sürümlerinde yetki değişikliklerinin uygulanış ayrıntıları farklılaşabileceği için mevcut sürümün belgelerini kontrol edin.

MariaDB veya MySQL sürümüne göre kimlik doğrulama eklentisi farklı olabilir. Eski PHP sürümü ile yeni MySQL kimlik doğrulama yöntemi arasında uyumsuzluk varsa PHP sürümünü yükseltmek, rastgele bir authentication plugin değişikliğinden daha güvenlidir.

Bağlantı hâlâ kurulmuyorsa hangi katmanları incelemelisiniz?

Komut satırı bağlantısı başarısızsa üç olasılık öne çıkar: socket veya port yanlışlığı, ağ erişimi ve kaynak sınırı. Önce MySQL’in hangi adreste dinlediğini kontrol edin.

sudo ss -lntp | grep 3306
sudo ss -lxnp | grep -E 'mysql|maria'

İlk komut TCP dinleyicisini, ikinci komut Unix socket dosyasını arar. MySQL yalnızca 127.0.0.1:3306 üzerinde dinliyorsa uzaktaki uygulama sunucusu bağlanamaz. Tersi durumda firewall kuralı veya yanlış DNS adresi kontrol edilmelidir.

nc -vz db.internal.example 3306
getent hosts db.internal.example

nc bağlantı kuramıyorsa sorun PHP veya WordPress’e ulaşmadan önce ağdadır. Bağlantı kuruluyor fakat MySQL erişimi reddediliyorsa kullanıcı ve yetki tarafına dönün.

Too many connections hatasında SHOW STATUS LIKE 'Threads_connected'; ve SHOW VARIABLES LIKE 'max_connections'; çıktıları alınabilir. max_connections değerini artırmak geçici rahatlama sağlayabilir; PHP-FPM worker sayısı, sorgu süresi ve RAM tüketimi incelenmeden yapılan artış sunucuyu bellek baskısına sokabilir.

PHP bellek sınırı veya PHP-FPM worker problemi de veritabanı hatasıyla karıştırılabilir. Bu ayrımı anlamak için WordPress Bellek Sınırı Hatası Nasıl Çözülür? içeriğindeki log ve kaynak kontrolü yaklaşımı kullanılabilir. İşlem seviyesindeki incelemeler için Linux’ta İşlem Yönetimi: ps, top ve kill Kullanımı rehberindeki komutlar yardımcı olur.

Katmanı ayırın – Socket, TCP portu, firewall ve bağlantı sayısını sırayla test ederek sorunu PHP’den önce daraltın.

Veritabanı bozulması veya bakım gereksinimi nasıl anlaşılır?

Servis çalışıyor, kullanıcı bağlantısı başarılı fakat WordPress hâlâ hata veriyorsa tablo erişimi, disk hatası veya veritabanı bozulması incelenir. Önce yedek alın; onarım komutları bazı durumlarda tablo yapısını değiştirebilir.

WordPress’in wp-config.php dosyasına geçici olarak şu satır eklenebilir:

define( 'WP_ALLOW_REPAIR', true );

Ardından /wp-admin/maint/repair.php adresi kullanılabilir. Bu özellik bazı kurulumlarda kimlik doğrulaması istemeyebileceği için işlem biter bitmez satırı kaldırın. Yöntemi yalnızca gerekli durumlarda ve bakım penceresinde kullanın.

MySQL istemcisiyle tablo kontrolü de yapılabilir:

mysqlcheck -u wp_user -p wordpress

Her tablo için OK görülmesi bağlantı sorununu çözmez; yalnızca tablo kontrolünün başarılı olduğunu gösterir. Dosya sistemi hatası, disk doluluğu ve InnoDB kurtarma ihtiyacı ayrı konulardır. ibdata1 veya redo log dosyalarını elle silmek, veritabanını kurtarmak yerine kalıcı veri kaybına yol açabilir.

Bir tabloyu onarmadan veya silmeden önce mantıksal yedek alın:

mysqldump --single-transaction --routines --triggers wordpress > wordpress-$(date +%F).sql

InnoDB kullanan büyük veritabanlarında --single-transaction çevrimiçi yedek için uygun olabilir; MyISAM tablolarında aynı davranış garanti edilmez. Yedek dosyasının oluşması, geri döndürülebilir olduğu anlamına gelmez. Ayrı bir ortamda geri yükleme provası yapılmalıdır.

Önbellek ve eklentiler hata ekranını etkileyebilir mi?

Veritabanı düzeltildikten sonra eski hata sayfası görülüyorsa sayfa önbelleği veya PHP opcode cache devrede olabilir. Önce tarayıcıdan bağımsız bir istek yapın, ardından web sunucusu ve CDN önbelleğini temizleyin.

WordPress dosyalarına erişim varsa tüm eklentileri geçici olarak devre dışı bırakmak için eklenti klasörünü yeniden adlandırabilirsiniz:

mv wp-content/plugins wp-content/plugins.off

Hata kaybolursa klasör adını geri alıp eklentileri tek tek etkinleştirin. Bu işlem veritabanı bağlantısını doğrudan düzeltmez; yalnızca hatayı tetikleyen eklenti veya bağlantı havuzu davranışını ayırmaya yardım eder.

Debug log açılacaksa üretim sitesinde hatayı ekrana bastırmayın:

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

Log genellikle wp-content/debug.log altında oluşur. İnceleme tamamlanınca debug ayarlarını kapatın veya erişimi kısıtlayın; SQL sorgularında parola ve kişisel veri bulunabilir.

İçerik dosyalarını değiştirerek veritabanı hatasını gizlemek yerine kök nedeni düzeltin. Rastgele bir eklentiyi silmek, tablo yapısının ve eklenti ayarlarının geride kalmasına neden olabilir.

Önbelleği en sona bırakın – Servis, erişim ve yetki kontrolleri tamamlanmadan cache temizliğini çözüm olarak kabul etmeyin.

Tekrar yaşanmaması için üretim kontrolü

Bağlantı düzeldikten sonra yalnızca ana sayfayı açmak yeterli değildir. Yönetim paneli, yazı kaydetme, medya yükleme ve planlanmış görevler test edilmelidir. Aynı anda disk kullanımını, PHP-FPM loglarını ve MySQL hata logunu izleyin.

Yedekleme görevinin gerçekten çalıştığını ve geri yüklenebildiğini doğrulayın. Veritabanı yedeğini web kökünde tutmayın; dosya izinlerini, saklama süresini ve uzak kopyayı ayrıca kontrol edin.

İzleme tarafında en az şu göstergeler anlamlıdır: MySQL servis durumu, disk doluluk oranı, bağlantı sayısı, PHP-FPM aktif worker sayısı ve WordPress’in HTTP 5xx oranı. Alarm geldiğinde ilk iş olarak yeniden başlatmak yerine ilgili zaman aralığındaki logları karşılaştırın.

WordPress veritabanı bağlantı hatası bir parola probleminden ibaret olabilir; aynı ekran disk doluluğunu, yanlış socket yolunu veya aşırı bağlantı sayısını da saklayabilir. Her katmanı doğrudan test ettiğinizde çözüm yolu belirginleşir. Bir sonraki alarmda ilk komutunuz yeniden başlatma değil, hangi servisin cevap vermediğini gösteren ölçüm olsun.

Düzeltme Öncesi Kontrol Listesi

• Hata saatini ve ilgili web sunucusu ile PHP-FPM loglarını kaydedin.
• wp-config.php içindeki dört veritabanı sabitini karşılaştırın.
• mysql veya mariadb servis durumunu ve journal kayıtlarını inceleyin.
• Aynı bilgilerle komut satırından güvenli bağlantı testi yapın.
• Disk doluluğunu, MySQL portunu ve socket dosyasını kontrol edin.
• Kullanıcının host kaydını ve veritabanı yetkilerini doğrulayın.
• Onarım veya kurtarma işleminden önce doğrulanabilir yedek alın.

Sık Sorulan Sorular

Kaynaklar

• WordPress – wp-config.php Düzenleme — wordpress.org
• WordPress – Hata Ayıklama — wordpress.org
• MySQL 8.0 – Access Denied Hataları — dev.mysql.com
• PHP Manual – MySQLi Bağlantıları — php.net