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

MySQL’de görülen "Too many connections" hatası, uygulamanızın veritabanı katmanında tıkanma yaşadığını gösterir. Bu durum sadece bir rahatsızlık değil; doğru yönetilmediğinde performans düşüşü, zaman aşımı (timeout) ve hizmet kesintisiyle sonuçlanır. Bu rehberde, hatanın nereden geldiğini (MySQL ayarları, uygulama bağlantı davranışı, kaynak limitleri) net şekilde ayırt edip çözüm yollarını sıralayacağız. Ayrıca pratikte uygulanacak ayar önerileri ve test yaklaşımı da vereceğiz.

1) Hatanın kökü: Bağlantı limitine neden ulaşılıyor?

"Too many connections" mesajı, MySQL’in yeni bağlantıları kabul edecek kapasiteyi kalmadığında çıkar. Sorunun kaynağı çoğu zaman üç başlıkta toplanır:

• MySQL bağlantı limitine ulaşılıyor: max_connections ayarı doluyor.
• Bağlantılar serbest bırakılmıyor: Uygulama connection’ları kapatmıyor ya da havuz (pool) kullanmıyor.
• Bağlantılar uzun sürüyor: Yoğun sorgular, kilit (lock) beklemeleri veya yavaş query’ler nedeniyle bağlantılar “aktif” kalıyor.

Hızlı teşhis: Gerçek limit ve mevcut bağlantılar

Önce şu bilgileri kontrol edin:

• MySQL’in izin verdiği maksimum bağlantı: max_connections
• Anlık bağlantı sayısı: Threads_connected
• Bekleyen bağlantılar: Threads_connected + bağlantı kuyruğu (varsa)
• Bağlantıların hangi durumda takıldığı: Threads_running

MySQL içinde şu sorgular genellikle yol gösterir:

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

Bu değerler arasında “yakın ilişki” şu şekilde okunur: - Threads_connected ≈ max_connections ise, doğrudan limit dolmuştur. - Threads_connected yüksek ama Threads_running düşükse, bağlantılar “bekleme” durumunda kalıyor olabilir. - Threads_running yüksekse, bağlantılar yoğun sorgularla meşgul demektir.

2) Kısa vadeli müdahale mi, köklü çözüm mü?

“Bağlantı limitini artırmak” çoğu zaman ilk refleks olur. Ancak bu, sorunun kaynağı olan bağlantı yönetimini düzeltmez; sadece tıkanıklığın daha geç yaşanmasına neden olur. En sağlıklı yaklaşım şudur:

1. Sorunun kapsamını ölç: Kaç bağlantı geliyor, pik saatlerde nasıl değişiyor?
2. Bağlantıların davranışını düzelt: Uygulamada havuz kullanımı ve connection kapanışı.
3. Sorgu ve kilit problemlerini çöz: Yavaş query + lock beklemeleri.
4. Gerekirse MySQL tarafında limitleri ayarla: Uygun aralıkla, RAM/CPU/IO kapasitesine göre.

Aşağıdaki tablo, hangi senaryoda hangi yaklaşımın daha doğru olduğuna net bir çerçeve çizer:

3) Uygulama katmanı: Connection pooling ve doğru kapatma

MySQL’e bağlantı aç-kapat yaklaşımı, trafik arttığında hızlıca bağlantı fırtınasına dönüşür. Bu sorunu en çok çözen unsur genellikle connection pooling (bağlantı havuzu) olur.

Connection pool kullanmama neden bu hatayı hızlandırır?

• Her istek yeni connection açar.
• Aynı anda çok istek geldiğinde bağlantılar çoğalır.
• MySQL, bu bağlantılar için thread/worker ayırır; kaynaklar tükenir.

Net kontrol listesi

Uygulama tarafında şu maddeler “standart” olmalıdır:

• Uygulama connection pool kullanır (ör. Java HikariCP, Node.js için pool kütüphaneleri, PHP PDO + pool mimarisi).
• Connection açıldıktan sonra her yol için düzgün kapatılır.
• Timeout’lar (hem uygulama hem DB) makul seviyededir.
• Çok uzun süren sorgular için limit/indeks stratejisi vardır.

Havuz büyüklüğünü (pool size) doğru seçmek

Havuz boyutunu rastgele büyütmek de sorunu yerinden eder. Net yaklaşım:

• MySQL tarafında max_connections artıyorsa, uygulama aynı hızda artan bağlantıları “üretebilir”.
• Bu yüzden pool boyutu; uygulamanın beklenen eşzamanlılık (concurrency) ihtiyacına göre belirlenir.

Genel kural olarak: - Bir uygulama instance’ı için pool boyutu, instance başına beklenen eşzamanlı istekle uyumlu olmalıdır. - Çoklu instance (ör. 4 pod) varsa toplamı düşünmek gerekir.

Örnek hesap (yaklaşık): - 4 uygulama instance - instance başına pool size 20 - toplam hedef bağlantı ≈ 80

Bu toplam, MySQL’in max_connections değerinin ve diğer kullanıcı/servislerin ihtiyacının altında kalmalıdır.

4) MySQL ayarları: max_connections ve eş zamanlılık gerçeği

Bağlantı limitini artırmak kısa vadede hata yüzdesini düşürebilir; ancak bu kararın bedeli vardır: max_connections büyüdükçe MySQL’in yönetmesi gereken thread sayısı artabilir ve RAM/CPU baskısı yükselir.

max_connections nasıl okunur?

• max_connections: Aynı anda kabul edilebilecek maksimum bağlantı.
• Bu ayarı artırırken MySQL’in çalıştığı sunucudaki RAM ve CPU kapasitesi kritik rol oynar.

Pratikte hedef: - “Hata vermeden” çalışabilecek bir kapasiteye ulaşmak - Aynı zamanda sunucuyu thread/konuşturma maliyetleriyle yormamak

İyileştirme yaklaşımı

1. Önce mevcut max_connections ve gerçek bağlantı davranışını ölçün.
2. max_connections artıracaksanız, tek seferde aşırı yükseltmeyin.
3. Paralel olarak sorgu optimizasyonu ve connection pooling’i düzeltin.

5) Yavaş sorgular ve kilitler: Bağlantı sayısı değil süre sorunu

Bağlantı limitini dolduran sadece “kaç bağlantı geldiği” değil; bağlantıların ne kadar süreyle meşgul kaldığıdır. Yavaş sorgu veya lock beklemeleri bağlantıları “aktif” tutar ve sonuçta Threads_running artar.

Ne bakmalı?

• En uzun süren sorgular (slow query log veya APM)
• Sık tekrar eden aynı sorgular
• Lock beklemeleri (transaction davranışları)
• İndeks eksikliği

Net test yöntemi

• Trafik pikine yakın bir zamanda, yavaş query listesini çıkarın.
• Her bir sorgu için EXPLAIN planına bakın.
• Eksik indeks varsa doğru indeksleri ekleyin.

Örnek indeks kontrol mantığı: - WHERE şartlarında kullanılan kolonlar indekslenmiş mi? - JOIN yapılan alanlar indeksli mi? - Sıralama (ORDER BY) ve filtreleme kolonları birlikte çalışıyor mu?

İndeks eklemek genellikle bağlantı sayısını doğrudan azaltmaz; ancak sorgu süresini kısalttığı için bağlantıların daha erken kapanmasını sağlayarak toplam bağlantı baskısını düşürür.

6) Doğru barındırma seçimi: Sunucu kaynakları bağlantı kapasitesini belirler

Bu hatayı sadece yazılımsal ayarlarla çözmek her zaman mümkün olmayabilir. MySQL’in çalıştığı sunucunun disk ve CPU performansı özellikle sorgu süresini etkiler; sorgu uzadıkça bağlantı süresi uzar ve bağlantı limiti daha çabuk dolabilir.

VM/VDS tarafında dikkat edilmesi gerekenler

• RAM: max_connections artınca daha fazla thread kaynak tüketecektir.
• CPU: CPU-bound sorgular thread sayısıyla birleşince hızla tıkanma yaratır.
• Disk (IOPS/latency): Yüksek gecikme, sorgu süresini uzatır.

Bu nedenle bağlantı yönetimini düzeltirken, sunucu tarafında şu kontrol yapılmalıdır: - Disk performansı kararlı mı? (özellikle yoğun IO anlarında) - CPU kullanım piki bağlantı hatasıyla aynı zamana mı denk geliyor? - RAM kullanımı sabit mi yoksa sürekli artış eğiliminde mi?

7) Adım adım uygulama planı (kesin sıralama)

Aşağıdaki plan, “hangi veriyi toplarım → neyi değiştiririm → nasıl doğrularım” şeklinde ilerler.

Adım 1: Veri topla (15-30 dk)

• max_connections
• Threads_connected, Threads_running
• Uygulama tarafında concurrent istek sayısı (istek başına DB işlem sayısı)
• Hatanın saat aralığı ve hangi endpoint’te yoğunlaştığı

Adım 2: Connection pooling ve kapanış hatalarını düzelt (1-4 saat)

• Pool kullanmayan katmanları tespit et
• Connection’ların her koşulda kapandığından emin ol
• Endpoint başına DB çağrı sayısını ölç

Adım 3: Yavaş sorguları indir (yarım gün – 2 gün)

• Slow query log veya APM üzerinden en pahalı sorguları bul
• EXPLAIN ile indeks/plan sorunlarını gider
• Kilit (lock) beklemelerini minimize edecek transaction tasarımını gözden geçir

Adım 4: MySQL limitlerini kontrollü ayarla (30-60 dk)

• max_connections artışı yapacaksanız; RAM ve CPU sınırlarına göre sınırlı bir değer seçin.
• Artışı tek başına çözüm gibi görmeyin; çünkü kök neden düzeltilmezse bağlantı yine dolar.

Adım 5: Doğrula (pik testi)

• Uygulama pik yükünü simüle et
• Hata tekrar ediyor mu?
• Threads_connected tepe yapıyor mu yoksa daha erken normal seviyeye mi dönüyor?

8) Ne zaman “büyütme” (scale-up) veya “bölme” gerekir?

Aşağıdaki şartlarda ölçekleme kararı netleşir:

• Tek bir uygulama instance’ı bile pool boyutuna rağmen bağlantı hızla doluyorsa: kod/DB davranışı sorunu vardır (ölçekleme değil önce düzeltme).
• Bağlantılar kısa ama çok fazla: kullanıcı trafiği ve concurrency gerçek olarak yüksek olabilir; burada doğru havuz boyutu ve doğru sunucu kapasitesi gerekir.
• Sorgular optimize edilemiyor ve yük sürekli: read replica (okuma replikası) veya daha güçlü MySQL kaynak planlaması gündeme gelir.

Sonuç: Bağlantı sızıntısını ve süreyi birlikte düzeltin

"Too many connections" hatasını kalıcı çözümleyecek yaklaşım tek bir ayarı büyütmek değil; bağlantının nasıl açıldığını (pool/kapatma), bağlantının ne kadar süreyle tutulduğunu (yavaş query/lock) ve sunucunun kaynak kapasitesini birlikte yönetmektir. Bugün yapabileceğiniz en net aksiyon: Önce max_connections, Threads_connected ve Threads_running verilerini toplayın; ardından uygulama tarafında connection pool ve kapanış kontrolünü uygulayın; yavaş sorguları azaltıp MySQL limitini kontrollü gözden geçirin.

İsterseniz kullandığınız uygulama dili/çerçevesini ve MySQL’deki mevcut max_connections değerini yazın; buna göre pool boyutu ve ayar aralığını daha net bir planla önerebilirim.