MySQL Error 2002: Yeniden Başlatma Sonrası Socket Dosyası Oluşmuyor Hatasını Çözme

MySQL Error 2002, istemcinin MySQL veya MariaDB sunucusuna erişemediğini gösterir. Yeniden başlatma, paket güncellemesi ya da yapılandırma değişikliği sonrasında görülen Can't connect to local MySQL server through socket ... (2) biçimi özellikle önemlidir: İstemcinin aradığı Unix socket dosyası yoktur, sunucu hiç başlamamıştır veya iki taraf farklı socket yollarını kullanıyordur. Bu rehber, Linux üzerinde socket dosyası oluşmayan MySQL Error 2002 sorununu veri tabanına müdahale etmeden teşhis etmeye ve güvenle gidermeye odaklanır.

Hata, yalnızca bir uygulamada değil; mysql komutunda, yedekleme betiklerinde veya PHP tabanlı bir sitede de oluşabilir. Önce çalışan servisi ve gerçek socket yolunu doğrulayın. Socket dosyasını elle oluşturmak ya da rastgele izin vermek kalıcı çözüm değildir; asıl neden bulunmalıdır.

Belirti, kapsam ve hızlı teşhis özeti

Sık görülen hata aşağıdakine benzer:

ERROR 2002 (HY000): Can't connect to local MySQL server through socket '/run/mysqld/mysqld.sock' (2)

Buradaki (2), işletim sisteminin istenen yolda dosya bulamadığını ifade eder. Bu, veritabanı dosyalarının bozulduğu anlamına gelmez. Öncelik, veritabanı motorunun ayakta olup olmadığını ve sunucu ile istemcinin aynı socket yolunu kullanıp kullanmadığını tespit etmektir.

• MySQL/MariaDB servisi çalışıyor mu?
• Servis günlüklerinde başlangıcı engelleyen disk, izin veya yapılandırma hatası var mı?
• Sunucunun açtığı socket ile istemcinin aradığı socket aynı mı?
• Socket üst dizini mevcut ve servis kullanıcısı tarafından yazılabilir mi?
• Uygulama gerçekten yerel socket mi kullanmalı, yoksa TCP ile başka bir sunucuya mı bağlanmalı?

Gözlem	Muhtemel anlamı	İlk güvenli işlem
Servis failed durumda	Socket oluşturulamadan başlatma kesilmiş olabilir	systemd günlüğündeki ilk gerçek hatayı inceleyin
Servis çalışıyor, socket yok	Farklı socket yolu veya başlatma ayarı olabilir	Çalışan süreç ve ayarlardan socket yolunu alın
Socket var, istemci Error 2002 veriyor	İstemci başka bir yolu kullanıyor olabilir	--socket ile açık test yapın
127.0.0.1 ile çalışıyor, localhost ile çalışmıyor	TCP erişilebilir; yerel socket yapılandırması uyumsuzdur	İstemci ve sunucu socket ayarlarını eşleştirin

MySQL Error 2002 nedenleri

Servisin başlayamaması

Disk alanı veya inode tükenmesi, hatalı bir sunucu parametresi, yanlış sahiplik, bellek baskısı ya da InnoDB başlangıç hatası nedeniyle servis çalışmıyor olabilir. Socket hatası bu ana sorunun sonucu olur. Bu durumda socket dosyasına değil, servis günlüğündeki ilk hata satırına odaklanın.

Sunucu ve istemci socket yollarının farklı olması

MySQL/MariaDB sunucusu [mysqld] bölümünde bir socket yolu kullanırken, komut satırı istemcisi veya uygulama [client] bölümünde başka bir yol arayabilir. Dağıtım, paket deposu veya elle derlenmiş kurulum değiştiğinde bu uyumsuzluk ortaya çıkabilir.

Geçici çalışma dizininin eksik ya da yanlış izinli olması

Bazı kurulumlar socket dosyasını yeniden başlatmada temizlenen bir çalışma dizininde üretir. Dizin oluşmazsa veya sahipliği servis hesabıyla uyumlu değilse sunucu socket oluşturamaz. Ancak gerçek yol dağıtıma ve kuruluma bağlıdır; hata mesajı ile sunucu ayarı doğrulanmadan dizin oluşturmayın.

Yerel bağlantı ile TCP bağlantısının karıştırılması

Çoğu MySQL istemcisinde localhost, Unix socket kullanma eğilimindedir; 127.0.0.1 ise TCP bağlantısını zorlar. Bu davranış uygulama sürücüsüne göre değişebilse de teşhis için yararlıdır. Uzak veritabanı hedeflerinde Error 2002; ağ rotası, güvenlik duvarı, DNS veya MySQL dinleme adresi sorunundan da kaynaklanabilir. Bu rehberdeki socket adımları yerel bağlantı içindir.

Log ve komutlarla güvenli teşhis

Üretim ortamında servis yeniden başlatmadan önce planlı bir bakım penceresi belirleyin. Aşağıdaki salt-okunur kontroller veri değiştirmez. Önce dağıtımınızda servis adını doğrulayın: Debian/Ubuntu paketlerinde çoğunlukla mysql, RHEL uyumlu sistemlerde çoğunlukla mysqld kullanılır. MariaDB kurulumlarında ad mariadb olabilir.

systemctl list-unit-files | grep -E '^(mysql|mysqld|mariadb)\.service'

Bulduğunuz servis adıyla durum ve günlüğü inceleyin. Aşağıdaki örnekte mysql yerine kendi servis adınızı yazın.

systemctl status mysql --no-pager -l
journalctl -u mysql -b --no-pager -n 200

Özellikle ERROR, InnoDB, Permission denied, No space left on device ve unknown variable satırlarını kontrol edin. Disk alanı ve inode kontrolü de başlangıç sorunlarını hızlıca ayırır:

df -h
df -i

Ardından istemci ve sunucu için tanımlanmış etkili seçenekleri görüntüleyin. my_print_defaults aracı kurulu değilse bu adımı atlayın; yapılandırma dosyası yollarını tahmin ederek değiştirmeyin.

my_print_defaults client
my_print_defaults mysqld

Çıktıda bulunan --socket=... değerlerini not edin. Çalışan servis varsa açık Unix socket’leri de kontrol edin:

ss -lx | grep -E 'mysql|mysqld|mariadb'
ps -ef | grep -E '[m]ysqld|[m]ariadbd'

İstemcinin hata mesajında aradığı yol ile my_print_defaults mysqld veya açık socket listesinde görünen yol aynı değilse, sorun büyük olasılıkla yapılandırma uyumsuzluğudur.

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

1. Servis durmuşsa önce başlangıç hatasını giderin

Günlükte hatalı bir parametre veya izin sorunu görünüyorsa, ilgili yapılandırma değişikliğini geri alın ya da düzeltin. Yapılandırma dosyasını değiştirmeden önce tarihli bir kopya alın ve mevcut dosya izinlerini koruyun. Dağıtıma göre ana dosya genellikle Debian/Ubuntu ailesinde /etc/mysql/ altında, RHEL ailesinde /etc/my.cnf veya dahil edilen dizinlerde bulunabilir; kesin dosyayı servis günlüklerinden ve etkin ayarlardan belirleyin.

Uyarı: Veri dizinini silmek, yeniden başlatmak için --initialize kullanmak veya rastgele InnoDB kurtarma parametresi eklemek bu Error 2002 için uygun ilk işlem değildir. Bunlar veri kaybı veya daha uzun kesinti riski doğurur. Günlükte InnoDB hatası varsa, veri dosyalarına dokunmadan önce güncel yedek ve kurtarma planı oluşturun.

Düzeltme sonrasında, bakım penceresinde servisi başlatın ve durumunu tekrar kontrol edin:

sudo systemctl restart mysql
systemctl is-active mysql
journalctl -u mysql -b --no-pager -n 80

Servis adı farklıysa tüm komutlarda aynı adı kullanın. Servis tekrar başarısız olursa art arda yeniden başlatma denemeleri yapmak yerine yeni günlük satırlarını inceleyin.

2. Socket yolunu tek bir değerde eşleştirin

Sunucu çalışıyor ancak istemci yanlış yola bakıyorsa, önce gerçek sunucu socket’i ile doğrudan bağlantıyı test edin. Aşağıdaki /gercek/socket/yolu.sock ifadesini teşhis ettiğiniz gerçek değerle değiştirin:

mysql --protocol=socket --socket=/gercek/socket/yolu.sock -u root -p

Bu test başarılıysa motor ve socket çalışıyordur. Kalıcı çözüm için uygulamanın bağlantı ayarını veya istemcinin [client] ayarını, [mysqld] tarafındaki gerçek socket yolu ile uyumlu hale getirin. Tek bir ayarı değiştirmek yerine, hangi dosyanın ayarı ezdiğini my_print_defaults ile yeniden doğrulayın. Değişiklik yaptıysanız yalnızca sunucu tarafı ayarı değiştiğinde servis yeniden başlatması gerekir; istemci ayarı için genellikle yeni bağlantı yeterlidir.

3. Çalışma dizini sorununu kanıtla, sonra düzelt

Günlük açıkça socket üst dizininin bulunmadığını veya erişilemediğini belirtiyorsa, önce yapılandırılmış socket yolunun üst dizinini inceleyin:

socket_path='/gercek/socket/yolu.sock'
parent_dir=$(dirname "$socket_path")
ls -ld "$parent_dir"
namei -l "$socket_path"

Burada namei kurulu değilse yalnızca ls -ld kullanın. Dizin yoksa veya sahiplik farklıysa, paketinizin ve systemd biriminin beklediği çalışma dizini yönetimini kontrol edin:

systemctl cat mysql
systemctl show mysql -p RuntimeDirectory -p User -p Group

Bu çıktılar, çalışma dizininin systemd tarafından oluşturulup oluşturulmadığını anlamaya yardım eder. Dizin sahipliğini yalnızca servis hesabı ve doğrulanmış socket yolu belli olduktan sonra düzeltin. Belirsiz bir kullanıcıyla geniş kapsamlı chown -R uygulamayın; veri dizinindeki sahiplikleri değiştirmek veritabanını başlatılamaz hale getirebilir.

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

Yerel TCP dinlemesini test etmek için parolayı etkileşimli girerek aşağıdaki komutu kullanın:

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

Bu test başarılı, socket testi başarısızsa ağ sorunu değil socket yapılandırması vardır. Her iki test başarısızsa servis günlüğüne dönün. TCP testinin başarısız olması tek başına güvenlik duvarı kanıtı değildir; sunucu yalnızca socket ile çalışacak şekilde ayarlanmış veya farklı bir portta dinliyor olabilir.

Çözümü doğrulama

Servis ayakta ve socket yolu eşleştirildikten sonra hem bağlantıyı hem de temel sorguyu doğrulayın:

mysqladmin --protocol=socket --socket=/gercek/socket/yolu.sock -u root -p ping
mysql --protocol=socket --socket=/gercek/socket/yolu.sock -u root -p -e 'SELECT VERSION();'

Başarılı mysqld is alive yanıtı, socket üzerinden erişimin kurulduğunu gösterir. Son olarak uygulamanın kullandığı kullanıcıyla uygulama bağlantısını kontrol edin. Uygulama bundan sonra Access denied gibi bir hata verirse bu artık Error 2002 değildir; kullanıcı yetkisi veya parola ayrı olarak ele alınmalıdır.

Önleme ve sonuç

MySQL Error 2002 tekrarını azaltmak için socket yolunu sunucu, istemci ve uygulama katmanlarında belgelendirin; yapılandırma değişikliklerini sürüm kontrolü veya değişiklik kaydıyla yönetin. İzleme sisteminizde servis durumu, disk alanı, inode kullanımı ve günlüklerdeki başlatma hataları için uyarılar oluşturun. Paket veya işletim sistemi güncellemelerinden sonra kontrollü yeniden başlatma ve yerel bağlantı testi uygulayın.

Özetle, socket dosyasını elle taklit etmek yerine servisin neden socket üretmediğini veya istemcinin neden yanlış yolu aradığını kanıtlayın. Bu yaklaşım MySQL Error 2002 sorununu daha güvenli çözer ve gereksiz veri riski oluşturmaz.

Sık sorulan sorular

MySQL Error 2002 veri kaybı olduğu anlamına gelir mi?

Hayır. Çoğu vakada bağlantı katmanı sorunudur. Ancak servis günlüklerinde InnoDB veya disk hatası varsa veriye müdahale etmeden önce yedek ve kurtarma planı gerekir.

localhost yerine 127.0.0.1 yazmak kalıcı çözüm müdür?

Hayır, bu öncelikle socket ve TCP davranışını ayıran bir teşhistir. Uygulamanın gereksinimine göre doğru bağlantı yöntemini belirleyin; socket yolu uyumsuzluğunu gizlemeyin.

Socket dosyasını touch ile oluşturabilir miyim?

Hayır. Socket, çalışan MySQL/MariaDB sürecinin oluşturduğu özel bir iletişim nesnesidir. Normal dosya oluşturmak bağlantıyı düzeltmez.

REPAIR TABLE bu hatayı düzeltir mi?

Hayır. Error 2002 bağlantı hatasıdır. Ayrıca InnoDB tablolarında klasik REPAIR TABLE yaklaşımı uygun kurtarma yöntemi değildir. Önce bağlantıyı ve servis başlangıcını düzeltin.

Uzak sunucuya bağlanırken Error 2002 alıyorum; socket adımları geçerli mi?

Genellikle hayır. Uzak bağlantıda hedef adresi, DNS çözümlemesini, portu, MySQL dinleme ayarını, ağ erişimini ve güvenlik duvarını incelemek gerekir.