MySQL Error 2002 (111) Bağlantı Reddedildi Hatası: TCP Dinleme ve Erişim Çözümü

MySQL Error 2002 bağlantı hatası, istemcinin MySQL veya MariaDB sunucusuna TCP üzerinden ulaşamadığını gösterir. Özellikle Can't connect to MySQL server on 'sunucu-adresi' (111) veya Connection refused mesajı, hedef IP ve portta bağlantının aktif olarak reddedildiği anlamına gelir. Sorun; veritabanı servisinin çalışmaması, sunucunun 3306 portunu dinlememesi, yanlış bind-address ayarı, güvenlik duvarı ya da SELinux kuralı olabilir. Bu rehber, Linux sistemlerde hatayı servis yeniden başlatma gibi kör müdahaleler yerine ölçülebilir kontrollerle ayırmayı ve güvenli biçimde gidermeyi açıklar.

Belirti, kapsam ve hata kodunun anlamı

Hata genellikle bir uygulama, uzak yönetim istemcisi veya komut satırı istemcisiyle bağlantı kurarken görülür:

ERROR 2002 (HY000): Can't connect to MySQL server on '192.0.2.10' (111)

Linux’ta (111), çoğunlukla Connection refused karşılığıdır. Ağ paketi hedefe ulaşmış olabilir; ancak hedef sistemde ilgili port dinlenmiyor veya bir güvenlik bileşeni bağlantıyı açıkça reddediyordur. Bu durum, kullanıcı adı/parola veya yetki sorununu ifade eden ERROR 1045 ile aynı değildir.

Bu makale uzak TCP bağlantısına odaklanır. Hata metninde localhost ve bir .sock dosyası geçiyorsa, istemci TCP yerine Unix socket kullanıyor olabilir. Önce bağlantı türünü ayırmak gerekir.

MySQL Error 2002 bağlantı hatası için hızlı teşhis özeti

Kontrol	Beklenen bulgu	Olası sonuç
Servis durumu	active (running)	Servis kapalıysa 2002 oluşabilir.
3306 dinleme	Doğru IP’de LISTEN	Yalnızca 127.0.0.1 dinleniyorsa uzak erişim çalışmaz.
Yerel TCP testi	127.0.0.1 ile bağlantı	Başarısızsa sorun sunucu servisinde veya TCP yapılandırmasındadır.
Uzak port testi	TCP 3306 erişilebilir	Başarısızsa firewall, ağ ACL’i veya yanlış hedef incelenir.
Güvenlik günlükleri	Engellemeye dair kayıt yok	SELinux veya güvenlik duvarı politikası müdahale ediyor olabilir.

Komutları veritabanı sunucusunda, sudo yetkisi olan bir kullanıcıyla yürütün. Üretim sisteminde yapılandırma değişikliği veya servis yeniden başlatma öncesinde bakım penceresi planlayın. Çalışan oturumları ve kısa süreli sorgular kesilebilir; değişiklikten önce yapılandırma dosyasının yedeğini alın.

Olası nedenler

• MySQL ya da MariaDB servisi durmuş, başlatılamamış veya çökme sonrası kapalı kalmıştır.
• Sunucu 3306 portunu hiç dinlemiyordur; servis başlatma hatası günlüklerde görülebilir.
• bind-address yalnızca 127.0.0.1 veya ::1 ile sınırlandırılmıştır. Bu, yerel erişim için güvenli olabilir; uzak bağlantı ihtiyacında planlı biçimde değiştirilmelidir.
• İstemci yanlış IP, DNS kaydı, port veya IPv6/IPv4 hedefi kullanıyordur.
• Sunucu güvenlik duvarı, bulut güvenlik grubu veya veri merkezi ağ kuralı 3306/TCP trafiğini engelliyordur.
• SELinux etkin sistemlerde web sunucusu süreci gibi kısıtlı bir alanın veritabanına ağ üzerinden erişmesine izin verilmiyordur.
• Uygulama localhost ile socket bağlantısı beklerken, socket dosyası yolu istemci ve sunucu arasında farklı yapılandırılmıştır.

Log ve teşhis komutları

1. Doğru servis birimini ve çalışma durumunu bulun

Dağıtıma göre birim adı mysql, mysqld veya mariadb olabilir. Önce hangisinin sistemde bulunduğunu tespit edin:

systemctl list-unit-files --type=service | grep -E '^(mysql|mysqld|mariadb)\.service'
systemctl --no-pager --full status mysql
systemctl --no-pager --full status mysqld
systemctl --no-pager --full status mariadb

Bulduğunuz etkin birim için son günlükleri inceleyin. Örnekte mariadb yerine kendi birim adınızı yazın:

sudo journalctl -u mariadb -n 100 --no-pager
sudo journalctl -u mariadb -b --no-pager

Disk doluluğu, izin hatası, InnoDB kurtarma mesajı veya başka bir sürecin portu kullanması gibi bulguları çözmeden servisi tekrar tekrar başlatmayın.

2. Sunucunun hangi adres ve portta dinlediğini doğrulayın

sudo ss -ltnp | grep ':3306'
sudo ss -ltnp | grep -E ':(3306|33060)\b'

127.0.0.1:3306 sadece aynı makinedeki IPv4 istemcilerini kabul eder. [::1]:3306 IPv6 loopback ile sınırlıdır. Sunucunun özel ağ IP’sinde veya tüm uygun arayüzlerde dinleme, uzak istemcinin erişebilmesi için gereklidir. Her arayüzde dinleme anlamına gelebilen 0.0.0.0:3306 ayarını internet erişimli sistemlerde gereksiz yere kullanmayın.

3. Socket ve TCP davranışını birbirinden ayırın

Aşağıdaki testte 127.0.0.1 kullanımı TCP’yi zorlar. Kullanıcı adını kendi yetkili veritabanı hesabınızla değiştirin; parola komut geçmişine yazılmamalıdır.

mysql -h 127.0.0.1 -P 3306 -u kullanici_adi -p -e 'SELECT 1;'
mysql -h localhost -u kullanici_adi -p -e 'SELECT 1;'

İlk komut başarılı, ikinci komut başarısızsa servis çalışıyor olabilir; sorun socket dosyası veya localhost bağlantı tercihidir. İlk komut dahi reddediliyorsa dinleme ve servis günlüklerine dönün. Uzak bir Linux istemcisinden, önce kimlik bilgisi göndermeden port erişimini test edebilirsiniz:

nc -vz -w 5 veritabani-sunucusu.example 3306

nc kurulu değilse dağıtımınızın paket yöneticisiyle yüklemek yerine mevcut ağ izleme araçlarını ve firewall günlüklerini kullanmak da mümkündür. Test sonucunu tek başına kesin kanıt olarak değerlendirmeyin; ağ cihazları farklı davranış gösterebilir.

Güvenli adım adım çözüm

1. Servis kapalıysa nedeni inceleyip kontrollü başlatın

Günlüklerde yapılandırma veya veri diziniyle ilgili kritik hata yoksa, doğru servis birimini başlatın ve durumunu tekrar kontrol edin:

sudo systemctl start mariadb
sudo systemctl --no-pager --full status mariadb
sudo journalctl -u mariadb -n 50 --no-pager

Buradaki mariadb örnektir; sisteminizde tespit ettiğiniz birim adını kullanın. Başlatma hatasında veri dosyalarını silmek, başlangıçta innodb_force_recovery eklemek veya InnoDB tablolarına REPAIR TABLE çalıştırmak bu bağlantı hatası için uygun ilk müdahale değildir. Günlükte InnoDB hasarı belirtileri varsa yazma işlemlerini durdurun, yedeği doğrulayın ve ayrı bir veri kurtarma planı uygulayın.

2. bind-address ayarını yalnızca gerekli ağ için düzenleyin

Etkin yapılandırma dosyasının yolu dağıtıma ve kurulum yöntemine göre değişir. Yaygın yapılandırma konumlarında ilgili satırları arayın:

sudo grep -RInE '^\s*(bind-address|port|skip-networking)\b' \
  /etc/mysql /etc/my.cnf /etc/my.cnf.d 2>/dev/null

skip-networking etkinse TCP bağlantıları kapalıdır. bind-address ise hangi IP’lerde dinleneceğini belirler. Değişiklikten önce dosyayı tarih ekleyerek yedekleyin:

sudo cp -a /etkin/yapilandirma/dosyasi.cnf \
  /etkin/yapilandirma/dosyasi.cnf.$(date +%F-%H%M%S).bak

Yerel ağdan erişim gerekiyorsa mümkünse sunucunun yalnızca özel ağ IP’sini kullanın. Değişiklikten sonra bakım penceresinde servisi yeniden başlatın ve ss çıktısını tekrar inceleyin:

sudo systemctl restart mariadb
sudo ss -ltnp | grep ':3306'

3. Güvenlik duvarını kaynak IP ile sınırlandırın

3306 portunu herkese açmak yerine yalnızca uygulama veya yönetim sunucularının sabit IP’lerine izin verin. Önce kullanılan güvenlik duvarını tespit edin:

sudo ufw status verbose
sudo firewall-cmd --state 2>/dev/null
sudo nft list ruleset

UFW kullanılan Ubuntu sistemlerinde, örneğin yalnızca belirli bir kaynak IP için kural şu biçimdedir:

sudo ufw allow from 198.51.100.25 to any port 3306 proto tcp

Firewalld kullanılan RHEL ailesinde kalıcı bir kural için:

sudo firewall-cmd --permanent --add-rich-rule='rule family="ipv4" source address="198.51.100.25" port port="3306" protocol="tcp" accept'
sudo firewall-cmd --reload

IP adreslerini örnek değerlerle bırakmayın. Ayrıca bulut sağlayıcısındaki güvenlik grubu, ağ ACL’i veya kurum güvenlik duvarı da ayrı bir engel katmanı olabilir.

4. SELinux engelini kanıtla, sonra en dar izni verin

SELinux çoğunlukla RHEL tabanlı sistemlerde görülür. Durumu ve yakın tarihli erişim reddi kayıtlarını kontrol edin:

getenforce
sudo ausearch -m AVC -ts recent

Bir web uygulamasının başka bir sunucudaki MySQL’e erişmesi engellenmiş ve AVC kayıtları bunu doğruluyorsa, HTTPD alanı için ilgili boolean değerlendirilebilir:

sudo setsebool -P httpd_can_network_connect_db on

Bu değişiklik kalıcıdır. Yalnızca erişen süreç HTTPD tabanlıysa ve günlük kaydı gerçekten SELinux engelini gösteriyorsa uygulayın; SELinux’u tamamen kapatmak güvenli bir çözüm değildir.

Çözümü doğrulama

Değişikliklerden sonra dört katmanı sırayla doğrulayın:

# Veritabanı sunucusunda TCP testi
mysql -h 127.0.0.1 -P 3306 -u kullanici_adi -p -e 'SELECT @@hostname, @@port;'

# Uzak istemciden TCP erişimi ve kimlik doğrulama testi
mysql -h veritabani-sunucusu.example -P 3306 -u kullanici_adi -p -e 'SELECT 1;'

# Sunucuda etkin dinleme denetimi
sudo ss -ltnp | grep ':3306'

Uzak port testi başarılı fakat MySQL istemcisi ERROR 1045 veriyorsa, Error 2002 aşaması çözülmüştür. Sonraki konu; kullanıcı hesabının doğru 'kullanici'@'istemci-hostu' tanımı, parola ve yetkileridir. Uygulamanın yapılandırmasında doğru sunucu adı, port ve bağlantı türünün kullanıldığını son olarak doğrulayın.

Önleme ve sonuç

MySQL Error 2002 bağlantı hatası tekrarını azaltmak için veritabanı erişimini özel ağla sınırlandırın, 3306 için kaynak IP bazlı firewall kuralları kullanın ve servis günlüklerini merkezi izlemeye dahil edin. Yapılandırma değişikliklerini sürüm kontrolünde veya değişiklik kaydında tutmak, geri dönüşü kolaylaştırır. İzleme sisteminiz servis durumu, 3306 dinleme durumu, disk alanı ve bağlantı hata oranı için uyarı üretebilmelidir. Böylece sorun, uygulama kesintisine dönüşmeden önce fark edilir.

Sık sorulan sorular

Error 2002 ile Error 1045 arasındaki fark nedir?

Error 2002 bağlantının sunucuya ulaşamadığını veya reddedildiğini gösterir. Error 1045 ise sunucuya erişildiğini, ancak kimlik doğrulama ya da yetkilendirmenin başarısız olduğunu gösterir.

localhost neden 127.0.0.1 ile aynı sonucu vermiyor?

Birçok MySQL istemcisinde localhost Unix socket bağlantısını tercih eder. 127.0.0.1 ise TCP bağlantısını zorlar. Bu nedenle socket yolu sorunu iki hedefte farklı sonuç verebilir.

3306 portunu internete açmalı mıyım?

Genellikle hayır. Uzak erişim gerekiyorsa özel ağ, VPN veya bastion yaklaşımı tercih edin. Firewall kuralını yalnızca ihtiyaç duyan sabit kaynak IP’lerle sınırlandırın.

Servisi yeniden başlatmak veri kaybına yol açar mı?

Normal ve sağlıklı bir kapatma/başlatma veri kaybı anlamına gelmez; ancak açık bağlantılar ve çalışan işlemler kesilir. Günlüklerde InnoDB veya disk hatası varsa önce yedek ve kurtarma değerlendirmesi yapılmalıdır.