Veritabanı Bağlantısı Kurulurken Hata Oluştu Ne Demek, Nasıl Çözülür

Sitenizi açtığınızda bembeyaz bir sayfanın ortasında tek bir cümle duruyor: "Veritabanı bağlantısı kurulurken hata oluştu." İngilizce kurulumlarda aynı ekran "Error establishing a database connection" olarak çıkar. Menü yok, tasarım yok, wp-admin de açılmıyor. Bu ekran, WordPress'in dosyalarının yerinde durduğunu ama içeriğin tutulduğu MySQL veritabanına hiçbir şekilde bağlanamadığını söyler. Yani PHP çalışıyor, sunucu ayakta, sorun tam olarak PHP ile veritabanı arasındaki o tek bağlantıda.

Bu yazıda hatayı "wp-config.php'yi kontrol edin" tavsiyesinin çok ötesine taşıyacağız. Yıllardır paylaşımlı hosting ve VDS üzerinde bu hatayı ayıklarken gördüğüm gerçek dağılım şudur: vakaların küçük bir kısmı gerçekten yanlış parolayken, büyük kısmı bağlantı limiti aşımı (max_user_connections), veritabanı kullanıcısının yetkisinin düşmesi, DB_HOST değerinin localhost olmadığı bir mimari ya da MySQL servisinin tamamen durmasıdır. Aşağıda önce hatanın hangi katmandan geldiğini kesinleştireceğiz, sonra WordPress'ten tamamen bağımsız çalışan küçük bir PHP betiğiyle bağlantıyı test edip MySQL'in size döndürdüğü gerçek hata numarasını okuyacağız. O numara, doğru çözümü tahmin etmeden bulmanızı sağlar.

Bu Hata Tam Olarak Ne Anlama Geliyor#

WordPress her sayfa isteğinde wp-config.php dosyasındaki dört değerle MySQL'e bağlanmayı dener; bağlantı kurulamazsa wp-db.php içindeki hata yakalayıcı devreye girer ve bu tek satırlık ekranı basar. Kritik nokta şudur: WordPress size neden bağlanamadığını söylemez. Yanlış parola da, sunucunun bağlantı limitinin dolması da, MySQL servisinin çökmesi de aynı ekranı üretir. Bu yüzden ekranı okuyarak teşhis koymak mümkün değildir; hatayı bir katman aşağıda, MySQL'in kendi hata numarasında aramak gerekir.

Bağlantı zinciri şu dört halkadan oluşur ve herhangi biri koptuğunda aynı ekranı görürsünüz:

1. Kimlik bilgileri — DB_NAME, DB_USER, DB_PASSWORD doğru mu?
2. Adres — DB_HOST doğru sunucuyu/soketi mi gösteriyor?
3. Yetki — bu kullanıcının bu veritabanına, bu host'tan erişim izni var mı?
4. Kapasite — MySQL yeni bir bağlantı kabul edecek durumda mı, yoksa limit mi dolmuş?

İlk iki halka için insanlar saatlerce uğraşır çünkü tavsiyelerin tamamı oraya odaklıdır. Oysa sitesi dün gece sorunsuz çalışıp sabah bu ekrana düşenlerin büyük çoğunluğunda 1. ve 2. halka hiç değişmemiştir — sorun 3. veya 4. halkadadır.

Önce Hangi Ekranı Gördüğünüzü Kesinleştirin#

Doğru teşhis, gördüğünüz ekranın tam metnini ayırt etmekle başlar. Üç farklı varyant vardır ve üçü farklı yerlere işaret eder:

Üçüncü satır özellikle önemlidir: ana sayfa normal, sadece yönetim paneli bu hatayı veriyorsa bağlantı zaten kuruluyor demektir; sorun bağlantıda değil, birkaç tablonun bozulmasındadır. Bu ayrımı yapmadan wp-config.php ile uğraşmak boşa zaman kaybıdır. Panele giriş konusunda başka semptomlar da yaşıyorsanız wordpress admin paneline giremiyorum yazısındaki eleme sırası daha uygun olabilir.

wp-config.php İçindeki Dört Değeri Doğrulama#

wp-config.php sitenizin kök dizinindedir (public_html/wp-config.php). cPanel Dosya Yöneticisi'nden ya da FTP ile açın. Aradığınız blok şudur:

define( 'DB_NAME', 'kullanici_wp01' );
define( 'DB_USER', 'kullanici_wpuser' );
define( 'DB_PASSWORD', 'parola-buraya' );
define( 'DB_HOST', 'localhost' );
define( 'DB_CHARSET', 'utf8mb4' );

Bu dört değeri gözle kontrol etmek yeterli değildir; karşılaştırma yapmanız gerekir. cPanel kullanıyorsanız MySQL® Veritabanları ekranını açın ve şu üçünü doğrulayın:

1. Veritabanı listesinde DB_NAME ile birebir aynı ad var mı? Paylaşımlı hostingde veritabanı adları hesap ön ekiyle oluşturulur (kullanici_ gibi); yeni kurulumlarda bu ön ek unutulur.
2. "Geçerli Kullanıcılar" listesinde DB_USER var mı?
3. Sayfanın altındaki "Veritabanına Kullanıcı Ekle" bölümünün altındaki tabloda, bu kullanıcı o veritabanına atanmış görünüyor mu?

Üçüncü madde en sık atlanan maddedir. Kullanıcı var, veritabanı var, parola doğru — ama ikisi birbirine bağlanmamış. Bu durumda MySQL size 1044 numaralı "Access denied for user to database" hatasını döndürür.

Parolayı doğrulamanın en hızlı yolu değiştirmektir. cPanel'de kullanıcının üzerine tıklayıp yeni bir parola üretin, sonra aynı parolayı wp-config.php içine yazın. Parolada $, ', \ gibi karakterler varsa PHP'nin tek tırnak içinde bunları farklı yorumlayabileceğini unutmayın; sorun yaşamamak için harf-rakam ağırlıklı, en az 16 karakterlik bir parola üretin.

Bağlantıyı WordPress'ten Bağımsız Test Edin#

Bu adım, Türkçe kaynakların neredeyse tamamının atladığı ve teşhis süresini dakikalara indiren adımdır. WordPress hata numarasını gizler; küçük bir PHP betiği ise MySQL'in ham cevabını olduğu gibi ekrana basar.

Kök dizine dbtest.php adında bir dosya oluşturun ve içine şunu yazın:

<?php
$host = 'localhost';
$user = 'kullanici_wpuser';
$pass = 'parola-buraya';
$db   = 'kullanici_wp01';

mysqli_report( MYSQLI_REPORT_OFF );
$link = @mysqli_connect( $host, $user, $pass, $db );

if ( ! $link ) {
    echo "BAGLANTI YOK\n";
    echo "Hata no : " . mysqli_connect_errno() . "\n";
    echo "Mesaj   : " . mysqli_connect_error() . "\n";
    exit;
}

echo "BAGLANTI TAMAM\n";
echo "Sunucu  : " . mysqli_get_server_info( $link ) . "\n";
$r = mysqli_query( $link, "SHOW TABLES" );
echo "Tablo   : " . mysqli_num_rows( $r ) . " adet\n";

Değerleri wp-config.php içindekilerle kopyala-yapıştır aynı yapın; elle yeniden yazarsanız test ettiğiniz şey artık gerçek yapılandırma olmaz. Sonra tarayıcıdan https://siteniz.com/dbtest.php adresini açın.

Alacağınız çıktı üç şeyden biridir:

• "BAGLANTI TAMAM" ve tablo sayısı geliyorsa bağlantı sağlıklıdır. Sorun wp-config.php'de değil, tablolarda veya PHP tarafında bir yerdedir; aşağıdaki onarım bölümüne geçin.
• "BAGLANTI YOK" ve bir hata numarası geliyorsa altın vuruş buradadır. Numarayı not edin, bir sonraki bölümdeki tabloda karşılığını bulun.
• Sayfa hiç açılmıyor, 500 hatası veriyorsa PHP tarafında ayrı bir sorun var demektir; önce sunucu hata kayıtlarına bakılmalıdır.

⚠️ Teşhis bittiğinde dbtest.php dosyasını mutlaka silin. İçinde veritabanı parolanız düz metin olarak durur ve bu dosyanın adresini tahmin etmek zor değildir.

MySQL Hata Numaralarını Doğru Okuma#

Betiğin verdiği numara, sorunun hangi halkada olduğunu tek başına söyler:

1045 ve 1044 dışındaki her numara, parolayla uğraşmayı bırakmanız gerektiğini söyler. 1045 ile 1044'ün ayrımı da önemlidir: birincisi kimlik doğrulama, ikincisi yetkilendirme hatasıdır. Birincisinde parolayı, ikincisinde cPanel'deki kullanıcı-veritabanı eşleşmesini düzeltirsiniz.

DB_HOST Her Zaman localhost Değildir#

Türkçe rehberlerin büyük kısmı "DB_HOST değerini localhost yapın" diye yazar. Bu, tek sunuculu klasik paylaşımlı hostingde doğrudur ama artık pek çok kurulumda yanlıştır. DB_HOST şu değerlerden biri olabilir:

• localhost — PHP ve MySQL aynı makinede, Unix soketi üzerinden bağlanır.
• 127.0.0.1 — aynı makine ama TCP üzerinden. Soket yolu bozulduğunda localhost çalışmaz, 127.0.0.1 çalışır. 2002 hatası alıyorsanız ilk denenecek şey budur.
• mysql.siteniz.com veya bir IP — veritabanı ayrı bir sunucuda. Kurumsal barındırma ve yük dengeli kurulumlarda standarttır.
• localhost:3307 veya 127.0.0.1:3307 — MySQL varsayılan dışında bir portta dinliyor.
• /var/lib/mysql/mysql.sock — soket yolu doğrudan verilmiş.

Uzak bir veritabanı sunucusu kullanıyorsanız, o sunucunun sizin web sunucunuzun IP'sinden gelen bağlantılara izin vermesi gerekir. cPanel'de bu ayar Uzak MySQL® ekranındadır ve web sunucusunun IP'si oraya eklenmemişse bağlantı 2003 ile reddedilir. Aynı ekranda % joker karakteri yerine tek tek IP tanımlamak da güvenlik açısından doğrusudur.

Siteyi yeni bir sunucuya taşıdıysanız ve eski wp-config.php dosyasını olduğu gibi kopyaladıysanız, DB_HOST değeri hâlâ eski sunucunun adresini gösteriyor olabilir. Taşıma sonrası bu hatanın en klasik sebebi budur.

Asıl Yaygın Neden: Bağlantı Limiti Aşımı#

Paylaşımlı hostingde bu hatanın en sık, en az anlaşılan ve kendiliğinden düzeldiği için yanlış teşhis edilen sebebi budur: hesabınızın eşzamanlı MySQL bağlantı limiti dolmuştur.

Belirtisi çok tipiktir: site bazen açılır, bazen bu hatayı verir. Sayfayı yenilediğinizde düzelir, on dakika sonra yine bozulur. Trafik arttığında, WooCommerce'de kampanya başladığında, bir bot siteyi taradığında ya da bir eklenti arka planda ağır sorgu attığında ortaya çıkar. Kimlik bilgileriyle hiçbir ilgisi yoktur — o yüzden wp-config.php ile uğraşan herkes çözemez.

Mekanizma şudur: barındırma sağlayıcıları bir hesabın MySQL'i tek başına tüketmesini engellemek için kullanıcı başına eşzamanlı bağlantı sınırı koyar (max_user_connections). Sınır dolduğunda yeni gelen her istek 1203 hatasıyla reddedilir; WordPress bunu "bağlantı kurulamadı" ekranına çevirir. Bağlantılar kapandıkça site kendiliğinden düzelir, sonra yine dolar.

Bunu doğrulamanın yolları:

1. Betiğin çıktısı: dbtest.php 1203 veya 1040 döndürüyorsa teşhis kesindir.
2. cPanel kaynak kullanımı: cPanel > Kaynak Kullanımı ekranındaki grafikte EP (eşzamanlı süreç) veya nproc sınırına takılma varsa aynı dönemde MySQL de zorlanıyordur. Aynı sıkışma, ziyaretçilere "508 Resource Limit Is Reached" ekranı olarak da yansıyabilir.
3. Zaman deseni: Hata her gün belirli saatlerde tekrar ediyorsa bir zamanlanmış görev (cron) veya yedekleme işi bağlantıları tüketiyordur.

Kalıcı çözüm, limiti yükseltmek değil bağlantı tüketimini düşürmektir:

• Nesne önbelleği kurun. Redis veya Memcached, tekrarlanan sorguları veritabanına hiç göndermez. redis object cache wordpress yazısındaki kurulum, ağır bir sitede MySQL bağlantı sayısını gözle görülür biçimde düşürür.
• Sayfa önbelleği açın. Önbellekten dönen bir sayfa tek bir veritabanı bağlantısı bile açmaz.
• wp-cron'u gerçek cron'a taşıyın. Yoğun trafikte her istekte tetiklenen wp-cron.php bağlantı havuzunu boşuna tüketir.
• Ağır eklentileri ayıklayın. İstatistik, ziyaretçi takibi ve "ilgili yazılar" eklentileri her sayfa yüklemesinde yazma sorgusu atar.
• wp_options tablosunu temizleyin. Şişmiş autoload verisi her istekte megabaytlarca satır çeker.

Bu önlemlerden sonra hâlâ limit doluyorsa sorun paket düzeyindedir: site paylaşımlı hostingin kaynak zarfını aşmıştır ve kendi MySQL örneğine sahip bir sunucuya geçmesi gerekir.

Veritabanı Kullanıcısının Yetkisi Düşmüş Olabilir#

Dün çalışan bir kullanıcı bugün 1044 dönüyorsa, birileri yetkileri değiştirmiştir. Bunun üç gerçek sebebi vardır:

• Hesap taşıma / geri yükleme. cPanel yedeğinden geri yükleme sırasında veritabanı ve kullanıcı geri gelir ama aralarındaki ilişki (grant) bazen gelmez.
• Yanlışlıkla kullanıcı silme. Panelde "kullanılmayan" sanılan bir MySQL kullanıcısının silinmesi, o kullanıcıyı kullanan siteyi anında düşürür.
• Kısıtlı yetkiyle oluşturma. Kullanıcıya sadece SELECT ve INSERT verilmişse site açılır ama güncelleme sırasında ALTER TABLE gerektiren işlem başarısız olur; bazı durumlarda WordPress bunu da bağlantı hatası gibi gösterir.

Kabuk erişiminiz varsa yetkiyi doğrudan sorabilirsiniz:

SHOW GRANTS FOR 'kullanici_wpuser'@'localhost';

Beklenen çıktı şuna benzer:

GRANT USAGE ON *.* TO `kullanici_wpuser`@`localhost`
GRANT ALL PRIVILEGES ON `kullanici_wp01`.* TO `kullanici_wpuser`@`localhost`

İkinci satır yoksa yetki verilmemiş demektir. cPanel'de MySQL® Veritabanları > Veritabanına Kullanıcı Ekle bölümünden kullanıcıyı seçip ALL PRIVILEGES kutusunu işaretlemek sorunu çözer. WHM erişiminiz varsa aynı işi SQL ile de yapabilirsiniz, ama paylaşımlı hostingde panel yolu daha güvenlidir çünkü hesap ön eklerini otomatik uygular.

Tablolar Bozuksa Onarım#

"Veritabanınız onarılmalı gibi görünüyor" mesajını gördüyseniz ya da ön yüz açılıp panel açılmıyorsa, bağlantı kuruluyor ama bir veya birkaç tablo bozulmuş demektir. Bu genellikle disk dolması, ani güç kesintisi veya MySQL'in düzgün kapanmaması sonucu olur.

wp-config.php dosyasının sonuna, /* That's all, stop editing! */ satırından önce şunu ekleyin:

define( 'WP_ALLOW_REPAIR', true );

Sonra tarayıcıdan şu adresi açın:

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

Bu sayfa oturum açmanızı istemez — bilinçli bir tasarım tercihidir, çünkü panele giremediğiniz için oradasınız. Tam da bu yüzden işiniz bitince satırı hemen silin; açık bırakılan bu tanım, herhangi birinin veritabanınıza onarım/optimizasyon çalıştırmasına izin verir.

"Veritabanını Onar" düğmesi yeterli olmazsa phpMyAdmin üzerinden tablo bazında onarım yapabilirsiniz. Tabloları seçip alttaki menüden Tabloyu onar komutunu çalıştırmak, InnoDB dışındaki tablolarda çoğu zaman işe yarar. Yöntemin ayrıntısı için mysql veritabanı onarma ve phpmyadmin kullanımı yazılarına bakın. Onarım hiçbir şey düzeltmiyorsa yedekten geri dönmek en hızlı çözümdür; bu yüzden her sitede günlük otomatik yedek olmalıdır.

Sıkça Sorulan Sorular#

Veritabanı bağlantısı kurulurken hata oluştu mesajı sitemi kalıcı olarak sildi mi#

Hayır, bu mesaj veri kaybı anlamına gelmez. Hata yalnızca WordPress'in veritabanına o an ulaşamadığını söyler; yazılarınız, ayarlarınız ve medya dosyalarınız yerinde durur. Bağlantı sorunu giderildiği anda site hiçbir şey kaybetmeden geri gelir. Gerçek veri kaybı yalnızca veritabanının silinmesi (1049 hatası) veya tabloların onarılamayacak kadar bozulması durumunda söz konusudur; her iki durumda da yedekten geri dönüş çözümdür.

Hata bazen çıkıp bazen kaybolması ne anlama gelir#

Kesintili çıkan bu hata neredeyse her zaman bağlantı limiti aşımıdır. Kimlik bilgileri yanlış olsaydı hata istisnasız her istekte çıkardı; aralıklı olması, MySQL'in bazı istekleri kabul edip bazılarını reddettiğini gösterir. Bu da max_user_connections sınırına takıldığınız, sunucu genelinde too many connections yaşandığı veya sunucunun anlık olarak aşırı yüklendiği anlamına gelir. Önbellekleme ve ağır eklentilerin ayıklanmasıyla başlayın; devam ediyorsa paketin kaynak zarfı yetersizdir.

wp-config.php içindeki parolayı değiştirdim ama hata devam ediyor#

Parolayı yalnızca dosyada değiştirmek yetmez, MySQL tarafında da aynı parolanın tanımlı olması gerekir. Doğru sıra şudur: önce cPanel'in MySQL Veritabanları ekranından kullanıcının parolasını yenileyin, üretilen parolayı kopyalayın, sonra aynı değeri wp-config.php içine yapıştırın. Ayrıca dosyayı düzenleyen editörün akıllı tırnak eklemediğinden ve satır sonunda boşluk bırakmadığından emin olun. Değişiklikten sonra hata numarası hâlâ 1045 ise parola gerçekten eşleşmiyordur; 1044'e dönüştüyse parola tamam, yetki eksiktir.

Sitem yeni sunucuya taşındıktan sonra bu hatayı vermeye başladı#

Taşıma sonrası bu hatanın sebebi hemen her zaman eski wp-config.php dosyasının olduğu gibi kopyalanmasıdır. Yeni sunucuda veritabanı adı, kullanıcı adı ve çoğu zaman DB_HOST değeri farklıdır; hesap ön ekleri de değişir. Yeni sunucunun panelinden veritabanı ve kullanıcı bilgilerini alıp dört tanımı da güncelleyin. Veritabanı ayrı bir sunucudaysa DB_HOST alanına o sunucunun adresini yazmayı ve uzak erişim izninde web sunucusunun IP'sini tanımlamayı unutmayın.

Bağlantı testi betiği çalışıyor ama WordPress hâlâ hata veriyor#

Bu durum, sorunun kimlik bilgilerinde olmadığını kesinleştirir ve dikkati üç yere kaydırır. Birincisi, wp-config.php içinde başka bir yerde eski bir DB_HOST veya DB_NAME tanımı tekrar edilmiş olabilir; dosyanın tamamını arayın. İkincisi, tablo öneki ($table_prefix) yanlıştır ve WordPress var olmayan tabloları arıyordur. Üçüncüsü, tablolar bozuktur ve WP_ALLOW_REPAIR ile onarım gerekir. Betik bağlanıp tablo sayısını sıfır gösteriyorsa veritabanı gerçekten boştur, yedekten geri yükleme gerekir.

MySQL servisi durmuşsa bunu nasıl anlarım#

En net işaret, test betiğinin 2002 veya 2003 hata numarası döndürmesidir. Paylaşımlı hostingde bunu doğrulamanın pratik yolu, aynı sunucudaki başka bir sitenizin de aynı anda hata vermesidir; tek site etkileniyorsa servis ayaktadır, sorun hesap düzeyindedir. VDS veya sunucu yönetimi sizdeyse systemctl status mysql (veya mariadb) komutu servisin durumunu, journalctl -u mysql -n 50 komutu ise son hata satırlarını gösterir. Servis disk dolduğu için durmuşsa df -h çıktısında %100 dolu bir bölüm görürsünüz ve önce yer açmanız gerekir.

Bu hatayı önlemek için ne yapabilirim#

Kalıcı önlem üç başlıkta toplanır: yedek, önbellek ve izleme. Günlük otomatik veritabanı yedeği, en kötü senaryoda kaybınızı bir güne indirir. Sayfa ve nesne önbelleği, MySQL'e giden istek sayısını ciddi biçimde azaltarak limit aşımını en baştan engeller. Son olarak sitenin ayakta olup olmadığını dışarıdan kontrol eden bir izleme, bu hatayı müşteriden önce sizin görmenizi sağlar. Ayrıca wp-config.php dosyasının yedeğini ayrı bir yerde tutmak, panikle yapılan bir düzenlemeden geri dönmeyi kolaylaştırır.

Kapanış#

"Veritabanı bağlantısı kurulurken hata oluştu" ekranı, tek bir sebebi olan bir hata değil; dört farklı katmandan gelebilen bir semptomdur. Doğru yaklaşım, wp-config.php içindeki parolayı defalarca değiştirmek yerine bağlantıyı WordPress'ten bağımsız test edip MySQL'in verdiği hata numarasını okumaktır. 1045 kimlik, 1044 yetki, 1049 eksik veritabanı, 2002/2003 erişim, 1040/1203 ise kapasite sorununu gösterir. Numarayı bildiğinizde çözüm birkaç dakikalık bir iştir; bilmediğinizde saatlerce yanlış yerde ararsınız. Aralıklı çıkan hatalarda ise şüpheyi doğrudan bağlantı limitine ve kaynak tüketimine yöneltin — deneyimde en sık çıkan sebep budur.

Bu tür kesintileri sürekli yaşıyorsanız çoğu zaman sorun WordPress'te değil, sitenin büyüdüğü ama paketin büyümediği gerçeğindedir. Nesne önbelleği ve düzenli yedekle gelen WordPress hosting paketlerimiz orta ölçekli siteler için yeterli olur; ziyaretçi sayısı ve eşzamanlı sipariş yükü arttıysa kendi kaynakları ayrılmış bir VDS sunucu MySQL'i komşu sitelerin etkisinden tamamen kurtarır. Kesinti anında geri dönebileceğiniz bir noktanız yoksa yedekleme hizmetimiz bu boşluğu kapatır; sunucu tarafındaki MySQL ayarları ve izleme işini kendiniz üstlenmek istemiyorsanız da sunucu yönetimi paketi bu bakımı devralır.