“WordPress veritabanı bağlantısı kurulurken hata oluştu” mesajı, WordPress’in yazılar, kullanıcılar, ayarlar ve eklenti verileri için kullandığı MySQL veya MariaDB veritabanına erişemediğini gösterir. Sorun; hatalı wp-config.php bilgileri, veritabanı kullanıcısı yetkileri, erişilemeyen MySQL/MariaDB servisi, dolu disk, kaynak sınırı ya da daha nadiren tablo bozulmasından kaynaklanabilir. Çözüm için doğrudan dosya değiştirmek yerine önce hatanın tüm sitelerde mi, yalnızca tek WordPress kurulumunda mı görüldüğünü belirleyin. Ardından bağlantı bilgilerini ve sunucu günlüklerini doğrulayın; yedek almadan geri dönüşü zor işlemler uygulamayın.
Belirti ve kapsam: Hata neyi ifade eder?
Bu hata genellikle hem ziyaretçi tarafında hem de /wp-admin/ alanında görünür. WordPress, PHP üzerinden veritabanına bağlanır; bağlantı kurulamadığında içerikleri ve ayarları okuyamadığı için sayfayı oluşturamaz.
Önce kapsamı ayırmak, doğru müdahaleyi seçtirir:
- Yalnızca bir site etkileniyorsa: En olası alanlar
wp-config.php, ilgili veritabanı kullanıcısı, kullanıcı parolası, kullanıcı yetkileri veya o veritabanının kendisidir. - Aynı sunucudaki birçok site etkileniyorsa: MySQL/MariaDB hizmeti, disk alanı, inode, bellek, bağlantı limiti veya sunucu genelindeki bir değişiklik incelenmelidir.
- Taşıma, geri yükleme ya da parola değişiminden sonra başladıysa: Veritabanı adı, kullanıcı adı, parola veya
DB_HOSTdeğeri uyuşmuyor olabilir. - Aralıklı görülüyorsa: Kaynak tüketimi, eşzamanlı bağlantı sınırı veya MySQL/MariaDB hata günlükleri önceliklidir.
WordPress veritabanı bağlantısı kurulurken hata oluştu: hızlı teşhis özeti
Aşağıdaki kontrolleri sırasıyla uygulayın. Paylaşımlı hosting ortamında SSH veya servis yönetimi erişiminiz olmayabilir; bu durumda paneldeki veritabanı araçları ve hata günlükleriyle ilerleyin.
- Son değişiklikleri not edin: güncelleme, taşıma, parola sıfırlama, eklenti kurulumu, geri yükleme veya sunucu bakımı.
wp-config.phpiçindeki veritabanı adı, kullanıcı adı, parola ve sunucu bilgisini kontrol edin.- MySQL/MariaDB’ye aynı bilgilerle komut satırından veya güvenilir bir veritabanı istemcisinden bağlanmayı deneyin.
- Sunucuda MySQL/MariaDB servisinin çalıştığını, disk alanının dolmadığını ve hata günlüklerini doğrulayın.
- Bağlantı sağlanıyor fakat WordPress hâlâ açılmıyorsa tablo varlığını ve seçili veritabanını kontrol edin.
- Bozulma şüphesi varsa önce mantıksal yedek alın; InnoDB tablolarında rastgele onarım komutları çalıştırmayın.
Olası nedenler ve güvenli ilk aksiyonlar
| Belirti veya bulgu | Muhtemel neden | İlk güvenli kontrol |
|---|---|---|
| Taşıma veya parola değişiminden sonra başladı | Hatalı DB_NAME, DB_USER, DB_PASSWORD veya DB_HOST |
wp-config.php ile paneldeki veritabanı kayıtlarını karşılaştırın. |
| Birden fazla site aynı anda kapalı | MySQL/MariaDB durmuş, disk dolu veya sistem kaynakları tükenmiş | Servis durumu, disk kullanımı ve hata günlüklerini inceleyin. |
| “Access denied” kaydı görülüyor | Parola yanlış, kullanıcı mevcut değil veya yetki eksik | Kullanıcıyı doğru veritabanına bağlayıp gereken yetkileri doğrulayın. |
| “Too many connections” kaydı görülüyor | Bağlantı limiti aşılmış ya da sorgular uzun sürüyor | Etkin bağlantıları, yavaş sorguları ve uygulama trafiğini inceleyin. |
| Tablo hatası veya beklenmeyen çökme kaydı | Tablo/depoma motoru sorunu | Önce yedek alın; motor türüne uygun kurtarma planı belirleyin. |
Loglar ve teşhis komutları
1. WordPress yapılandırmasını dikkatle kontrol edin
WordPress kök dizinindeki wp-config.php dosyasında aşağıdaki sabitleri bulun. Parolayı ekrana, ticket kaydına veya sürüm kontrol sistemine kopyalamayın.
grep -nE "DB_(NAME|USER|HOST|PASSWORD)" /var/www/html/wp-config.phpYol örnektir; kurulumunuzun gerçek belge kökünü kullanın. Özellikle DB_HOST her zaman localhost olmak zorunda değildir. Bazı yönetilen veya uzak veritabanı mimarilerinde sağlayıcının verdiği sunucu adı ve gerekirse özel port kullanılır.
2. Veritabanına doğrudan bağlantıyı test edin
Bu test WordPress katmanını devreden çıkarır. Komut parolayı etkileşimli ister; parolayı komut satırına yazmak, kabuk geçmişine düşebileceği için önerilmez.
mysql -h DB_HOST -u DB_USER -p DB_NAMEBağlantı açıldıktan sonra seçili veritabanını ve WordPress tablolarını kontrol edin:
SELECT DATABASE();
SHOW TABLES;
EXIT;wp_ öneki varsayılandır; güvenlik veya çoklu kurulum nedeniyle tablolar farklı bir önekle başlayabilir. Bu önek, wp-config.php içindeki $table_prefix değeriyle uyumlu olmalıdır.
3. Linux üzerinde servis, disk ve günlük kontrolü
Bu adımlar root veya sudo yetkisi gerektirir. Systemd kullanan dağıtımlarda servis adı çoğunlukla mariadb veya mysql olur; hangisinin sisteminizde bulunduğunu kontrol edin.
systemctl status mariadb
systemctl status mysql
df -h
df -i
journalctl -u mariadb -n 100 --no-pager
journalctl -u mysql -n 100 --no-pagerdf -h disk alanını, df -i inode kullanımını gösterir. Diskin veya inode’ların dolması MySQL/MariaDB’nin geçici dosya ya da günlük yazmasını engelleyebilir. Günlük dosyalarının konumu dağıtıma ve yapılandırmaya göre değiştiğinden, doğrulanmamış sabit bir dosya yolunu varsaymayın.
4. Bağlantı yoğunluğunu inceleyin
Veritabanına yönetici yetkisiyle bağlanabiliyorsanız bağlantı limitini ve anlık durumu kontrol edin:
mysql -u root -p -e "SHOW VARIABLES LIKE 'max_connections'; SHOW STATUS LIKE 'Threads_connected'; SHOW FULL PROCESSLIST;"Too many connections bulgusunu sadece max_connections artırarak çözmeye çalışmayın. Daha yüksek limit daha fazla bellek tüketebilir. Uzun süren sorgular, hatalı önbellek davranışı, trafik artışı veya bağlantıları kapatmayan özel kodlar asıl neden olabilir.
Güvenli adım adım çözüm
Adım 1: Yedek ve bakım penceresi hazırlayın
Parola, yetki, servis veya tablo işlemi öncesinde mevcut durumu yedekleyin. Veritabanına erişim varsa mantıksal yedek alın. Büyük veritabanlarında çıktı için yeterli boş alan olduğundan emin olun.
mysqldump -h DB_HOST -u DB_USER -p --single-transaction --routines --events DB_NAME > DB_NAME-before-db-fix.sql--single-transaction, InnoDB ağırlıklı veritabanlarında tutarlı yedek almaya yardımcı olur; MyISAM tabloları için aynı tutarlılık garantisini sağlamaz. Üretim ortamında geri yükleme, servis yeniden başlatma veya kurtarma adımlarını mümkünse bakım penceresinde uygulayın.
Adım 2: Kimlik bilgilerini ve kullanıcı yetkilerini düzeltin
Panel kullanıyorsanız veritabanı adı ve kullanıcı adı, hesap öneki içerebilir. wp-config.php değerlerini panelde görünen tam adlarla karşılaştırın. Parola sıfırlandıysa yeni parolayı wp-config.php içindeki DB_PASSWORD değerine güncelleyin.
Yetki sorunu varsa, ilgili kullanıcıyı doğru veritabanına bağlayın ve WordPress’in normal çalışması için gereken izinleri paneliniz veya yetkili DBA aracılığıyla atayın. Geniş kapsamlı GRANT ALL ON *.* gibi sunucu genelindeki yetkiler vermeyin. Değişiklikten sonra doğrudan mysql bağlantı testini yeniden yapın.
Adım 3: MySQL/MariaDB hizmetini yalnızca nedeni gördükten sonra ele alın
Servis çalışmıyorsa önce günlüklerdeki son hatayı belirleyin. Disk doluluğu, yanlış sahiplik, bellek baskısı veya başarısız bir yapılandırma değişikliği çözülmeden yapılan tekrar tekrar başlatmalar yararlı değildir. Nedeni giderdikten sonra, bakım penceresinde ve yetkili erişimle uygun servis adını kullanarak başlatın:
sudo systemctl start mariadb
sudo systemctl status mariadb --no-pagerSisteminizde servis mysql adıyla tanımlıysa aynı işlemi o adla uygulayın. Servis zaten çalışıyorsa gereksiz yeniden başlatma yapmayın; devam eden işlemleri ve hata günlüklerini inceleyin.
Adım 4: Tablo bozulması şüphesini depolama motoruna göre yönetin
Önce motor türünü görün:
mysql -h DB_HOST -u DB_USER -p DB_NAME -e "SHOW TABLE STATUS;"InnoDB tablolarında klasik REPAIR TABLE komutunu çözüm olarak kullanmayın; InnoDB için uygun değildir. Erişim hâlâ mümkünse CHECK TABLE yalnızca inceleme amacıyla uygulanabilir:
mysql -h DB_HOST -u DB_USER -p DB_NAME -e "CHECK TABLE wp_options, wp_posts;"Tablo adlarını kendi önekinize göre değiştirin. Sunucu genelinde kontrollü denetim için mysqlcheck kullanılabilir:
mysqlcheck -h DB_HOST -u DB_USER -p --check DB_NAMEInnoDB açılmıyor veya çöküyorsa, uzman incelemesi olmadan kalıcı ayar değişiklikleri yapmayın. innodb_force_recovery normal çalışma çözümü değildir; yalnızca en düşük gerekli seviyeden başlayarak veri dışa aktarmaya yönelik, riskli bir acil kurtarma seçeneğidir. Yazma işlemlerini sınırlayabilir ve yanlış kullanım veri kaybını büyütebilir. Güvenilir yedekten geri dönmek ya da kurtarılabilen veriyi dump alıp temiz bir örneğe geri yüklemek çoğu durumda daha güvenli yaklaşımdır.
Çözümü doğrulama
Her değişiklikten sonra aşağıdaki kontrolleri yapın:
mysql -h DB_HOST -u DB_USER -p DB_NAMEkomutu hata vermeden bağlanıyor mu?SHOW TABLES;beklenen WordPress tablolarını gösteriyor mu?- Site ana sayfası, tekil bir yazı, giriş sayfası ve
/wp-admin/alanı HTTP 200 ile açılıyor mu? - WordPress yönetiminde yazı kaydetme veya ayar güncelleme gibi kontrollü bir yazma işlemi başarılı mı?
- PHP/web sunucusu ve MySQL/MariaDB günlüklerinde yeni bağlantı hataları sürüyor mu?
Önbellek katmanı varsa doğrulama sırasında eski hata sayfası sunulabilir. Önce gerçek uygulama yanıtını, sonra gerekli ise kullandığınız önbellek katmanının kendi prosedürüne uygun temizliğini değerlendirin.
Tekrarını önleme
- WordPress dosyaları ile veritabanı için düzenli, geri yüklemesi test edilmiş yedekler tutun.
- Disk alanı, inode, bellek ve MySQL/MariaDB hata oranı için izleme ve uyarı eşiği belirleyin.
- Veritabanı parolası değişikliklerini kayıt altına alın;
wp-config.phpgüncellemesini kontrollü dağıtım sürecine ekleyin. - Her WordPress kurulumu için ayrı, en az yetkili veritabanı kullanıcısı kullanın.
- Eklenti, tema veya WordPress güncellemelerini önce test ortamında deneyin; üretimde planlı değişiklik yapın.
- Yüksek trafikte yavaş sorguları ve kalıcı bağlantı tüketimini düzenli inceleyin.
Sonuç
WordPress veritabanı bağlantısı kurulurken hata oluştu mesajında en hızlı güvenli yol; önce kapsamı ayırmak, ardından kimlik bilgilerini doğrudan bağlantı testiyle doğrulamak ve servis ile günlük bulgularına göre ilerlemektir. Özellikle InnoDB kaynaklı şüphelerde rastgele onarım yerine yedek, kontrollü dump/restore ve gerektiğinde uzman destekli kurtarma planı tercih edilmelidir.
Sık sorulan sorular
wp-config.php içindeki DB_HOST değeri her zaman localhost mudur?
Hayır. Aynı sunucudaki tipik kurulumlarda localhost sık kullanılır; ancak uzak veya yönetilen veritabanlarında sağlayıcının verdiği ana makine adı, IP adresi ya da özel bağlantı bilgisi gerekir.
Bu hata WordPress eklentisinden kaynaklanabilir mi?
Dolaylı olarak evet. Hatalı ya da yoğun sorgu üreten bir eklenti bağlantı limitini veya kaynakları tüketebilir. Ancak önce veritabanı bağlantı testi ve sunucu günlükleriyle temel erişim sorununu dışlayın.
InnoDB tablolarında REPAIR TABLE çalıştırmalı mıyım?
Hayır. REPAIR TABLE InnoDB için doğru kurtarma yöntemi değildir. Erişim varsa yedek ve denetim yapın; ciddi InnoDB sorunlarında dump/restore, yedekten dönüş veya dikkatle planlanmış kurtarma süreci değerlendirilmelidir.
Veritabanı parolasını değiştirmek veri kaybettirir mi?
Parola değişikliği tek başına veriyi silmez. Fakat yeni parola hem veritabanı kullanıcısında hem de wp-config.php içinde tutarlı güncellenmezse site bağlantı kuramaz.
Paylaşımlı hostingde MySQL servisini neden başlatamıyorum?
Servis yönetimi sunucu yöneticisinin yetkisindedir. Paneldeki veritabanı ve kullanıcı eşleşmelerini kontrol edin, hata zamanını not edin ve servis/log incelemesi için sağlayıcınızın destek kanalıyla ilerleyin.
