WordPress Veritabanı Bağlantı Hatası: Nedenleri ve Çözüm Rehberi

23 Nisan 2026 WPNeta No comments yet

WordPress Veritabanı Bağlantı Hatası çözüm rehberi kapak görseli

Özet: “Error establishing a database connection” — Türkçesiyle WordPress veritabanı bağlantı hatası — sitenizin veritabanıyla konuşamadığını gösteren en kritik hatalardan biridir. Genelde hatalı wp-config.php ayarları, MySQL/MariaDB servisinin durması, bozulmuş tablolar veya hostingte kaynak yetersizliği gibi nedenlerden kaynaklanır. Bu rehberde hatanın nedenlerini, adım adım tanı yöntemlerini, wp-config.php, WP_ALLOW_REPAIR, WP-CLI ve SSH ile çözüm yollarını, ayrıca tekrar yaşamamak için alabileceğiniz önlemleri bulacaksınız.

WordPress Veritabanı Bağlantı Hatası Nedir?

WordPress, içerikleri, kullanıcıları, yorumları, ayarları ve eklenti verilerini bir MySQL (ya da MariaDB) veritabanında tutar. Her sayfa isteğinde WordPress, wp-config.php dosyasındaki kimlik bilgilerini kullanarak veritabanına bağlanır ve sorgular çalıştırır. Bu bağlantı herhangi bir nedenle kurulamazsa tarayıcıda yalnızca şu beyaz ekran ve mesaj görünür:

Error establishing a database connection

Türkçe temalarda bu mesaj “Veritabanı bağlantısı kurulurken bir hata oluştu” şeklinde de görünebilir. Önemli olan nokta şudur: Bu hata çoğu zaman WordPress’in kendisiyle değil, veritabanı sunucusuyla iletişim katmanıyla ilgilidir. Yani yalnızca PHP hatası gibi basit bir sorun değildir; bazen hosting altyapısına ait bir problem habercisidir.

Neden bu kadar kritik?

Veritabanı bağlantı hatası yaşandığında ziyaretçiler siteyi hiçbir şekilde göremez, yönetim paneline (wp-admin) bile giremezsiniz. Durum uzun sürerse arama motorları sayfalarınızı tekrar tekrar erişilemez bulur, bu da organik trafikte ve sıralamalarda kalıcı kayıplara yol açabilir. Özellikle WooCommerce gibi e-ticaret sitelerinde doğrudan gelir kaybı anlamına gelir.

Hatanın En Sık Nedenleri

Pratikte karşılaşılan kök nedenler genellikle şu başlıklar altında toplanır:

Yanlış veritabanı kimlik bilgileri: wp-config.php içinde yanlış DB_NAME, DB_USER, DB_PASSWORD veya DB_HOST değerleri.
Veritabanı sunucusunun çökmesi: MySQL/MariaDB servisinin durması, crash etmesi ya da yeniden başlatılmaması.
Paylaşımlı hostingte kaynak sınırı aşımı: Aynı anda açılan bağlantı sayısının (max_connections) ya da CPU/RAM kotasının dolması.
Bozuk veritabanı tabloları: Beklenmedik kapanmalardan sonra özellikle wp_options, wp_posts gibi kritik tabloların çökmesi.
Sunucu IP veya host değişikliği: Taşıma işleminden sonra DB_HOST değerinin güncellenmemesi (örneğin localhost yerine farklı bir IP olması gerektiği halde değiştirilmemesi).
Kötü amaçlı yazılım veya saldırı: wp-config.php dosyasının değiştirilmesi ya da veritabanı kullanıcısının yetkilerinin iptal edilmesi.
Disk alanı dolu: Hosting diskinin %100 dolması MySQL’in yazma yapamamasına ve bağlantıyı reddetmesine yol açar.
Eski PHP sürümü veya uyumsuz MySQL sürücüsü: PHP’nin mysqli veya pdo_mysql modüllerinin yüklü olmaması.

Doğru çözüme ulaşmak için yukarıdaki listeyi bir kontrol listesi gibi kullanıp teker teker elemek en hızlı yoldur.

Paniklemeden İlk 5 Dakikada Yapılacaklar

Hatayı gördüğünüzde panik yapıp hemen dosyalara müdahale etmeyin. Önce aşağıdaki basit kontrolleri yapın:

Siteyi farklı bir tarayıcıda, gizli sekmede veya başka bir cihazda açmayı deneyin. Bazı durumlarda sorun önbellek kaynaklı olabilir.
Hostinginizin durum sayfasına (status page) ya da destek panosuna bakın. Geniş çaplı bir kesinti varsa zaten bekleyerek çözülür.
wp-admin paneline girmeyi deneyin: https://siteniz.com/wp-admin. Bazen yönetim paneli farklı bir mesaj verir — örneğin “One or more database tables are unavailable” — bu bize bozuk tablo olduğunu söyler.
Son 24 saatte sitede bir güncelleme, tema/eklenti kurulumu, sunucu taşıma veya şifre değişikliği yaşandı mı, not edin. Çözüm çoğu zaman bu son değişikliğin içinde gizlidir.
Varsa son yedeği belirleyin. Henüz hiçbir dosyayı değiştirmeyin, çünkü önce mevcut durumun bir kopyasını almak gerekir.

Adım 1: wp-config.php Dosyasını Doğrulayın

Neredeyse hataların yarısı wp-config.php dosyasındaki yanlış bilgilerden kaynaklanır. FTP/SFTP veya hosting dosya yöneticisi ile sitenin kök dizinine girip bu dosyayı açın. Aşağıdaki dört satır doğru olmalıdır:

define( 'DB_NAME',     'veritabani_adi' );
define( 'DB_USER',     'veritabani_kullanicisi' );
define( 'DB_PASSWORD', 'guclu_sifre' );
define( 'DB_HOST',     'localhost' );

Kontrol edilecek noktalar

Tırnak işaretleri: Değerler tek tırnak içinde olmalı. Akıllı tırnaklar (‘ ’) yerine düz tırnak (') kullanıldığından emin olun.
Boşluklar: Değerlerin başında veya sonunda görünmeyen boşluk/satır sonu olmamalı. Kopyalama yaparken oluşabilir.
Dil ve karakter: Şifrede &, #, ', \\ gibi özel karakterler varsa bunlar doğru kaçırılmalı veya tercihen şifre baştan oluşturulup yalnızca harf/rakam kullanılmalı.
DB_HOST: Çoğu ortamda localhost yeterlidir. Ancak hosting firmaları bazen mysql.siteniz.com, bir IP adresi ya da özel port (localhost:3307, db1.host.com:3306) verir. Hosting panelindeki değerle birebir aynı olmalıdır.
Tablo öneki: $table_prefix = 'wp_'; satırı veritabanındaki tabloların başlangıç ekiyle aynı olmalı. Elle bir göç yaptıysanız burada uyumsuzluk çıkabilir.

Güvenli düzenleme pratiği

Dosyayı değiştirmeden önce mutlaka yedek alın:

# SSH ile:
cp wp-config.php wp-config.php.bak-$(date +%Y%m%d)

Değişikliği yaptıktan sonra siteyi yeniden yükleyin. Eğer hata kaybolduysa sebep çözülmüş demektir. Kaybolmadıysa sıradaki adıma geçin.

Adım 2: Veritabanı Kimlik Bilgilerini Gerçekten Test Edin

wp-config.php görünüşte doğru olabilir ama veritabanı tarafında kullanıcı silinmiş, şifre değişmiş ya da yetkiler kaldırılmış olabilir. En hızlı doğrulama yöntemi kök dizine geçici bir test betiği koymaktır:

<?php
// test-db.php — test sonrası MUTLAKA silin
$link = @mysqli_connect('localhost', 'kullanici', 'sifre', 'veritabani');
if ($link) {
    echo 'Baglanti BASARILI. MySQL: ' . mysqli_get_server_info($link);
} else {
    echo 'BAGLANTI HATASI: ' . mysqli_connect_error();
}

Bu dosyayı tarayıcıda açın: https://siteniz.com/test-db.php. Aldığınız mesaj size net bilgi verir:

Access denied for user: Kullanıcı adı veya şifre yanlış.
Unknown database: Veritabanı adı yanlış.
Can’t connect to MySQL server on ‘localhost’: MySQL servisi ayakta değil veya host yanlış.
Too many connections: Kaynak sınırı dolu.

Önemli: Test bittikten sonra test-db.php dosyasını mutlaka silin. İçinde açık şifreniz olduğu için güvenlik açığıdır.

phpMyAdmin ile doğrulama

Hosting panelinizde phpMyAdmin varsa, wp-config.php‘deki kullanıcı/şifre ile giriş yapmayı deneyin. Giriş yapamıyorsanız sorun kimlik bilgilerinde, yapabiliyorsanız sorun PHP katmanında veya host/IP ayarındadır.

Adım 3: MySQL/MariaDB Servisinin Durumunu Kontrol Edin

Kimlik bilgileri doğru, ama yine de bağlantı kurulamıyorsa büyük ihtimalle veritabanı servisi çalışmıyordur. Bunun kontrolü erişim türünüze göre değişir:

cPanel / Plesk kullanıcıları

Çoğu paylaşımlı hostingte MySQL servisine doğrudan erişim olmaz. Burada yapılabilecek en mantıklı şey, hosting desteğine e-posta/ticket açıp şu mesajı göndermektir:

“Sitemde ‘Error establishing a database connection’ hatası alıyorum. wp-config.php bilgilerini kendi kullanıcımla test ettim, bağlantı reddediliyor. MySQL sunucumun ayakta olup olmadığını ve kullanıcı yetkilerinin geçerli olduğunu kontrol edebilir misiniz?“

VPS / Dedicated sunucu kullanıcıları

SSH erişiminiz varsa servis durumunu doğrudan kontrol edebilirsiniz:

# Servisin durumu
sudo systemctl status mysql
# veya MariaDB için:
sudo systemctl status mariadb

# Yeniden başlatma (dikkatli kullanın)
sudo systemctl restart mysql

# Portun dinlenip dinlenmediği
sudo ss -tlnp | grep 3306

MySQL açık ama yine bağlanılamıyorsa mysql -u root -p komutu ile yerel bağlantıyı test edin. Açılabiliyorsa sorun kullanıcı yetkilerinde, açılamıyorsa servis yapılandırmasındadır.

Bellek yetersizliği (OOM) nedeniyle düşen MySQL

Küçük VPS’lerde en yaygın senaryo, PHP-FPM veya arka plan işlerinin RAM’i doldurması ve Linux kernelinin MySQL sürecini OOM-killer ile öldürmesidir:

sudo dmesg | grep -i "killed process"
sudo journalctl -u mysql --since "1 hour ago"

Bu çıktılarda Out of memory: Kill process veya Killed process ... mysqld satırı görüyorsanız sorun net: Sunucuya bir swap alanı ekleyin ya da MySQL’in innodb_buffer_pool_size değerini düşürün.

Adım 4: Veritabanını Tamir Edin (WP_ALLOW_REPAIR)

Tablo seviyesinde bozulmalar, özellikle wp_options veya wp_posts çöktüğünde bağlantı kurulsa da WordPress tarafından “database not reachable” olarak raporlanır. WordPress’in kendi yerleşik onarım aracı bunun için birebirdir.

wp-config.php dosyasına /* That's all, stop editing! */ satırının ÜSTÜNE şu satırı ekleyin:

define( 'WP_ALLOW_REPAIR', true );

Ardından tarayıcıdan şu URL’yi açın:

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

Karşınıza iki seçenek çıkar:

Repair Database: Bozuk tabloları otomatik olarak düzeltir.
Repair and Optimize Database: Tamir eder ve ardından optimize işlemiyle tabloları sıkıştırır.

İşlem bittikten sonra WP_ALLOW_REPAIR satırını MUTLAKA kaldırın. Aksi halde bu URL login gerektirmediği için herkese açık kalır ve güvenlik açığı oluşturur.

Komut satırından tamir — mysqlcheck

SSH erişimi olanlar için daha güçlü bir yöntem:

# Tek veritabanını tamir et
mysqlcheck -u kullanici -p --auto-repair --optimize veritabani_adi

# Tüm veritabanlarını tara
mysqlcheck -u root -p --auto-repair --all-databases

Bu komut MyISAM tabloları için güvenilirdir; InnoDB tablolarında ise tam tamir için MySQL’i innodb_force_recovery modunda açmak gerekebilir. Burası artık hosting desteğine ya da deneyimli bir sistem yöneticisine danışmanız gereken alandır.

Adım 5: Yedekten Geri Yükleme

Tüm denemelere rağmen sorun çözülmediyse, özellikle saldırı şüphesi varsa, en temiz yol son sağlıklı yedekten geri yüklemedir. İyi bir geri yükleme planı şu adımları içerir:

Mevcut dosyaları ve veritabanını “kirli” olsalar bile kenara yedekleyin. Saldırı inceleme için gerekecektir.
Son sağlıklı olduğunu bildiğiniz dosya yedeğini (/wp-content, temalar, eklentiler) ve veritabanı dump’ını yükleyin.
Geri yükleme sonrası siteye girer girmez tüm kullanıcı şifrelerini sıfırlayın, wp-config.php içindeki AUTH_KEY ve diğer tuzları WordPress.org salt generator ile yenileyin.
Tüm eklenti ve tema sürümlerini güncel olanlarla değiştirin — eski yedekten gelen sürümlerde zaten yamanmış zafiyetler olabilir.

Eğer bu hatayla karşılaşan sitede düzenli yedek yoksa, bu olay size düzenli yedekleme planının değerini hatırlatan bir uyarı olarak kalsın. İleride “Düzenli Yedekleme Stratejisi” bölümünü mutlaka uygulayın.

Adım 6: Kaynak ve Bağlantı Limitlerini Kontrol Edin

Sitenizin trafiği arttıkça ya da kötü yazılmış eklentiler yüzünden veritabanı sorguları çoğaldıkça “Too many connections” hatası sık görülür. Bu, teknik olarak “Error establishing a database connection” ile aynı mesajı üretir.

MySQL tarafında mevcut bağlantıları görmek

SHOW STATUS LIKE 'Threads_connected';
SHOW STATUS LIKE 'Max_used_connections';
SHOW VARIABLES LIKE 'max_connections';

Threads_connected değeri max_connections‘a sık sık yaklaşıyorsa:

Agresif cache (sayfa ve nesne cache) kurun: örneğin Redis/Memcached + WP Super Cache/LiteSpeed Cache.
Kötü yazılmış eklentileri Query Monitor gibi bir araçla tespit edip kaldırın.
Hosting paketinizi, max_connections, CPU ve RAM limitlerinizi yükseltin.
Aynı sunucuda çok sayıda WordPress çalışıyorsa bunları farklı veritabanı kullanıcılarına dağıtıp yüklerini ayırın.

Disk dolu mu?

df -h
du -sh /var/lib/mysql

Kök disk %100’e ulaştıysa MySQL yazma yapamaz. Log dosyalarını (/var/log/), eski yedekleri, kullanılmayan imajları temizleyin ve kalıcı bir log rotasyonu kurun.

Adım 7: WP-CLI ile Hızlı Tanı

WP-CLI erişimi olan sunucularda veritabanı durumu saniyeler içinde anlaşılır. Kök dizinde şu komutları çalıştırın:

# Bağlantıyı test et
wp db check

# Sorunlu tabloları onarmayı dene
wp db repair

# wp-config.php içindeki sabitleri doğrula
wp config list --fields=name,value

# Temel veritabanı bilgileri
wp db size --tables

WP-CLI’nin vereceği hata çıktıları, WordPress’in gördüğü hatayla birebirdir ve genellikle “Access denied”, “Unknown database”, “Can’t connect” gibi net mesajlar içerir. Bu mesaj, üst adımdaki hangi kutuya gireceğinizi söyler.

Adım 8: Güvenlik Perspektifinden Kontrol

Hata bir anda ve belirgin bir sebep olmadan ortaya çıktıysa — güncelleme yok, trafik pikinde değil, hostingten açıklama yok — kötü niyetli bir saldırıyı eleyin. Site sahibinin güvenliği artırmak için yapması gerekenler:

wp-config.php bütünlüğü: Dosyanın değişiklik tarihine bakın. Beklenmeyen bir tarihte değişmişse saldırıyı gösterir.
Dosya izinleri: wp-config.php için 640 veya 600, dizinler için 755, diğer dosyalar için 644 idealdir.
Güçlü şifreler ve 2FA: Tüm admin, FTP ve veritabanı kullanıcı şifrelerini yenileyin; yönetici hesaplarına iki aşamalı doğrulama (2FA) ekleyin.
Güvenlik tarayıcıları: Wordfence, Sucuri ya da iThemes Security eklentilerinden birini kurup tam tarama çalıştırın. Bu eklentiler wp-config.php ve wp-includes gibi çekirdek dosyaların bütünlüğünü de kontrol eder.
Error log incelemesi: wp-content/debug.log, /var/log/nginx/error.log, /var/log/mysql/error.log içinde son birkaç saate ait anormal satırları okuyun.

wp-config.php’yi sertleştirme

Doğru ayarlar veritabanı bağlantısına dayalı sorunların oluşma şansını ciddi biçimde azaltır:

// Dosya düzenlemeyi kapat
define( 'DISALLOW_FILE_EDIT', true );

// Dosya yüklemeyi kapat (acil durumlar için kullanışlı)
define( 'DISALLOW_FILE_MODS', true );

// Hata ayıklamayı üretimde logla, ekrana yazdırma
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );

// Çöp kutusu sıklığı
define( 'EMPTY_TRASH_DAYS', 7 );

// Revizyonları sınırla
define( 'WP_POST_REVISIONS', 10 );

Bu sabitler, hem güvenlik katmanı ekler hem de veritabanına giden gereksiz yazmaları azaltır.

Sık Karşılaşılan Durumlar ve Hızlı Çözümler

Durum 1: Ön yüz bağlanamıyor ama wp-admin çalışıyor

WordPress, bazı tablolar çökse bile yönetim paneline “sınırlı” modda girmeye izin verebilir. Bu durumda panele girip Araçlar > Site Sağlığı’ndan bakın veya WP_ALLOW_REPAIR adımını uygulayın.

Durum 2: Taşımadan sonra hata başladı

Büyük ihtimalle yeni sunucuda DB_HOST veya DB_USER farklıdır. Yeni hostinginizin verdiği bilgilerle wp-config.php‘yi güncelleyin. Ayrıca yeni veritabanına eski dump’ı yüklerken charset (utf8mb4) ve collation ayarlarının korunduğundan emin olun.

Durum 3: Site periyodik olarak hata veriyor

Saatlik aralıklarla bu hata görünüp kayboluyorsa sorun sabit bir kimlik/erişim değil, kaynak darboğazıdır. Cache ekleyin, Query Monitor ile sorguları izleyin, hosting planını büyütün.

Durum 4: WooCommerce mağazası kapandı

E-ticaret sitelerinde sipariş tabloları (wp_wc_orders, wp_woocommerce_order_items) çok yazma alır. İlk olarak bu tabloları onarın:

mysqlcheck -u kullanici -p --auto-repair wc_db wp_wc_orders wp_woocommerce_order_items

Ardından ürün ve sipariş sayfalarını test edin. Gerekiyorsa WooCommerce > Durum > Araçlar menüsünden “Ürün aramayı yeniden oluştur” ve “Vergi oranlarını yenile” gibi bakım aksiyonlarını çalıştırın.

Sorun Giderme Checklist

Aşağıdaki listeyi sırayla uygularsanız 9 vakanın 10’unda sorun çözülür:

wp-config.php dosyasında DB_NAME, DB_USER, DB_PASSWORD, DB_HOST değerleri doğru mu?
Kimlik bilgilerini phpMyAdmin veya geçici test-db.php ile doğruladınız mı?
Hosting firmasının durum sayfasında planlı bakım / kesinti yok mu?
MySQL/MariaDB servisi çalışıyor mu? (systemctl status mysql)
Sunucu diskinde doluluk var mı? (df -h)
RAM/OOM kaynaklı servis çökmesi var mı? (dmesg, journalctl)
max_connections dolmuş mu, kötü sorgu üreten eklenti var mı?
WP_ALLOW_REPAIR ile tablo onarımı denendi mi?
WP-CLI ile wp db check çalıştırıldı mı?
Son yedeğe güvenli bir şekilde dönme planı hazır mı?
wp-config.php’deki tuzlar yenilendi, tüm şifreler sıfırlandı mı?
Wordfence veya Sucuri ile tam tarama yapıldı mı?

Tekrar Yaşamamak İçin Uzun Vadeli Önlemler

Düzenli yedekleme stratejisi

En az üç katmanlı bir yedek planı kurun: sunucuda günlük yedek, hostingin haftalık yedeği ve üçüncü bir tarafta (BunnyCDN, Amazon S3, Backblaze, Google Drive) aylık arşiv. UpdraftPlus, WP Staging, BlogVault gibi eklentiler bu işi otomatikleştirir. Restore sürecini yılda en az bir kez canlı olmayan bir ortamda test edin — “yedek aldım” değil, “yedeği geri yükleyebiliyorum” olmalı önemli olan.

İzleme ve uyarı

Site dakikada bir kontrol edilsin. UptimeRobot, BetterUptime, Pingdom gibi servisler 1-5 dakikalık kontrollerle HTTP 500 ya da veritabanı hatasını e-posta/Telegram/Slack ile anında bildirir. Böylece ziyaretçi fark etmeden siz müdahale edersiniz.

Güncelleme disiplini

WordPress çekirdek, tema ve eklenti güncellemelerini bir staging ortamında deneyip sonra canlıya taşımak bağlantı hatası riskini minimize eder. Otomatik güncellemeleri açarken kritik eklentileri manuel tutun; beklenmedik bir şema değişikliği veritabanını bozabilir.

Performans ve cache

Page cache + object cache + CDN üçlüsü veritabanı yükünü %80-90 azaltır. Object cache için Redis ya da Memcached şiddetle tavsiye edilir; Object Cache Pro veya Redis Object Cache eklentileri kolay kurulum sağlar.

Doğru hosting seçimi

Sık sık “Error establishing a database connection” yaşıyorsanız sorun çoğu zaman sizinle değil, paketinizledir. İyi bir WordPress odaklı hosting sağlayıcısı LiteSpeed/Nginx + PHP-FPM + ayrılmış MySQL sunucusu ile gelir, max_connections‘ı şeffaf paylaşır ve 7/24 destek sunar. WPNeta’nın WordPress için en uygun hosting seçimi rehberimizdeki kriterleri kullanın.

Sıkça Sorulan Sorular (SSS)

1. “Error establishing a database connection” hatasını görmek sitemin hacklendiği anlamına mı gelir?

Hayır, mutlaka değil. Çoğu zaman sebep yanlış wp-config.php, düşen MySQL servisi ya da kaynak yetersizliğidir. Ancak dosya değiştirme tarihlerinde ya da error log’da şüpheli iz varsa güvenlik taraması şart.

2. wp-config.php’yi düzenlerken nelere dikkat etmeliyim?

Önce yedek alın, akıllı tırnak yerine düz tırnak kullanın, dosyayı UTF-8 (BOM’suz) olarak kaydedin. Şifre özel karakter içeriyorsa değeri çift tırnak içine alıp kaçış karakterleriyle yazın ya da daha iyisi sadece harf ve rakamdan oluşan yeni bir şifre oluşturun.

3. WP_ALLOW_REPAIR güvenli mi?

Geçici olarak güvenlidir, ancak onarım bittikten sonra bu satırı mutlaka silmeniz gerekir. Aksi halde /wp-admin/maint/repair.php URL’si login gerektirmeden herkese açık kalır.

4. Şifremi hatırlamıyorum, nasıl sıfırlarım?

Hosting panelinde MySQL Kullanıcıları bölümünden şifreyi sıfırlayabilirsiniz. Ardından yeni şifreyi wp-config.php‘ye yazın. Şifrede özel karakter kullanmamaya özen gösterin.

5. Kendi sunucumu yönetiyorum, MySQL yerine MariaDB’ye geçmeli miyim?

Modern WordPress sürümleri her ikisiyle de uyumludur. MariaDB genellikle daha açık, daha hızlı geliştirilen bir alternatiftir. Ancak geçiş yaparken mysqldump ile dikkatli bir dump-restore süreci uygulayın ve charset’i utf8mb4 tutun.

6. Hostingim paylaşımlı ve SSH yok, şans var mı?

Var. Çoğu paylaşımlı pakette cPanel / Plesk üzerinden phpMyAdmin, Dosya Yöneticisi ve MySQL Kullanıcı ekranına erişebilirsiniz. Bu yazıdaki WP-CLI ve SSH adımlarını atlayıp phpMyAdmin + hosting destek bileti kombinasyonuyla devam edin.

7. Cache ve CDN bu sorunu yaşatmamı engeller mi?

Tek başına engellemez ama ciddi anlamda azaltır. Sayfa cache ile MySQL’e giden sorgu sayısı %70-80 düşer; object cache ile tekrarlanan sorgular Redis/Memcached’den dönerek veritabanını yormaz. Her iki cache katmanını da kullanmak en iyisidir.

8. Error log’da “MySQL server has gone away” görüyorum, bu aynı sorun mu?

Yakın akraba bir hatadır. Genellikle uzun süren bir sorgu wait_timeout‘u aşıyor ya da max_allowed_packet sınırının üstünde bir veri gönderiliyor. MySQL konfigürasyonunda bu değerleri yükseltmek ve büyük sorguları parçalamak çözümdür.

Kaynak Önerileri

Sonuç

WordPress veritabanı bağlantı hatası ilk bakışta korkutucu görünür ama büyük çoğunlukla sistematik bir yaklaşımla 15-30 dakika içinde çözülür. wp-config.php kontrolü, kimlik bilgilerinin doğrulanması, MySQL servisinin ayakta olması, WP_ALLOW_REPAIR ile tablo onarımı ve son çare olarak temiz bir yedekten dönüş — bu dört basamak neredeyse tüm senaryoları kapsar. Önemli olan paniğe kapılmadan, önce veriyi (mevcut durumu) yedeklemek, ardından nedeni izole edip adım adım elemektir.

Bu hatayı bir daha yaşamak istemiyorsanız, en büyük yatırım düzenli yedekleme ve izlemeye yapılacak olandır. Yedekten geri yükleme senaryosunu test edilmiş bir sitenin 4 saatlik bir kesinti ile kurtulduğu bir olayla, yedeği olmayan ve günlerce kapalı kalan bir olay arasındaki fark tamamen bu iki disiplindir.