MySQL Error 2002 Bağlantı Hatası Nasıl Çözülür? Linux Teşhis Rehberi

MySQL Error 2002 bağlantı hatası, istemcinin MySQL veya MariaDB sunucusuna TCP/IP ya da Unix soketi üzerinden ulaşamadığını gösterir. Hata çoğunlukla Can't connect to local MySQL server through socket veya Connection refused metniyle birlikte görülür. Sorun; veritabanı servisinin durmuş olması, istemci ve sunucunun farklı socket dosyası kullanması, yanlış host/port tanımı, dinleme adresi, güvenlik duvarı veya DNS çözümlemesinden kaynaklanabilir. Bu rehber, Linux sunucularda MySQL Error 2002 bağlantı hatasının nedenini veri bütünlüğünü riske atmadan bulmak ve kalıcı biçimde gidermek için uygulanabilir bir sıra sunar.

Önce hatanın yerel socket bağlantısında mı, yoksa uzak TCP bağlantısında mı oluştuğunu ayırın. Doğru ayrım, gereksiz yapılandırma değişikliklerini ve kesinti riskini önler.

MySQL Error 2002 bağlantı hatası: Belirti ve kapsam

Bu hata, uygulama, komut satırı istemcisi veya bakım aracı veritabanına bağlantı kuramadığında görülür. Hata kodu aynı olsa da parantez içindeki işletim sistemi mesajı teşhis için önemlidir:

Hata örneği	Olası anlamı	İlk kontrol
... through socket '/var/run/mysqld/mysqld.sock' (2)	Socket dosyası yok, yol yanlış veya servis çalışmıyor.	Servis durumu ve socket yolu
... through socket ... (111)	Socket yolunda dinleyen sunucu yok ya da erişim reddediliyor.	Servis günlükleri ve socket sahibi
... on '127.0.0.1' (111)	TCP portunda dinleyen hizmet yok veya bağlantı engelleniyor.	ss ile 3306 dinlemesi
Unknown MySQL server host	Sunucu adı DNS ile çözümlenemiyor.	DNS ve uygulama bağlantı dizesi
Connection timed out	Ağ yolu, güvenlik duvarı veya yönlendirme sorunu olabilir.	Port erişimi ve firewall

Önemli: Error 2002 doğrudan tablo bozulması anlamına gelmez. Bu nedenle, yalnızca bağlantı hatası nedeniyle veri dosyalarını silmeyin, taşıma işlemi yapmayın veya InnoDB tablolarında REPAIR TABLE çalıştırmayın.

Hızlı teşhis kontrol listesi

Root yetkisi veya uygun sudo yetkisiyle aşağıdaki kontrolleri sırayla yapın. Üretim sisteminde servis yeniden başlatma veya yapılandırma değişikliği öncesinde güncel yedek, izleme alarmı ve bakım penceresi planlayın.

1. İstemcinin socket mi, TCP mi kullandığını hata metninden belirleyin.
2. MySQL/MariaDB servisinin çalıştığını doğrulayın.
3. 3306 portu veya beklenen Unix socket üzerinde dinleme olup olmadığını inceleyin.
4. Hata günlüklerinde başlatmayı engelleyen asıl nedeni bulun.
5. Yerel bağlantıyı socket ve TCP ile ayrı ayrı deneyin.
6. Uzak bağlantıda DNS, ağ erişimi, dinleme adresi ve güvenlik duvarını kontrol edin.

1. Servis durumunu doğrulayın

Paket adına göre servis adı değişir. Debian ve Ubuntu sistemlerinde MySQL için genellikle mysql, MariaDB için mariadb kullanılır. RHEL, AlmaLinux, Rocky Linux ve benzeri dağıtımlarda da kurulum türüne göre bu iki ad görülür.

sudo systemctl status mysql --no-pager
sudo systemctl status mariadb --no-pager

Komutlardan yalnızca kurulu hizmete ait olanı kullanın. Hizmet failed durumundaysa önce günlükleri okuyun; doğrudan tekrar başlatmak, kısa süreliğine sorunu gizleyebilir ancak kök nedeni çözmez.

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

Günlüklerde disk doluluğu, izin hatası, yanlış yapılandırma, InnoDB başlatma hatası veya başka bir sürecin portu kullanması gibi kayıtlar aranmalıdır. Disk ve inode doluluğu için:

df -h
df -i

2. Socket ve TCP bağlantısını ayırın

localhost ile yapılan bağlantı, MySQL istemcisinde çoğu Linux kurulumunda TCP yerine Unix socket kullanır. Buna karşılık 127.0.0.1, TCP bağlantısını zorlar. Bu iki testi karşılaştırmak sorunun katmanını belirler.

mysql -u root -p -h localhost
mysql -u root -p -h 127.0.0.1 -P 3306

İlk komut başarısız, ikinci komut başarılıysa servis çalışıyor olabilir; ancak istemci ve sunucu farklı socket yolu bekliyordur. İlk komut başarılı, ikinci komut başarısızsa TCP dinlemesi veya ağ yapılandırması incelenmelidir. Kimlik doğrulama hatası almanız, ağ/servis erişiminin çalıştığını gösterir; bu durum Error 2002’den farklıdır.

MySQL Error 2002 bağlantı hatasının yaygın nedenleri

Veritabanı hizmetinin başlamaması

En yaygın neden, mysqld sürecinin çalışmamasıdır. Hata günlüklerinde özellikle disk alanı, bellek baskısı nedeniyle sonlandırılma, yapılandırma sözdizimi ve InnoDB başlangıç mesajlarını inceleyin. Çekirdek tarafından bellek yetersizliği nedeniyle sonlandırılan süreçleri görmek için:

sudo dmesg -T | grep -i -E 'out of memory|killed process|oom'

Önce kök nedeni giderin. Örneğin disk doluysa güvenli alan açma ve yedekleme işlerini gözden geçirin; yanlış yapılandırma varsa son bilinen çalışan ayara dönün.

Socket dosyası yolu uyuşmazlığı

Dağıtım, paket ve yapılandırmaya göre socket yolu değişebilir. İstemci bir yolu, sunucu başka bir yolu kullanıyorsa hata mesajında belirtilen dosya bulunamaz. Çalışan sunucunun gerçek değerini SQL üzerinden öğrenmek en güvenilir yöntemdir:

mysql -u root -p -h 127.0.0.1 -e "SHOW VARIABLES LIKE 'socket';"

TCP de çalışmıyorsa etkin ayarları ve mevcut socket dosyalarını dikkatle kontrol edin:

sudo find /run /var/run /tmp -type s -name '*mysql*.sock' -o -name '*mysqld*.sock' 2>/dev/null
mysql --help | grep -i socket

find komutundaki sonuç, tek başına yapılandırmanın değiştirilmesi gerektiğini kanıtlamaz. Sunucu ayarı ile uygulama veya istemci ayarındaki socket değerinin aynı olduğundan emin olun. Uygulama bağlantı ayarını değiştirmeden önce yapılandırma yedeği alın.

3306 portunda dinleme olmaması veya yanlış bind adresi

TCP bağlantısında sistemin hangi adres ve portta dinlediğini kontrol edin:

sudo ss -ltnp | grep ':3306'

Hiç çıktı yoksa MySQL TCP’de dinlemiyor olabilir veya hizmet çalışmıyor olabilir. Yalnızca 127.0.0.1:3306 görünüyorsa uzak istemciler bağlanamaz; bu, çoğu tek sunuculu kurulum için bilinçli ve güvenli bir ayardır. Uzak erişim gerçekten gerekmedikçe bind-address değerini genel ağa açmayın.

Yapılandırma dosyasının yeri dağıtıma ve pakete göre değişir. MySQL ve MariaDB, varsayılan seçenek dosyalarını görmek için aşağıdaki komutla listelenebilir:

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

Etkin dosyada [mysqld] bölümündeki port, bind-address, skip-networking ve gerekliyse socket değerlerini kontrol edin. Değişiklikten önce dosyayı yedekleyin ve değişikliği bakım penceresinde uygulayın.

Güvenlik duvarı, DNS veya ağ yolu sorunu

Uzak sunucuya bağlanılıyorsa, istemci taraftan ad çözümlemesini ve port erişimini test edin:

getent hosts db.example.com
nc -vz db.example.com 3306

db.example.com yerine gerçek veritabanı sunucusu adını yazın. nc her dağıtımda kurulu olmayabilir; yoksa paket yöneticinizle kurmadan önce kurum güvenlik politikasını değerlendirin. Sunucu tarafında kullanılan güvenlik duvarı aracına göre kural incelemesi yapın:

sudo firewall-cmd --list-all
sudo ufw status verbose
sudo nft list ruleset

Bu araçların hepsi aynı sistemde kullanılmaz. Aktif olan çözümü tespit edin. 3306’yı internete tüm kaynaklardan açmak yerine yalnızca uygulama sunucularının sabit IP adreslerine izin verin. Ayrıca MySQL kullanıcı hesabının uzak kaynak için tanımlanmış olması gerekir; ancak bu eksiklik genellikle Error 2002 değil, erişim reddi hatası üretir.

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

1. Başlatma sorununu günlükten giderin

Hizmet durmuşsa ve günlükte düzeltilebilir sorun giderildiyse, kontrollü biçimde başlatın:

sudo systemctl start mysql
sudo systemctl status mysql --no-pager

MariaDB kullanıyorsanız komutlardaki mysql yerine mariadb yazın. Servis çalışırken yalnızca yapılandırma değişikliğini yüklemek için yeniden başlatma gerekebilir:

sudo systemctl restart mysql

Yeniden başlatma aktif bağlantıları keser. Özellikle üretim veritabanında bakım penceresi olmadan çalıştırmayın. Başlatma tekrar başarısız olursa sürekli yeniden denemek yerine yeni günlük kayıtlarını okuyun.

2. Socket uyuşmazlığını doğru katmanda düzeltin

Uygulama aynı makinedeyse, uygulamanın beklediği socket yolunu sunucunun etkin socket değeriyle eşleştirin. Uygulama TCP kullanabilecek şekilde tasarlanmışsa, yerel bağlantıda açıkça 127.0.0.1 ve doğru port kullanmak socket bağımlılığını kaldırabilir. Ancak uygulama yapılandırmasını değiştirmeden önce dosyanın yedeğini alın ve uygulama üreticisinin desteklediği parametreleri kullanın.

Eksik socket dosyasını elle oluşturmayın, rastgele sembolik bağ oluşturmayın ve çalışma dizini izinlerini tahmine dayalı olarak değiştirmeyin. Socket, veritabanı hizmeti tarafından oluşturulmalıdır; asıl problem genellikle hizmetin başlatılamaması veya ayarların uyuşmamasıdır.

3. Uzak TCP erişimini en az yetkiyle açın

Uzak erişim zorunluysa önce MySQL’in yalnızca gerekli özel ağ arayüzünde dinlemesini sağlayın. Ardından güvenlik duvarında sadece güvenilen kaynak IP’leri için 3306/TCP kuralı tanımlayın. Değişiklik sonrasında hem uygulama sunucusundan hem de yetkisiz bir ağdan test yaparak erişim sınırını doğrulayın. Genel internetten erişilebilen veritabanı portu, parola denemeleri ve keşif trafiği açısından ek risk yaratır.

4. InnoDB günlükleri hata gösteriyorsa veri kurtarmayı ayrı ele alın

Günlüklerde InnoDB’nin başlatılamadığı yazıyorsa, Error 2002 bunun sonucu olabilir. Önce depolama katmanı, disk alanı ve son değişiklikleri inceleyin. Veri dizini üzerinde silme/taşıma yapmadan önce dosya sistemi veya sanal makine düzeyinde tutarlı yedek alın.

Sunucu açılabiliyorsa öncelik mantıksal yedek almaktır. Tablo denetimi için, servis erişilebilir durumdayken aşağıdaki komut kullanılabilir:

mysqlcheck -u root -p --all-databases --check

CHECK TABLE ve mysqlcheck --check inceleme amaçlıdır; her InnoDB fiziksel bozulmasını onarmaz. InnoDB için klasik REPAIR TABLE komutunu çözüm olarak kullanmayın. Başlatma hatasında innodb_force_recovery ancak uzman gözetiminde, mümkün olan en düşük değerle ve öncelikle veri dışa aktarmak amacıyla değerlendirilmelidir. Bu mod yazma işlemlerini ve normal kurtarma davranışını etkileyebilir; kalıcı çalışma ayarı değildir. Güvenilir yedekten temiz bir örneğe geri dönüş çoğu ciddi bozulma senaryosunda daha güvenli yaklaşım olabilir.

Çözümü doğrulama

Düzeltme sonrasında hizmet, socket/TCP erişimi ve temel sorgu birlikte doğrulanmalıdır:

sudo systemctl is-active mysql
mysqladmin -u root -p -h 127.0.0.1 ping
mysql -u root -p -h 127.0.0.1 -e "SELECT VERSION();"
sudo ss -ltnp | grep ':3306'

MariaDB servis adı kullanılıyorsa ilk komutu uyarlayın. Uygulamanın kendi yapılandırdığı kullanıcıyla yaptığı sağlık kontrolü veya düşük etkili bir okuma sorgusu da test edilmelidir. Uzak bağlantı gerekiyorsa aynı testi uygulama sunucusundan yapın; yalnızca veritabanı sunucusunda başarılı olan test ağ kuralını doğrulamaz.

Tekrarını önleme

• Disk alanı, inode, bellek ve MySQL servis durumu için izleme ve alarm kurun.
• Yapılandırma değişikliklerini sürüm kontrolü veya değişiklik kaydıyla takip edin; değişiklik öncesi dosya yedeği alın.
• Uygulama bağlantı ayarlarında socket veya TCP tercihini açık ve tutarlı biçimde belirleyin.
• Yedeklerin yalnızca oluştuğunu değil, geri yüklenebildiğini düzenli olarak test edin.
• Uzak MySQL erişimini özel ağ, kaynak IP kısıtı ve en az yetki ilkesiyle sınırlandırın.

Sonuç

MySQL Error 2002 bağlantı hatası çoğunlukla servis, socket veya ağ erişimi katmanındaki bir uyuşmazlıktır. Hata metnindeki socket yolu, hata numarası ve hedef adresi dikkatle okuyup servis durumunu, günlükleri ve dinleyen portları sırasıyla incelemek en hızlı yoldur. InnoDB başlangıç hatası görülürse bunu sıradan bağlantı problemi gibi ele almayın; önce yedekleme ve veri kurtarma planını güvenceye alın.

Sık sorulan sorular

Error 2002 ile “Access denied” hatası aynı mıdır?

Hayır. Error 2002 bağlantı kurulamadığını belirtir. “Access denied” ise genellikle sunucuya ulaşıldığını, fakat kullanıcı adı, parola veya kaynak yetkisinin reddedildiğini gösterir.

localhost yerine 127.0.0.1 yazmak neden fark yaratır?

Linux’ta localhost çoğu MySQL istemcisinde Unix socket bağlantısını tercih eder. 127.0.0.1 ise TCP/IP üzerinden bağlantıyı zorlar; socket uyuşmazlığını ayırmak için yararlıdır.

MySQL çalışıyor ama uygulama hâlâ Error 2002 veriyor. Ne kontrol etmeliyim?

Uygulamanın host, port ve socket ayarını; uygulama kullanıcısının çalıştığı ortamı; konteyner kullanılıyorsa ağ ad alanını ve socket dosyasının konteynere aktarılıp aktarılmadığını kontrol edin.

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

Gerekmedikçe hayır. Uygulama ile veritabanını özel ağda tutmak tercih edilir. Zorunluysa erişimi belirli kaynak IP’lerle sınırlandırın ve şifreli bağlantı ile uygun kullanıcı yetkilerini uygulayın.

Servisi yeniden başlatmak sorunu çözer mi?

Bazen geçici olarak çözer; ancak disk doluluğu, yanlış ayar veya InnoDB hatası varsa kök neden devam eder. Yeniden başlatmadan önce günlükleri incelemek ve üretimde bakım penceresi kullanmak daha güvenlidir.