MySQL Error 2002: Socket ve TCP Bağlantı Hatasını Güvenle Giderme

MySQL Error 2002, istemcinin MySQL veya MariaDB sunucusuna erişemediğini gösteren bir bağlantı hatasıdır. Hata; yerel Unix socket dosyasının bulunamaması, servisinin çalışmaması, TCP 3306 portunun dinlememesi ya da uzak erişimin ağ ve güvenlik duvarı tarafından engellenmesiyle ortaya çıkar. En sık görülen iletiler Can't connect to local MySQL server through socket ve Can't connect to MySQL server on 'sunucu-adresi' biçimindedir. Bu rehber, Linux sunucularda sorunun socket mi, TCP mi, yoksa servis ve ağ katmanı mı olduğunu ayırarak MySQL Error 2002 hatasını veri riski oluşturmadan gidermeye odaklanır.

Belirti ve kapsam: Hatanın türünü doğru ayırın

Error 2002 tek başına kök nedeni söylemez. Önce hata iletisindeki bağlantı yöntemini belirleyin. localhost çoğu Linux MySQL istemcisinde TCP yerine Unix socket kullanımına yönelir. Buna karşılık 127.0.0.1, TCP/IP bağlantısını zorlar. Bu ayrım, sorunun hangi katmanda olduğunu hızlıca gösterir.

Hata örneği	Öncelikli inceleme alanı
... through socket '/yol/mysql.sock'	Servis durumu, gerçek socket yolu, dizin izinleri, disk alanı
... on '127.0.0.1' (111)	3306 dinleme durumu, bind-address, servis başlatma hatası
... on 'sunucu-adresi' (110)	Yönlendirme, güvenlik duvarı, sağlayıcı ACL’i, uzak TCP erişimi
... on 'sunucu-adresi' (111)	Hedefte port kapalı, yanlış IP/port veya MySQL yalnızca yerelde dinliyor

MySQL Error 2002 için hızlı teşhis özeti

1. Komutun kullandığı hedefi doğrulayın: localhost, 127.0.0.1 veya uzak IP/FQDN.
2. MySQL ya da MariaDB servisinin çalışıp çalışmadığını kontrol edin.
3. Socket hatasında, istemcinin aradığı yol ile sunucunun oluşturduğu socket yolunu karşılaştırın.
4. TCP hatasında, hedefte 3306 veya özel yapılandırılmış portun gerçekten dinlediğini doğrulayın.
5. Uzak bağlantıda DNS, güvenlik duvarı, ağ erişim listeleri ve MySQL kullanıcı yetkilerini ayrı ayrı test edin.
6. Servisi yeniden başlatmadan önce hata günlüklerini okuyun. Özellikle disk doluluğu veya InnoDB başlangıç hatası varsa rastgele tekrar başlatmalar teşhisi zorlaştırabilir.

Olası nedenler

MySQL veya MariaDB servisi durmuş ya da başlatılamıyor

Paket güncellemesi, hatalı yapılandırma, yetersiz disk alanı, bellek baskısı veya InnoDB günlük/veri dosyalarıyla ilgili bir başlangıç problemi servisinin durmasına neden olabilir. Socket dosyası genellikle servis çalışırken oluştuğundan, önce servis sağlığını değerlendirin.

İstemci ve sunucuda socket yolu farklı

Dağıtım, paket ve kurulum yöntemine göre socket yolu değişebilir. Örneğin uygulama bir socket yoluna göre yapılandırılmışken MySQL başka bir yolda socket oluşturabilir. Socket yolunu tahmin ederek yapılandırma değiştirmek yerine hem istemci hem sunucu ayarını ve mevcut dosyayı ölçün.

TCP dinleme ayarı veya port eşleşmesi yanlış

bind-address ayarı MySQL’in hangi ağ arayüzlerinde dinlediğini sınırlar. Ayrıca varsayılan 3306 yerine farklı bir port kullanılmış olabilir. Yerel TCP testi başarısızsa konu henüz güvenlik duvarı değildir; önce servisin doğru adres ve portta dinlediğini doğrulayın.

Uzak erişim ağ veya güvenlik politikasıyla engelleniyor

Sunucu güvenlik duvarı, bulut güvenlik grubu, veri merkezi ACL’i veya iki ağ arasındaki rota TCP erişimini engelleyebilir. Portu herkese açmak yerine yalnızca uygulama sunucusunun sabit IP adresine gerekli erişimi tanımlayın.

Hata aslında yetkilendirme hatasıyla karıştırılıyor

Error 2002 bağlantı kurulmadan önce oluşur. Bağlantı kurulduktan sonra görülen Access denied hatası ise kullanıcı adı, parola veya 'kullanici'@'host' yetkileriyle ilgilidir. Bu iki hatayı aynı değişiklik setiyle çözmeye çalışmayın.

Log ve teşhis komutları

Aşağıdaki kontroller yalnızca okuma amaçlıdır. Komutları yetkili bir kabukta çalıştırın. Sisteminizde servis adı mysql veya mariadb olabilir; önce mevcut birimi tespit edin.

systemctl list-unit-files --type=service | grep -E '^(mysql|mariadb)\.service'
systemctl status mysql --no-pager
systemctl status mariadb --no-pager
journalctl -u mysql -n 100 --no-pager
journalctl -u mariadb -n 100 --no-pager

status çıktısında yalnızca mevcut olan servis adını kullanın. Başlatma hatasının ayrıntısı çoğu systemd tabanlı dağıtımda journalctl içinde bulunur. MySQL hata günlüğünün dosya yolu kurulumdan kuruluşa değişebildiği için, yolunu bilmeden sabit bir günlük dosyasını varsaymayın.

Disk ve inode eksikliği, servisin socket oluşturmasını veya yazma işlemlerini engelleyebilir:

df -h
df -i
free -h

TCP dinlemeyi ve yerel bağlantıyı ayırmak için:

ss -lntp | grep ':3306'
mysqladmin --protocol=TCP -h 127.0.0.1 -P 3306 ping
mysqladmin --protocol=SOCKET ping

mysqladmin parola veya kullanıcı gerektiriyorsa uygun yetkili hesap bilgilerini güvenli yönteminizle verin. TCP için özel port kullanılıyorsa -P değerini yapılandırmanızdaki gerçek portla değiştirin. Socket yolunu istemci varsayımlarından görmek için şu komut kullanılabilir:

mysql --help | sed -n '/Default options are read from the following files:/,/Variables and options/p' | head -n 30
my_print_defaults client mysql mysqld 2>/dev/null

Çalışan socket dosyalarını, erişilebilir dizinlerle sınırlı biçimde aramak için:

find /run /var/run /tmp -type s -name '*mysql*.sock' -o -name '*mariadb*.sock' 2>/dev/null

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

1. Servis kapalıysa nedeni okuyun, sonra kontrollü başlatın

Önce günlükte yapılandırma sözdizimi, disk doluluğu, izin veya InnoDB ile ilgili hata olup olmadığını inceleyin. Planlı bakım penceresi yoksa üretim servisinde yeniden başlatma aktif bağlantıları kesebilir. Kritik sistemlerde güncel ve geri yüklenebilir yedek bulunduğunu doğrulayın.

sudo systemctl start mysql
sudo systemctl status mysql --no-pager
# MariaDB kullanan sistemlerde:
sudo systemctl start mariadb
sudo systemctl status mariadb --no-pager

Servis tekrar durursa sürekli yeniden başlatmak yerine günlüğe dönün. InnoDB kurtarma gerektiren bir hata görürseniz veri dizininde dosya silmeyin, taşımayın ve REPAIR TABLE komutunu InnoDB için çözüm olarak kullanmayın. Bozulma şüphesinde doğru yaklaşım; öncelikle yedek doğrulamak, mümkünse mantıksal dump almak, ardından kontrollü dump/restore veya yedekten dönüş planlamaktır. innodb_force_recovery yalnızca uzman değerlendirmesiyle, en düşük gerekli seviyede ve öncelikle veri dışa aktarmak amacıyla kullanılmalıdır; yazma ve veri bütünlüğü riski taşır.

2. Socket yolunu eşitleyin veya TCP’yi bilinçli kullanın

Servis çalışıyor, fakat localhost ile bağlantı başarısızsa gerçek socket dosyasını bulun. Uygulamanın veya istemcinin ayarındaki socket değeri, MySQL sunucusunun oluşturduğu değerle aynı olmalıdır. Değişiklikten önce ilgili yapılandırma dosyasının yedeğini alın ve sadece gerekli satırı düzenleyin.

Geçici teşhis amacıyla socket yerine TCP’yi zorlayın:

mysql --protocol=TCP -h 127.0.0.1 -P 3306 -u kullanici -p

Bu komut başarılı, mysql -h localhost başarısızsa servis büyük olasılıkla sağlıklıdır; sorun socket yolu veya socket dizini izinlerindedir. Socket dosyasını elle oluşturmaya çalışmayın. Dosya servis tarafından oluşturulmalıdır. Socket’in bulunduğu çalışma zamanı dizini yeniden başlatma veya sistem açılışında yeniden üretilebildiğinden, kalıcı çözüm doğru servis ve istemci yapılandırmasıdır.

3. TCP dinleme adresi ve portu doğrulayın

ss çıktısında MySQL yalnızca 127.0.0.1:3306 üzerinde dinliyorsa uzak istemciler bağlanamaz; ancak aynı sunucudaki uygulamalar bağlanabilir. Uzak erişim gerçekten gerekiyorsa etkin MySQL yapılandırmasındaki bind-address ve port değerlerini inceleyin. Dahil edilen yapılandırma dosyalarının sırası dağıtıma göre değiştiğinden, değişikliği hangi dosyanın ezdiğini de kontrol edin.

Yapılandırma değişikliği bir bakım işlemidir. Dosyanın yedeğini alıp sözdizimini dikkatle kontrol ettikten sonra yalnızca bir kez yeniden başlatın:

sudo systemctl restart mysql
# veya
sudo systemctl restart mariadb

4. Uzak bağlantıyı katman katman test edin

Uygulama sunucusundan hedef veritabanı sunucusuna, gerçek portla bağlantı testi yapın:

nc -vz veritabani-sunucusu.example 3306

nc her dağıtımda kurulu olmayabilir; kurulum yapmak zorunda değilsiniz. Test başarısızsa hedefte dinleme adresini, işletim sistemi güvenlik duvarı kurallarını ve varsa bulut güvenlik politikasını kontrol edin. Başarılı TCP testi sonrası MySQL istemcisi hâlâ hata veriyorsa, ana bilgisayar adı çözümlemesi ve istemcinin kullandığı portu yeniden doğrulayın. Bağlantı kurulur ancak erişim reddedilirse artık Error 2002 aşaması geride kalmıştır; kullanıcı yetkilerini inceleyin.

Çözümün doğrulanması

Servis ve bağlantı sağlandıktan sonra hem soket hem TCP yolunu, ihtiyacınız varsa uzak erişimi ayrı doğrulayın:

mysqladmin --protocol=SOCKET ping
mysqladmin --protocol=TCP -h 127.0.0.1 -P 3306 ping
mysql -u kullanici -p -e 'SELECT VERSION();'

Başarılı yanıtta genellikle mysqld is alive görülür. Uygulamanız uzak veritabanına bağlanıyorsa uygulama hizmetinin günlüklerinde yeni bağlantı hatası oluşmadığını, ayrıca uygulamanın beklenen veritabanı işlemini güvenle tamamladığını kontrol edin. Parolayı komut satırına düz metin olarak eklemeyin; kabuk geçmişi ve süreç listelerinde görünme riski vardır.

Tekrarını önleme

• Disk alanı ve inode kullanımını izleyin; özellikle günlük dosyaları ve veri bölümü için uyarı eşikleri belirleyin.
• Uygulamalarda yerel bağlantı tercihini açıkça tanımlayın: socket kullanılacaksa doğrulanmış socket yolunu, TCP kullanılacaksa 127.0.0.1 ve gerçek portu kullanın.
• Yapılandırma değişikliklerini sürüm kontrolü veya değişiklik kaydıyla takip edin; paket güncellemelerinden sonra servis durumunu kontrol edin.
• Uzak MySQL erişimini yalnızca gerekli kaynak IP’lerle sınırlandırın; geniş ağlara açık 3306 kurallarından kaçının.
• Düzenli, geri yükleme testi yapılmış yedekler tutun. Yedek varlığı kadar geri dönülebilirliği de önemlidir.

Sonuç

MySQL Error 2002 hatasını güvenle çözmenin anahtarı, socket ve TCP erişimini birbirinden ayırmaktır. Önce servis günlükleri ve kaynak durumuyla sunucunun sağlığını doğrulayın; sonra gerçek socket yolu, dinleyen port, bağlanma adresi ve ağ politikalarını sırayla kontrol edin. Bu yöntem, gereksiz yapılandırma değişikliklerini ve veri bütünlüğünü riske atabilecek aceleci müdahaleleri önler.

Sık sorulan sorular

localhost yerine neden 127.0.0.1 kullanınca bağlanıyor?

Linux istemcilerinde localhost çoğunlukla Unix socket kullanır; 127.0.0.1 ise TCP bağlantısını zorlar. Bu durum genellikle socket yolu veya socket diziniyle ilgili bir uyumsuzluğa işaret eder.

Error 2002 için MySQL’i her zaman yeniden başlatmalı mıyım?

Hayır. Önce servis durumu ve günlükler incelenmelidir. Servis çalışıyorsa hata socket yolu, TCP dinleme ayarı veya ağ kuralından kaynaklanabilir. Gereksiz yeniden başlatma aktif oturumları keser.

Connection refused ile Connection timed out arasındaki fark nedir?

Connection refused genellikle hedefe ulaşıldığını fakat ilgili portta dinleyen hizmet olmadığını gösterir. Connection timed out ise paketlerin güvenlik duvarı, rota veya ağ politikası nedeniyle yanıt alamadığını düşündürür.

InnoDB sorunu varsa REPAIR TABLE kullanabilir miyim?

Hayır, REPAIR TABLE InnoDB için klasik ve güvenli bir kurtarma yöntemi değildir. Önce yedek, hata günlükleri ve kontrollü mantıksal dışa aktarma seçenekleri değerlendirilmelidir. Gerekirse kurtarma, uzman gözetiminde dump/restore veya yedekten dönüş planıyla yapılmalıdır.

3306 portunu internete açmak gerekli mi?

Çoğu mimaride gerekli değildir. Uygulama ve veritabanı aynı sunucudaysa yerel bağlantı yeterlidir. Uzak erişim zorunluysa portu yalnızca ihtiyaç duyulan kaynak IP adreslerine ve güvenilir ağlara açın.