MySQL bağlantı hatası, bir uygulamanın veritabanı sunucusuna beklenen biçimde bağlanamadığını gösterir. Sebep yanlış parola, hatalı host, durmuş servis, ağ engeli, bağlantı sınırı veya yapılandırma önbelleği olabilir. WordPress’teki “Error establishing a database connection” ekranı da benzer bir soruna işaret eder; fakat tek bir hata mesajı kesin nedeni söylemez. Önce belirtileri, hata kodunu ve son değişikliği kaydedin. Bu rehberde güvenli tanı sırasını, WordPress ve genel PHP uygulamalarındaki kontrolleri, sık hata türlerini ve tekrarını önleme adımlarını anlatıyoruz.
MySQL bağlantı hatası ne anlama gelir?
Tarayıcı uygulamaya istek gönderir; uygulama veritabanından içerik veya ayar okumak ister. Bu bağlantı kurulamazsa uygulama sayfayı oluşturamayabilir. Bazı hatalarda sunucuya hiç ulaşılamaz; bazılarında sunucuya ulaşılır ama kimlik doğrulama reddedilir. Bu iki durumun çözümleri farklıdır. WordPress’in genel hata ekranı detayları ziyaretçiye göstermeyebilir. Yönetim paneli de açılmıyorsa sorunu çözmek için hosting paneli, günlükler veya yetkili sunucu erişimi gerekir.
Bir yazının yüklenmemesi her zaman veritabanı arızası değildir. PHP kritik hatası, önbellek bozulması veya CDN kesintisi farklı belirtiler verebilir. Ana sayfa çalışıp yönetim paneli hata veriyorsa ve yalnızca belirli sorgularda sorun varsa kapsamı not edin. Hatanın ilk görüldüğü saat, son eklenti güncellemesi, hosting taşıması veya parola rotasyonu tanıda yararlıdır. Bu bilgiler olmadan rastgele veritabanı onarım komutu çalıştırmak gereksiz risk yaratır.
Önce hata türünü ayırın
Access denied genellikle bağlantı sunucusuna ulaşıldığını ancak kimlik doğrulama veya host yetkisinin reddedildiğini gösterir. Connection refused istenen host ve portta hizmetin dinlemediğini ya da erişimin reddedildiğini gösterebilir. Connection timed out ağ veya sunucu yanıt gecikmesine işaret edebilir. Too many connections mevcut bağlantı sınırının dolduğu durumu belirtir. Unknown database veritabanı adının yanlış veya yok olduğunu düşündürür. Tam hata metni, kodu ve zaman damgası olmadan yalnızca yüzey belirtisiyle karar vermeyin.
Veri güvenliği: başlamadan önce
Çalışan ya da kısmen çalışan üretim veritabanında işlem yapmadan önce güncel yedek ve geri yükleme yolunu doğrulayın. Hata günlüklerini okurken parola, erişim anahtarı ve kişisel verileri herkese açık destek başlığında paylaşmayın. Veritabanını silmek, yeniden oluşturmak veya geniş yetkili yeni kullanıcı vermek ilk tanı adımı değildir. Sorunu çözmek için gereken en az değişikliği yapın. Yetkisiz erişiminiz yoksa hosting sağlayıcısından bağlantı durumu ve doğru host bilgisini doğrulamasını isteyin.
Adım 1: kapsamı ve son değişikliği belirleyin
Sorun yalnızca bir WordPress sitesinde mi, aynı sunucudaki bütün sitelerde mi? Veritabanı yönetim aracına erişiliyor mu? Uygulama logu hangi kodu veriyor? Bu sorular uygulama ayarı ile veritabanı hizmeti arasındaki farkı ortaya çıkarır. Az önce wp-config.php, .env, kullanıcı parolası veya DNS değiştiyse bunun saatini kaydedin. Yedek geri yükleme, sunucu yeniden başlatma veya hosting taşıma sırasında da bağlantı kesilebilir. Tanıya gözlemle başlamak, yanlış katmanı değiştirmenin önüne geçer.
Kesinti aralıklıysa sürekli hata ile aynı nedenleri varsaymayın. Yük altında bağlantı havuzu dolabilir, kısa süreli ağ kopması yaşanabilir veya veritabanı sunucusu yeniden başlıyor olabilir. Belirtiyi birkaç zaman noktasında ve farklı sayfalarda doğrulayın. Sağlayıcının durum sayfası veya yönetim panelinde hizmet kesintisi varsa bunu kaydedin. Ziyaretçiye görünen ekranın fotoğrafı tanı için yararlı olsa da yapılandırma dosyası ve şifre görüntüsü paylaşmayın.
Adım 2: veritabanı host ve portunu kontrol edin
Uygulamadaki DB_HOST veya eşdeğer alan, gerçek MySQL sunucusunu göstermelidir. Bazı hosting paketlerinde localhost doğrudur, bazılarında ayrı sunucu adı veya port gerekir. localhost ve 127.0.0.1 bazı sistemlerde soket ile TCP gibi farklı bağlantı yolları kullanabilir. Sağlayıcının verdiği bilgiyi esas alın. Sunucuya erişebiliyorsanız yetkili ağ araçlarıyla host çözümlemesini ve porta bağlantıyı test edin. Dışarıdan portu açmak sorunu çözmek için otomatik bir adım değildir; güvenlik sınırını genişletir.
Adım 3: veritabanı servisinin durumuna bakın
MySQL veya MariaDB hizmeti durmuşsa uygulama doğru parola kullansa bile bağlanamaz. Yönetilen hosting’de servis durumunu panelden veya destek ekibinden öğrenin. Kendi sunucunuzda günlük ve hizmet durumunu inceleyin. Yeniden başlatma kısa süreli çözüm gibi görünebilir, ancak servis disk doluluğu, bellek sınırı veya bozuk yapılandırma nedeniyle tekrar duruyorsa kök nedeni bulmak gerekir. Sunucu logundaki ilk hata, uygulama tarafındaki son hata mesajından daha açıklayıcı olabilir.
Adım 4: kimlik bilgilerini güvenli biçimde doğrulayın
Uygulamanın kullandığı veritabanı adı, kullanıcı adı, parola ve host değerlerini sağlayıcının kayıtlarıyla karşılaştırın. Parolayı ekran görüntüsünde veya destek mesajında yazmayın. Aynı kullanıcıyla yetkili sunucudan bağlantı denemesi yapılabilir; fakat kimlik bilgisini komut satırı geçmişine kaydedecek biçimde paylaşmayın. MySQL hesapları kullanıcı ve bağlandığı host birleşimine göre kontrol edilebilir. “Access denied” hatasında yalnızca parolayı değil, hesabın izin verilen istemci hostunu ve hesabın kilit durumunu da inceleyin.
Adım 5: yetkiyi veritabanı düzeyinde inceleyin
Bağlantı kuruluyor ama belirli veritabanına erişim reddediliyorsa kullanıcı yetkisi veya veritabanı adı sorunlu olabilir. MySQL hata kodları 1044 ve 1045 gibi farklı reddetme nedenlerini ayırt etmeye yardım eder. Üretim uygulamasına bütün sunucuda sınırsız yetki vermek hızlı ama riskli bir çözüm olabilir. Gereken veritabanı ve işlemler için uygun izinleri tanımlayın. Hosting paneli kullanıcıyı veritabanına ekleme adımı istiyorsa o eşlemenin varlığını kontrol edin.
WordPress’te wp-config.php kontrolü
WordPress’in veritabanı bağlantı bilgileri genellikle wp-config.php dosyasında tanımlanır. DB_NAME, DB_USER, DB_PASSWORD ve DB_HOST değerlerinin gerçek hosting bilgileriyle eşleştiğini denetleyin. Dosyayı indirip herkese açık klasöre kopyalamayın. Düzenleme öncesi yedek alın ve yalnızca gerekli satırı değiştirin. Sözdizimi hatası eklenirse site farklı bir PHP hatası verebilir. WordPress’in resmî “Common Errors” belgesi yanlış yapılandırma bilgisi ve hosting sorunlarını başlıca nedenler arasında sayar.
Parolayı yeni değiştirdiyseniz WordPress dosyası eski parolayı kullanıyor olabilir. Aynı veritabanını kullanan başka uygulamalar da varsa parola rotasyonu onların bağlantısını kesebilir. Tek uygulamayı düzeltip diğerlerini unutmayın. Sunucuda çevresel değişken veya özel yapılandırma katmanı varsa gerçek değerin nereden yüklendiğini belirleyin. Dosyayı doğru düzenleyip hâlâ eski davranışı görüyorsanız önbellek, dağıtım sürümü veya yanlış sunucuya bağlanma olasılığını inceleyin.
PHP uygulamalarında .env ve config önbelleği
Laravel gibi çerçevelerde bağlantı ayarları çevre değişkenlerinden okunabilir ve yapılandırma önbelleğine alınabilir. .env dosyasını değiştirmek çalışan uygulamanın ayarı hemen yenilediği anlamına gelmez. Kullandığınız çerçevenin resmî belgelerindeki önbellek yenileme yolunu izleyin. Canlıda önbelleği silmek başka ayarları da etkileyebilir; önce staging ve dağıtım yöntemini doğrulayın. Yalnızca “veritabanı hatası” deyip her PHP projesine WordPress adımlarını uygulamayın. Hata mesajı, uygulama ve sunucu günlükleri birlikte okunmalıdır.
Too many connections hatası
MySQL’in resmî belgesine göre bu hata, izin verilen bağlantıların başka istemcilerce kullanımda olduğu durumu gösterir. max_connections değerini yükseltmek mümkün olabilir, ancak önce bağlantıları neden tükettiğinizi ölçün. Uygulamada açık bırakılan bağlantılar, yavaş sorgular, trafik sıçraması veya çok sayıda işçi süreci etkili olabilir. Sunucu kaynakları yetersizse sınırı körlemesine yükseltmek bellek baskısı yaratır. Yetkili yönetici süreç listesini ve ilgili metrikleri incelemelidir. Sorun tekrar ediyorsa kapasite ve uygulama davranışı birlikte iyileştirilmelidir.
Timeout ve kesintili ağ sorunu
Bağlantı zaman aşımı sunucunun yanıt vermediğini gösterebilir; güvenlik duvarı, DNS, ağ yolu, sunucu yükü veya uzak veritabanı gecikmesi etkili olabilir. Uygulama ile veritabanı aynı sunucuda mı, ayrı ağda mı öğrenin. Yakın zamanda IP veya güvenlik kuralı değiştiyse bağlantı yolunu test edin. Sadece zaman aşımı süresini artırmak kök nedeni gizleyebilir ve ziyaretçilerin daha uzun beklemesine yol açabilir. Ağ ve sunucu metriklerini aynı zaman damgasıyla karşılaştırın.
Disk doluluğu ve sunucu kaynakları
Veritabanı sunucusunun diski dolmuşsa yazma işlemleri başarısız olabilir ve hizmet kararsızlaşabilir. Bellek ve CPU baskısı da bağlantı gecikmesini artırabilir. Sunucudaki boş alanı, hata günlüklerini ve kaynak eğilimini inceleyin. Eski yedekleri veya rastgele dosyaları tanı amaçlı silmeyin; önce nelerin güvenle kaldırılabileceğini belirleyin. Yönetilen hosting’de sağlayıcıdan kapasite raporu isteyin. Kısa süreli yeniden başlatma sonrası çalışan site, kök neden giderilmezse yeniden kesilebilir.
Tablo bozulması ile bağlantı hatasını karıştırmayın
Veritabanı bağlantısı hiç kurulamıyorsa tablo onarımı doğru ilk adım değildir. Bağlantı kurulduktan sonra belirli tablo okumasında bozulma hatası görülüyorsa ayrı onarım gerekebilir. WordPress belgelerinde tablo onarımı bazı durumlar için anlatılır, ancak hangi tablo ve depolama motorunun etkilendiği belirlenmelidir. Onarım ve değişiklikten önce güncel yedek alın. Çok büyük veya kritik veritabanında işlemi bakım penceresinde ve uzman desteğiyle yapın. Rastgele “repair database” komutunu her hata ekranına uygulamak veri riskini artırır.
MySQL ile MariaDB farkı tanıda önemli mi?
WordPress her ikisiyle de çalışabilir; bağlantı hatalarının genel sınıfları benzer olsa da sürüm, yapılandırma, hata kodu ve yönetim seçenekleri farklılaşabilir. Hosting panelinden gerçek sunucu yazılımını ve sürümünü öğrenin. İnternetteki bir MySQL sürümüne ait komutu MariaDB’de denemeden önce kendi ürün belgesini kontrol edin. Bu rehber genel tanı akışını verir; üretimde uygulanacak SQL komutları ve yapılandırma değişiklikleri ortamınızın belgeleriyle doğrulanmalıdır.
Bağlantı düzeldikten sonra test
Ana sayfanın açılması tek başına yeterli değildir. Oturum açmayı, bir yazıyı okumayı, yönetim paneline erişimi ve kontrollü yazma işlemini test edin. WooCommerce veya form sistemi varsa sipariş ve kayıt akışını dikkatle doğrulayın; gerçek ücretli işlem oluşturmamak için uygun test düzeni kullanın. Hata günlüğünde yeni bağlantı uyarısı var mı bakın. Önbellek eski sayfayı gösterebilir, bu yüzden canlı veritabanı okuma gerektiren bir sayfayı kontrol edin. Kesinti sırasında oluşan başarısız sipariş veya iş kuyruğu görevlerini ayrıca inceleyin.
Tekrarlayan hatalar nasıl önlenir?
Bağlantı sayısı, veritabanı yanıt süresi, disk kullanımı ve hata oranını izleyin. Kimlik bilgisi rotasyonunu uygulama dağıtımıyla koordineli yapın. Yavaş sorguları gözden geçirin, gereksiz sürekli bağlantıları azaltın ve kapasite sınırına yaklaşmadan uyarı üretin. Otomatik yedekle birlikte geri yükleme denemesi planlayın. Eklenti veya uygulama güncellemesinin beklenmedik bağlantı açıp açmadığını staging testinde ölçün. Tekrar eden “Too many connections” hatasını her seferinde servis yeniden başlatarak geçiştirmek kalıcı çözüm değildir.
Örnek olay 1: parola değişiminden sonra hata
Hosting panelinde veritabanı parolası değiştiriliyor. Birkaç dakika sonra WordPress bağlantı ekranı gösteriyor. İlk kontrol, veritabanı hizmetinin çalıştığı ve kullanıcı hesabının var olduğu. Ardından wp-config.php içindeki parola ile paneldeki yeni değer karşılaştırılıyor. Uygulama dosyası güncellenip sözdizimi doğrulanıyor. Site geri geliyor. Bu olayda veritabanını yeniden oluşturmak veya dosyaları silmek gerekmezdi. Eşzamanlı başka uygulamalar varsa onların bağlantıları da kontrol edilir.
Örnek olay 2: trafik zirvesinde kesinti
Site sabah saatlerinde aralıklı olarak hata veriyor; gece sorunsuz. Günlükte Too many connections görülüyor. Yönetici bağlantı sayısı, PHP işçi sayısı ve yavaş sorguları karşılaştırıyor. Bir eklentinin her sayfa görüntülemede ağır sorgu çalıştırdığı bulunuyor. Eklenti sorgusu düzeltilip önbellek düzenleniyor; kapasite sınırı kaynaklara göre yeniden değerlendiriliyor. Bu olayda parola değiştirmek sorunu çözmezdi. Hata kodunun tanıdaki değeri tam da burada görülür.
Örnek olay 3: hosting taşıması
Site yeni sunucuya kopyalanmış, dosyalar açılıyor ama veritabanına bağlanmıyor. Eski sunucunun DB_HOST değeri yapılandırmada kalmış olabilir. Yeni sağlayıcının host ve portu, veritabanı kullanıcı yetkileri, güvenlik duvarı ve DNS kontrol edilir. Taşımadan önceki yedek saklanır. Bağlantı düzeldikten sonra URL, medya, oturum ve yazma işlemleri test edilir. Sadece ana sayfanın önbellekte görünmesi göçün tamamlandığını kanıtlamaz.
Yayın sonrası olay kaydı oluşturun
Hata çözüldüğünde yalnızca “site çalışıyor” notu bırakmayın. Başlangıç ve bitiş saati, gerçek kök neden, yapılan tekil değişiklikler, geri alınan denemeler ve etkilenen kullanıcı işlemlerini kaydedin. Bir eklenti güncellemesi bağlantı yükünü artırdıysa sonraki sürüm için test senaryosu hazırlayın. Parola rotasyonu eşzamanlı yapılmadıysa dağıtım kontrol listesine bu adımı ekleyin. İzleme uyarısı geç geldiyse eşik ve bildirim sahipliğini düzeltin.
Veri tabanı kesintileri bazen önbellek yüzünden geç fark edilir. Ön yüzde önbellekte kalan sayfalar açılırken yönetim paneli veya ödeme akışı bozulabilir. Bu yüzden sağlık kontrolü yalnızca statik ana sayfaya istek atmakla sınırlı olmamalıdır. Güvenli, kimlik doğrulaması gerektirmeyen bir okuma sinyali ve sunucu metrikleri birlikte değerlendirilebilir. Kontrol mekanizması da veritabanına aşırı sorgu yükü bindirmemelidir.
Birden fazla sunuculu kurulumda uygulamanın hangi veritabanı uç noktasına bağlandığını, yük devretmenin gerçekleşip gerçekleşmediğini ve okuma-yazma rollerini ayrıca doğrulayın. Bu senaryo basit hosting hesabından farklıdır; yerel bakım runbook’unu kullanın.
Destek ekibine hangi bilgileri iletmeli?
Hatanın başladığı saat ve saat dilimini, etkilenen alan adını, görülen tam hata kodunu, sorunun sürekli mi aralıklı mı olduğunu, son yapılan değişikliği ve kontrol ettiğiniz servis durumunu paylaşın. Parola, tam wp-config.php dosyası veya kişisel kullanıcı verisini açık destek talebine yapıştırmayın. Sağlayıcı erişim doğrulaması isterse kendi güvenli kanalını kullanın. İyi bir destek talebi “sitem bozuk” yerine gözlemi ve kapsamı içerir; müdahale süresini kısaltır.
Sık sorulan sorular
WordPress “veritabanı bağlantı hatası” veriyorsa içerikler silindi mi?
Genellikle hayır; bağlantı kurulamaması içeriklerin silindiği anlamına gelmez. Fakat gerçek veri durumu yedek ve veritabanı kontrolüyle doğrulanmalıdır. Panik içinde yeniden kurulum yapmayın.
wp-config.php parolasını değiştirmek yeterli mi?
Hata gerçekten eski parola nedeniyleyse yeterli olabilir. Sunucu çalışmıyor, host yanlış veya bağlantı sınırı doluysa parolayı değiştirmek çözüm değildir. Önce hata türünü belirleyin.
localhost yerine 127.0.0.1 yazmalı mıyım?
Rastgele değiştirmeyin. Bağlantı yöntemi ve doğru host hosting altyapısına göre değişir. Sağlayıcının verdiği değeri ve hata günlüklerini esas alın.
Too many connections için sınırı artırmalı mıyım?
Sınırı artırmak bazı durumlarda kapasite çözümünün parçasıdır, ancak bağlantı tüketiminin nedeni ve sunucu belleği ölçülmeden tek adım olarak uygulanmamalıdır.
Sonuç: güvenli çözüm sırası
Önce hata metni ve kapsamı kaydedin. Ardından host, hizmet durumu, kimlik bilgileri, yetki ve kapasiteyi bu sırayla değil, gördüğünüz hata kodunun işaret ettiği önceliğe göre kontrol edin. Yedek ve erişim güvenliğini koruyun. Düzeltmeden sonra okuma, yazma ve kritik iş akışlarını deneyin. Tekrarlayan kesintide günlük ve metrikleri kullanarak kök nedeni bulun.
Kaynaklar ve ileri okuma
