MySQL “Too many connections” Hatası: Net Neden & Çözüm Rehberi

MySQL’de sık görülen "Too many connections" hatası, uygulamanızın aynı anda çok fazla bağlantı açmaya çalıştığını veya MySQL’in mevcut bağlantıları verimli yönetemediğini gösterir. Bu yazıda, hatanın nedenlerini net şekilde ayıracak; hangi ayarın hangi riski doğurduğunu, hangi düzeltmenin kalıcı sonuç verdiğini göstereceğiz. Ayrıca pratik bir tanılama akışı ve uygulanabilir yapılandırma örnekleriyle doğru çözümü hızlıca bulacaksınız.

Hata ne anlama gelir? “Too many connections” ne zaman çıkar

MySQL, aynı anda izin verilen eşzamanlı bağlantı sayısını aşınca yeni bağlantıları kabul etmeyi durdurur ve uygulama tarafında hata üretilir. Bu durum genellikle şu iki senaryodan birine dayanır:

• max_connections limiti dolmuştur. MySQL, aynı anda kaç bağlantıya izin verdiğini max_connections ayarıyla belirler.
• Bağlantılar hızlı doluyordur ama kapatma/temizlik gecikiyordur. Uygulama bağlantıları bitse bile thread’ler uzun süre açık kalabilir; bu da “bağlantı birikmesi” yaratır.

Bu ayrımı net yapmak için önce MySQL’in mevcut anlık bağlantı durumunu görmeniz gerekir.

Hızlı tanılama: Bağlantı sayısını ve limitleri doğrulayın

MySQL komut satırında veya yetkili hesapla şu sorgularla durumu izleyin:

• Anlık bağlantılar: SHOW STATUS LIKE 'Threads_connected';
• Bekleyen thread sayısı: SHOW STATUS LIKE 'Threads_running';
• Limite göre kullanım oranı: SELECT @@max_connections;
• O anki uzun sorgular: SHOW FULL PROCESSLIST;

Beklenen işaretler: - Threads_connected değeri, max_connections değerine çok yakınsa doğrudan limit kaynaklıdır. - Threads_connected çok yüksek değilken yine de hata alınıyorsa, uygulamanız bağlantıları anlık patlatıyor olabilir (burst) ya da MySQL tarafında thread kapanması gecikiyor olabilir.

1) En sık neden: Uygulamanın bağlantı yönetimi bozukluğu

Birçok projede sorun, MySQL sunucusundan önce uygulama tarafında başlar. Özellikle şu desenler “Too many connections” üretir:

• Her istek için yeni bağlantı açmak (connection per request)
• Bağlantıyı kapatmamak veya pool boyutunu kontrol etmemek
• Uygulama ölçeklenince (çok worker/çok pod) bağlantı sayısının lineer artması
• Timeout/keep-alive ayarlarının yanlış olması

Çözüm: Bağlantı havuzu (connection pooling) kullanın

Kalıcı çözümün temeli, uygulamanın MySQL’e tek tek bağlantı kurmasını engellemek ve havuzla yönetmektir (connection pool).

Net yaklaşım: - Uygulama dili / framework’ünüz için havuz kullanın (ör. Java HikariCP, Node.js tarafında pool, PHP tarafında PDO + pool mantığı). - Pool boyutunu MySQL’in kaldırabileceği eşzamanlı bağlantıya göre ayarlayın.

Aşağıdaki ilişkiyi net düşünün: - MySQL’de max_connections yükseltmek, daha fazla bağlantıya izin verir; ancak her bağlantı için kaynak (thread, bellek, scheduler yükü) artar. - Pool boyutunu gereğinden büyük yaparsanız yine limitleri aşarsınız.

Pool boyutunu net hesaplamak için pratik yöntem

Pool boyutunu belirlemenin somut bir yöntemi:

1. MySQL’de mevcut Threads_connected zirvelerini 10-30 dakika gözleyin.
2. Uygulama ölçeğinizi (worker/pod sayısı) belirleyin.
3. Pool size’ı şu mantıkla sınırlayın: - Toplam eşzamanlı bağlantı (yaklaşık) = worker/pod sayısı × pool size
4. Bu toplamın max_connections değerinin %60–%70’ini geçmemesini hedefleyin.

Bu “%” oranı, bağlantı artışlarında (burst) hızlı şekilde limiti aşmamak için güvenlik payıdır.

2) max_connections limiti doluyor: Neyi artırmalı, neyi artırmamalı?

max_connections doğrudan “aynı anda kaç bağlantı açılabilir” sorusunu yanıtlar. Ancak bu ayarı körlemesine artırmak doğru çözüm değildir.

Neden sadece max_connections artırmak risklidir?

• Bağlantı sayısı arttıkça MySQL’de thread’ler çoğalır.
• Thread sayısı artınca CPU scheduler maliyeti yükselir.
• Bellek tüketimi artabilir (konfigürasyona bağlı olarak).
• Sonuç: “Yeni bağlantı açamama” hatası yerine “yavaşlama / zaman aşımı / daha fazla birikme” görülebilir.

Net çözüm: max_connections’ı hedefle, nedenini düzelt

Doğru sıra şudur: 1. Önce uygulama bağlantı yönetimini düzeltin (pool + doğru kapatma). 2. Sonra MySQL limitini, beklenen gerçek yük için ayarlayın. 3. Son olarak izleme kurun; limit tekrar yaklaşırsa kök nedeni tekrar bulun.

3) Sık görülen ayar kaynaklı sorunlar: Thread birikmesi ve yavaş kapanma

MySQL’de bağlantı açmak kadar bağlantıyı “aktif değilken” doğru yönetmek de önemlidir. Özellikle uzun sorgular, kilitler veya hatalı indeksler, bağlantıların uzun süre açık kalmasına neden olur.

Önce “kim iş yapıyor?” sorusu

SHOW FULL PROCESSLIST; ile şu alanlara bakın: - Time (sorgu kaç saniyedir çalışıyor) - State (bekleme durumu: lock, Sending data, Sorting gibi) - Info (çalışan SQL)

Net hedef: Uzun süren aynı sorgular veya kilit beklemeleri varsa, bağlantı sayısı artmadan da “Too many connections” benzeri belirtiler tetiklenebilir.

Net çözüm: Yavaş sorguları düzeltin

Bağlantı sayısını azaltmanın en etkili yolu, sorguları hızlandırmaktır: - Eksik indeksleri tamamlayın - Aşırı büyük JOIN / ORDER BY / GROUP BY sorgularını optimize edin - Gereksiz kolonları çekmeyin

4) Doğru timeout ve limit stratejisi: Bağlantılar ne kadar süre beklemeli?

Bağlantıların sonsuza dek açık kalmasına izin vermek doğrudan risk üretir. Bu yüzden timeout’lar önemlidir.

Net kontrol listesi (değerleri ortamınıza göre ayarlayın):

Bağlantı ve işlem bekleme kontrolü

• Uygulamanızın sorgu timeout’larını net tanımlayın.
• MySQL tarafında uzun beklemeyi kesen ayarları gözden geçirin.

Kilit (lock) kaynaklı beklemeleri takip edin

Eğer uygulama transaksiyonlar kilit tutuyorsa, bağlantılar “beklemede” birikir. Bu durumda: - Transaction sürelerini kısaltın - İndeksle kilit kapsamını daraltın - Toplu işlemleri (bulk) parçalara bölün

5) Veritabanı ölçekleme değil, “bağlantı mimarisi” düzeltmesi

MySQL üzerinde “daha çok bağlantıya izin ver” yaklaşımı geçici bir rahatlama sağlar. Kalıcı olarak şu ayrımı yapın:

• Eşzamanlı bağlantı patlaması sorunu: Pool + uygulama ayarı çözümü.
• Sorgu yavaşlığı/lock sorunu: SQL + indeks + transaction çözümü.
• Yanlış limitleme/timeout sorunu: Limit ve timeout düzeltmesi.

Bu üçlüden hangisi baskınsa, çözüm de o yönde netleşir.

Uygulanabilir bir düzeltme planı (30-60 dakikalık görev akışı)

Aşağıdaki plan, üretim sisteminde riski azaltarak “doğru hamle”yi sırayla uygular.

Adım 1: Belirtiyi doğrula

• Hata aldığınız saatlerde Threads_connected zirvesini bulun.
• SHOW FULL PROCESSLIST; ile uzun sorguları yakalayın.

Adım 2: Uygulama bağlantı davranışını ölç

• Uygulama loglarında istek başına bağlantı açma/desenini kontrol edin.
• Aynı anda çalışan worker/pod sayısını ve pool size’ı doğrulayın.

Adım 3: Connection pooling’i devreye alın veya düzeltin

• Havuz boyutunu toplam eşzamanlı bağlantı hedefinize göre ayarlayın.
• Bağlantıyı döngü içinde yeniden açmak yerine pool üzerinden yönetin.

Adım 4: max_connections’i sadece hedef yükle uyumlu olacak şekilde güncelleyin

• Artış yapacaksanız gerçek ihtiyaca göre yapın.
• Artış sonrası Threads_connected değerinin yeniden limiti yaklaşıp yaklaşmadığını izleyin.

Adım 5: Uzun sorguları optimize edin

• En çok kaynak tüketen SQL’leri indeksleyin.
• Kilit bekleyen sorguları transaction tasarımından düzeltin.

MySQL “Too many connections” için sık senaryolar ve net öneriler

Aşağıdaki tablo, hangi belirti hangi çözümü işaret eder net biçimde özetler.

Ne zaman max_connections artırmak gerekir? Net kriterler

max_connections artışı şu koşullarda anlamlıdır: - Uygulama bağlantı davranışı düzgün (pool kullanılıyor, gereksiz aç-kapat yok). - Yine de beklenen gerçek trafik sırasında bağlantı sayısı gerçekten limitin üzerinde kalıyor. - Sunucu donanımı ve MySQL konfigürasyonu bu yükü kaldırabiliyor.

Aksi durumda (pool yokken veya sorgular çok yavaşken) max_connections artırmak yalnızca sorunu büyütebilir.

Test etme yaklaşımı

• Değişiklikleri trafiği düşükken veya bakım penceresinde yapın.
• İzlemeyi kapatmayın: Threads_connected, Threads_running, uzun sorgular.
• Ölçümden sonra geri dönüş planı hazırlayın.

Sonuç: Bu hatayı tek hamlede değil, bağlantı bütçesiyle çözün

"Too many connections" hatasında en hızlı yol, önce uygulamanın bağlantı davranışını düzeltmek (connection pooling) ve MySQL tarafında bununla uyumlu bir max_connections hedeflemektir. İkinci adım olarak uzun sorgu ve kilit beklemelerini ortadan kaldırın. Bugün ilk aksiyon olarak: Threads_connected zirvelerini kontrol edin, SHOW FULL PROCESSLIST ile uzun sorguları yakalayın ve uygulama pool size’ını toplam bağlantı bütçesine göre yeniden ayarlayın.

Böyle ilerlediğinizde, hata tekrar ortaya çıktığında “hangi katmanda” sorun olduğunu net yakalarsınız.