MySQL “Too many connections” Hatası: Net Sebep ve Çözümler

MySQL’de hata almanızın en hızlı sinyallerinden biri "Too many connections" mesajıdır. Bu sorun, uygulamanızın beklediği yanıt süresini uzatır; web sitesi veya API trafiğinde aniden servis etkilenmesine yol açar. Bu rehberde, hatanın kök nedenlerini (yalnızca max_connections artırmak değil) adım adım netleştirip, hangi çözümün hangi senaryoda işe yaradığını öğreneceksiniz. Hedefimiz: bağlantı sayısını kontrol altına alıp stabil çalışmayı sağlamak.

Hata ne anlama geliyor? (Too many connections)

MySQL, istemcilerden gelen bağlantıları belirli bir limite kadar kabul eder. Bu limit genellikle max_connections parametresiyle belirlenir. Limit dolduğunda MySQL yeni bağlantıları reddeder ve uygulama şu tarz hataları görebilir:

“Too many connections” (çok sayıda bağlantı)
“Can’t connect to MySQL server” (limit dolduğu için yeni oturum açılamıyor)
Zaman aşımı (timeout) ve yavaşlama (bağlantı bekleyen thread’ler birikir)

Önemli nokta: Bu hata tek başına “sunucu zayıf” demek değildir. Bazen uygulama bağlantıları düzgün kapatılmıyor, bazen bağlantı havuzu (pooling) yanlış yapılandırılıyor, bazen de servisler “şart değilken” yeni bağlantı açıyor.

1) Net tanılama: Hangi bağlantılar gerçekten artıyor?

Çözüm seçmeden önce 3 soruyu yanıtlayın:

Bağlantı limiti mi doluyor? (max_connections)
Bağlantılar gerçekten çoğalıyor mu, yoksa bekleme yüzünden mi artıyor?
Hangi kullanıcı/host/application pattern’i tetikliyor?

MySQL tarafında hızlı kontrol komutları

Aşağıdaki sorgular, anlık durumu görmenizi sağlar.

Bağlantı sayısı ve limite yakınlık

SHOW VARIABLES LIKE 'max_connections';
SHOW STATUS LIKE 'Threads_connected';
SHOW STATUS LIKE 'Threads_running';

Beklenen desen: - Threads_connected artıp max limiti yakınsadığında “Too many connections” beklenebilir. - Threads_running düşük ama bağlantı sayısı yüksekse, çoğu bağlantı beklemede kalıyor olabilir (ör. transaction/lock durumu, yavaş sorgular).

Hangi sorgular/işlemler bağlantıyı kilitliyor?

Aşağıdaki iki yaklaşım pratikte en hızlı sonucu verir.

(A) processlist ile görünürlük

SHOW FULL PROCESSLIST;

Burada şu alanlara odaklanın: - Command: “Sleep” ise bağlantı açık kalmış demektir. - Time: bağlantı/işlem ne kadar süredir sürüyor. - State: beklenen kilit/IO durumu. - Info: çalışan sorgu (mümkünse).

“Sleep” birikimi özellikle şu sebeplere işaret eder: - Uygulama her istek için yeni bağlantı açıyor. - Bağlantı havuzu kullanılıyor ama yanlış kapatılıyor. - “Connection close” yerine “disable autocommit/transaction” açık kalıyor.

(B) Performans şablonları: yavaş sorgu ve lock birikimi

Bağlantı sayısı artışıyla birlikte CPU yükselmesi ve sorgu süresi uzaması varsa, kök neden “çok bağlantı” değil “çok yavaş iş” olabilir. Yavaş sorgu, aynı anda daha fazla thread’in beklemesine yol açar.

2) En sık kök nedenler (net teşhis listesi)

2.1 Bağlantı havuzu yok veya yanlış kullanılıyor

MySQL’e her HTTP isteği için yeni bağlantı açmak, yüksek trafikte hızlıca bağlantı limitini doldurur.

Doğru yaklaşım: - Uygulama tarafında connection pooling kullanın. - Havuz boyutunu (max pool size) MySQL’in kaldırabileceği bağlantı sayısıyla uyumlu ayarlayın.

Örnek net kontrol: - Uygulama sunucusunda kaç worker var? - Her worker kaç eş zamanlı DB çağrısı yapıyor? - Havuz boyutu kaç?

Bu değerler toplamda MySQL’deki bağlantı ihtiyacını belirler.

2.2 Bağlantılar kapatılmıyor (leak)

“Too many connections” yaşayan sistemlerde çok sık görülen durum: kod yolu bazı exception’larda bağlantıyı kapatmıyor.

Belirtiler: - SHOW FULL PROCESSLIST içinde “Sleep” bağlantılar birikir. - Aynı süre sonunda bağlantı sayısı düşmüyorsa, kapatma mekanizması çalışmıyor olabilir.

Net çözüm: - Try/finally benzeri kapanış garantisi. - ORM kullanıyorsanız “session”/“entity manager” yaşam döngüsü doğru mu kontrol edin.

2.3 Uzun transaction / lock beklemeleri

Transaction açık kalır veya lock beklenirse, thread’ler serbest bırakılmadığından bağlantı birikir.

Belirtiler: - State alanlarında lock/transaction beklemeleri görünür. - Threads_running de yükselir.

Net çözüm: - Transaction kapsamını küçültün. - İlgili tablo/indeksleri kontrol edin. - Kilitli query’leri tespit edip optimize edin.

## 3) max_connections artırmak neden tek başına çözüm değil?

Bazı ekipler direkt max_connections yükseltir. Bu yaklaşım kısa vadede “hata kesilebilir” etkisi gösterebilir; ancak uzun vadede şu riskleri doğurur:

Her bağlantı memory ve thread kaynak tüketir.
Çok bağlantı, sorguların kuyrukta beklemesine ve genel performansın düşmesine neden olabilir.
DB sunucusu kapasitesi yerine sistemde başka darboğazlar ortaya çıkar.

Net kural: - max_connections artırımı, uygulama/konfigürasyon kaynaklı kök nedeni düzeltmeden kalıcı çözüm olmaz.

Ne zaman artırmak mantıklıdır?

Aşağıdaki şartlar varsa artırma geçici/opsiyonel olabilir: - Bağlantı sayısı stabil artmıyor; sadece trafik tepe anında çok kısa süre limit aşılıyor. - Uygulama pooling’i doğru çalışıyor. - Sorgu performansı normal; connection wait pattern’i yok.

Bu durumda hedefiniz: tepe anı güvenli şekilde geçirip kök nedeni paralelde düzeltmek.

4) Net çözüm planı: Uygulama + MySQL ayarlarıyla kalıcı stabilite

Aşağıdaki plan, “bağlantı limiti doluyor” sorununu sistemli şekilde giderir.

4.1 Uygulama tarafında connection pooling’i standart hale getirin

Minimum hedefler: - Havuzdaki bağlantı sayısını (pool size / max pool) kontrol edin. - Her istek için yeni bağlantı açmayın. - Bağlantıyı kullanım sonrası geri havuza verin.

Net kontrol matrisi: - Web/API katmanı kaç process/worker çalıştırıyor? - Her worker aynı anda kaç DB çağrısı yapabilir? - DB pool size toplamı MySQL’in kaldırabileceği bağlantı sayısını aşıyor mu?

Önerilen yaklaşım: - Önce MySQL’de mevcut max limit ve görülen bağlantı sayısını ölçün. - Ardından pooling max değerlerini ona göre kısın/dengeleyin.

4.2 Bağlantı leak tespitini rutinleştirin

Aşağıdaki kontrolleri bir kerelik değil, sistem izleme akışına ekleyin:

SHOW FULL PROCESSLIST ile “Sleep” birikimi trendi
Her deploy sonrası bağlantı davranışında değişim
Error/exception path’lerinde connection kapanıyor mu

4.3 Sorguları optimize ederek beklemeyi azaltın

Bağlantı sayısı arttığında genellikle iki şey olur: ya daha çok bağlantı geliyor, ya da bağlantılar daha uzun süre işgal kalıyor.

Çok yavaş sorgular connection sürelerini uzatır.
Yavaş sorgu sayısı artarsa, aynı havuz boyutunda daha çok thread “occupied” kalır.

Net yapılacaklar: - En uzun çalışan sorguları tespit edin. - Uygun indeksleri ekleyin. - Büyük tabloda sık yapılan filtreleri indeksleyin.

4.4 MySQL yapılandırmasında limitleri kontrollü ayarlayın

Ayar örnekleri (mantık): - max_connections: bağlantı kabul limitidir. - Uzun vadeli plan için buffer/polling uyumunu gözetin.

Uygulama havuzu doğru değilse max_connections yükseltmek sorunu geciktirir, ama genellikle çözmez.

4.5 Otomatik ölçekleme ve yük dağıtımıyla tepe trafiği yönetin

Özellikle API trafiği dalgalıysa, tek DB’nin tüm yükü taşımaması için: - Uygulama katmanında worker sayısını trafiğe göre ayarlayın. - Cache katmanı (yedek sorguları azaltmak) ekleyin.

Bu adımlar “bağlantı başına iş miktarını” düşürür.

## 5) MySQL bağlantı yönetimi için pratik kontrol listesi

Aşağıdaki listeyi, hata tekrar ettiğinde hızlıca uygulayın.

Threads_connected max limiti aşıyor mu, yoksa limitle aynı anda mı yükseliyor?
SHOW FULL PROCESSLIST içinde “Sleep” bağlantılar birikiyor mu?
“State” alanlarında lock/transaction beklemesi görüyor musunuz?
Trafik tepe anında mı oluyor, yoksa sabit yükte mi büyüyor?
Deploy sonrası mı tetikleniyor?
Uygulama tarafında connection pooling var mı ve max değerler MySQL limitlerini aşıyor mu?

Bu maddeler size “uygulama hatası mı, sorgu problemi mi, konfigürasyon mu?” sorusunun net cevabını verir.

6) Örnek senaryolar: Hangi çözüm hangi durumda çalışır?

Senaryo A: Trafik arttıkça aniden bağlantılar şişiyor

Muhtemel kök neden: - Pooling yok veya havuz boyutu çok yüksek.

Net çözüm: - Havuz ekleyin (veya büyüklüğü dengeleyin), “her istek yeni bağlantı” modelini kaldırın. - DB’ye giden çağrı sayısını cache ile azaltın.

Senaryo B: Sürekli “Sleep” bağlantıları artıyor ve inmiyor

Muhtemel kök neden: - Connection leak (kapatılmıyor) veya transaction yanlış yönetiliyor.

Net çözüm: - Kodda bağlantı kapanışını try/finally ile garanti altına alın. - ORM session yaşam döngüsünü gözden geçirin.

Senaryo C: “Too many connections” ile birlikte CPU ve sorgu süresi artıyor

Muhtemel kök neden: - Yavaş sorgu/lock nedeniyle bağlantılar uzun süre işgalde.

Net çözüm: - Uzun sorguları optimize edin, indeksleri kontrol edin. - Transaction süresini kısaltın.

Sonuç: Net aksiyon planı

Önce ölçüm yapın: max_connections, Threads_connected ve SHOW FULL PROCESSLIST ile bağlantıların nasıl davrandığını görün. Ardından kalıcı çözüm için uygulama tarafında connection pooling ve kapanış garantisini düzenleyin; bağlantılar uzun süre işgal oluyorsa sorgu/lock optimizasyonuna odaklanın. Eğer tepe anında kısa süreli limit aşımı varsa max_connections değişikliğini geçici bir emniyet supabı olarak düşünün. Bu sırayla ilerlediğinizde, “Too many connections” sorununu rastgele ayar değiştirerek değil, nedenini hedefleyerek kalıcı şekilde ortadan kaldırırsınız.