WordPress Veritabanı Bağlantı Hatası; Sorun Gidermeden Bozuk Tablo Onarımına

Veritabanı Bağlantı Hatası; WordPress Aniden Erişilemez Olduğunda

Siteniz beş dakika öncesine kadar çalışıyordu. Şimdi ana sayfa yerine renksiz ve beyaz bir cümle görüyorsunuz: Error establishing a database connection. Ziyaretçiler de aynen bunu görüyor. Ne 404 sayfası, ne 500 hatası, ne de "yakında döneceğiz" diyen bir sayfa. Sadece bu cümle.

Bu hata, WordPress'in MySQL'e erişemediği anlamına gelir. Veritabanının kesinlikle bozulduğu anlamına gelmez. On vakadan sekizinde sorun başka bir yerdedir. Olasılık sırasına göre beş gerçek nedene bakalım.

İlk Test: MySQL Servisi Gerçekten Çalışıyor mu?

SSH ile sunucuya giriş yapın ve şu komutu çalıştırın:

systemctl status mysql

Servis devre dışıysa, durumu kontrol edin:

systemctl start mysql
systemctl enable mysql

İşte burada hata yapıyorlar: Birçok kişi sunucuyu yeniden başlattıktan sonra MySQL servisini tekrar etkinleştirmiyor. enable komutunu çalıştırmıyorlar ve bir sonraki sunucu yeniden başlatılana kadar site çalışıyor. Yeniden başlatmanın ardından hata geri geliyor. Servis çalışıyorsa ancak hata devam ediyorsa, logu kontrol edin:

tail -50 /var/log/mysql/error.log

Out of memory veya Too many connections ifadelerini arayın. Her ikisinin de net bir anlamı vardır: Sunucunun RAM'i yetersiz veya eşzamanlı bağlantı sayısı izin verilen sınırı aşmış.

Kısa Bir Script ile Bağlantı Testi

wp-config.php dosyasını kurcalamadan önce doğrudan bir test yapın. Sitenin kök dizininde db-test.php adında bir dosya oluşturun:

<?php
$conn = @new mysqli('localhost', 'DB_USER', 'DB_PASSWORD', 'DB_NAME');
if ($conn->connect_error) {
    die('Connection failed: ' . $conn->connect_error);
}
echo 'Connected successfully';
$conn->close();
?>

DB_USER, DB_PASSWORD ve DB_NAME değerlerini wp-config.php dosyasından alın. Şimdi tarayıcıdan https://yourdomain.com/db-test.php adresine gidin.

İki durum ortaya çıkar. Connected successfully mesajını görürseniz, bağlantı kurulmuş demektir ve sorun başka bir yerdedir. Access denied for user hatası görürseniz, kullanıcı adı veya şifre yanlış demektir. Bu en basit durumdur ve çözümü de basittir: Şifreyi düzeltin.

Ancak Unknown database hatası görürseniz, veritabanı mevcut değil demektir. Bu durum genellikle site taşıma veya yedekten geri yükleme sonrasında ortaya çıkar. wp-config.php dosyasını açın ve veritabanı adını dikkatlice kontrol edin. Fazladan bir boşluk veya büyük/küçük harf farkı bile bu hatayı verir.

Sorun wp-config.php'de mi, Yoksa MySQL'in Kendisinde mi?

Test scriptini çalıştırdınız, artık sorunun nerede olduğunu biliyorsunuz. Script ile bağlantı kurulduysa ancak WordPress hala hata veriyorsa, üç ihtimal kalıyor.

1. wp-config.php İçinde Tekrarlanan Tanımlar

Bazı önbellek veya güvenlik eklentileri, veritabanı tanımlarını wp-config.php dosyasına ekler. Dosyada iki kez define('DB_NAME', ...) varsa, PHP yalnızca ilkini okur. Dosyayı açın ve tekrarlanan tanımları arayın. Fazla olanları silin.

2. Veritabanı Sunucusu (Host) Yanlış

DB_HOST değeri genellikle localhost'tur. Ancak bazı barındırma servisleri ayrı bir adres kullanır. Siteyi bir hosting'den diğerine taşıdıysanız, bu değeri kontrol edin. Yeni adresi yeni hosting panelinden alın. ServerNet dokümantasyon ve bilgi tabanında her hosting türü için varsayılan değerler tablosunu hazırladık.

3. Veritabanı Tabloları Bozulmuş

Herkesin korktuğu durum budur. Test scripti bağlantı kurduysa ve wp-config.php de sağlamsa, tabloların bozulma ihtimali artar. WordPress, wp_options tablosuna erişemediğinde aynı hatayı gösterir. Başka bir hata değil, daha fazla açıklama değil. Sadece bu cümle.

Bozuk Tablo Onarımı; Sitenin Hayatını Kurtaran Komut

MySQL'in yerleşik onarım aracı vardır. SSH ile giriş yapın ve şu komutu çalıştırın:

mysqlcheck -u root -p --auto-repair --optimize --all-databases

Bu komut tüm veritabanlarını kontrol eder, bozuk tabloları onarır ve sağlam tabloları optimize eder. Yalnızca WordPress veritabanını istiyorsanız:

mysqlcheck -u root -p --auto-repair your_database_name

Çıktıyı okuyun. Bir tablo Table is marked as crashed hatasıyla karşılaşırsa, sorun oradadır. Yukarıdaki komut genellikle onu onarır. Onarılmazsa, yedek kullanmanız gerekir. İşte burada hata yapıyorlar: Bazıları onarımdan sonra siteyi kontrol etmiyor ve işin bittiğini sanıyor. Onarılan tablo tekrar bozulabilir. 24 saat içinde hata tekrar gelirse, sorun donanımsaldır ve diski kontrol etmelisiniz.

Bu Hata Neden Aniden Ortaya Çıkıyor?

Veritabanı bağlantı hatası genellikle kademeli değil, aniden ortaya çıkar. Üç yaygın senaryoya bakalım:

• Sunucunun ani yeniden başlatılması: Sunucu yüksek RAM kullanımı nedeniyle yeniden başlatılırsa, MySQL düzgün başlamayabilir. /var/log/syslog logunda Out of memory ifadesini arayın.
• Diskin dolması: Disk dolduğunda MySQL yazamaz ve bağlantıyı keser. df -h ile boş alanı kontrol edin. %5'in altındaysa, sorun buradadır.
• Saldırı veya anormal trafik: Eşzamanlı bağlantı sayısı max_connections değerini aşarsa, MySQL yeni bağlantıları reddeder. Mevcut değeri şu komutla görün:

mysql -u root -p -e "SHOW VARIABLES LIKE 'max_connections';"

Varsayılan değer genellikle 151'dir. Siteniz gerçekten daha fazlasına ihtiyaç duyuyorsa, değeri /etc/mysql/mysql.conf.d/mysqld.cnf dosyasında değiştirmelisiniz. Ancak önce sorunun bağlantı sayısından değil, ağır sorgulardan kaynaklanmadığından emin olun.

Her Şey Doğruyken Hata Devam Ediyorsa

Servisin çalıştığı, test scriptinin bağlantı kurduğu, wp-config.php'nin sağlam olduğu ve tabloların onarıldığı bir durumu düşünün. Ancak hata hala var. Bu durum nadirdir ancak olur.

Suçlu genellikle önbellektir. WordPress veya önbellek eklentisi, önceki hatanın sonucunu bellekte tutmuştur. Önbelleği temizleyin. Redis veya Memcached kullanıyorsanız, servisi yeniden başlatın:

systemctl restart redis-server
systemctl restart memcached

Hata hala devam ediyorsa, DNS'i kontrol edin. Bazen siteniz sunucuda doğru çalışır ancak ziyaretçi başka bir sunucuya yönlendirilir. dig yourdomain.com ile IP adresini görün ve kendi sunucunuzun IP'siyle karşılaştırın. Yeni başlayanlar için DNS yapılandırma rehberini bu yazıda okuyun.

Önleme; Şimdi Yapmanız Gereken Şey

Bu hatayı deneyimlediniz ve tekrarlanmasını istemiyorsunuz. Üç şey yapın:

1. Otomatik veritabanı yedeği: Yedeğiniz yoksa, şimdi oluşturun. Haftaya değil, şimdi. Her gece veritabanından yedek alan basit bir cron job yeterlidir.
2. Otomatik izleme: Kullanıcıların sitenin erişilemez olduğunu söylemesini beklemeyin. Sitenizi her 5 dakikada bir kontrol eden ve hata görürse size e-posta gönderen bir uptime izleme servisi kurun. Site uptime izleme pratik rehberini bu yazıda okuyun.
3. Hata dokümantasyonunu saklayın: Bu hatayı her çözdüğünüzde, nedeni ve çözümü not edin. Bir dahaki sefere on dakika daha erken çözersiniz.

Sunucunuzun kaynakları yetersizse ve bu hatayla sık sık karşılaşıyorsanız, belki de yükseltme zamanı gelmiştir. ServerNet WordPress hosting, özel kaynaklar ve otomatik izleme ile bu tür hataları kökten çözer. Ancak herhangi bir işlem yapmadan önce, bu makaledeki testleri çalıştırın. On vakadan sekizinde sorun basit bir komutla çözülür.

Sıkça Sorulan Sorular

Error establishing a database connection hatası ne anlama gelir?

WordPress'in MySQL veritabanına bağlanamadığı anlamına gelir. Bu hata genellikle verilerin kaybolduğu anlamına gelmez, WordPress ile MySQL arasındaki bağlantının koptuğunun bir göstergesidir. Neden, servisin kapalı olması, yanlış şifre veya bozuk tablo olabilir.

WordPress veritabanı bağlantı hatasını SSH erişimi olmadan nasıl çözerim?

SSH erişiminiz yoksa, hosting yönetim panelini kullanın. cPanel veya DirectAdmin gibi çoğu panelde MySQL'i Yeniden Başlat seçeneği vardır. Yoksa, hosting desteğiyle iletişime geçin ve MySQL servisini yeniden başlatmalarını isteyin. Ardından site önbelleğini temizleyin.

Veritabanı tablosunun bozulması veri kaybına neden olur mu?

Hayır. Bozuk tablo, verilerin kaybolduğu anlamına gelmez. mysqlcheck --auto-repair komutu genellikle tabloyu veri kaybı olmadan onarır. Yalnızca diskin hasar gördüğü nadir durumlarda veri kaybı olabilir. Bu nedenle düzenli yedekleme şarttır.

Siteyi yeni hosting'e taşıdıktan sonra neden bu hata ortaya çıkıyor?

Genellikle wp-config.php dosyasındaki bir hatadan kaynaklanır. Veritabanı adı, kullanıcı adı veya şifre yeni hosting'de farklıdır. DB_HOST değeri de değişmiş olabilir. wp-config.php dosyasını yeni hosting değerleriyle güncelleyin ve emin değilseniz, yeni hosting desteğinden tam değerleri isteyin.