Mehmet

WFN Üye
Konular
1,851
Mesajlar
1,852
Çözüm
0
Ticaret Puanı
0
Üyelik
1 Ay 6 Gün
Konum
YurtDışı
Web Sitesi
Var
Alanı
Google Adsense
1/1
Konu sahibi

MySQL Server Has Gone Away hatası ne demektir?​


“MySQL Server Has Gone Away” hatası, uygulamanın MySQL sunucusuyla kullandığı bağlantının işlem sırasında kapanmış veya artık kullanılamaz hâle gelmiş olduğunu gösterir. Bu, her zaman MySQL servisinin tamamen durduğu anlamına gelmez. En yaygın nedenler bağlantının uzun süre boşta kalması, gönderilen veri paketinin izin verilen sınırı aşması, ağ kopması, sunucunun yeniden başlaması veya istemci ile sunucunun bağlantıyı zaman aşımına uğratmasıdır.

Hata çoğunlukla ERROR 2006 (HY000): MySQL server has gone away biçiminde görülür. Benzer durumda sorgu çalışırken bağlantı koparsa Lost connection to MySQL server during query mesajı da alınabilir. İki durumda da ilk iş, aynı bağlantıyı tekrar kullanmak yerine yeni bir bağlantı açıp sorunun tekrarlanıp tekrarlanmadığını kontrollü biçimde incelemektir.

Hata nasıl oluşur?​


MySQL bağlantısı, istemci ile sunucu arasında açık tutulan bir iletişim kanalıdır. İstemci sorgu gönderir, sunucu sonucu döndürür ve bağlantı kullanılmaya devam eder. Şu durumlardan biri bu kanalı bozabilir:

  • Uzun süre boşta kalan bağlantı: Sunucu veya bağlantı havuzu, kullanılmayan bağlantıyı kapatabilir. Uygulama daha sonra aynı bağlantıyı kullanmaya çalışır.
  • Büyük istek veya sonuç: Büyük bir BLOB, uzun bir metin, toplu ekleme veya büyük bir sorgu paketi max_allowed_packet sınırını aşabilir.
  • Ağ veya proxy sorunu: Uygulama ile MySQL arasındaki ağ bağlantısı kesilebilir ya da aradaki proxy bağlantıyı kapatabilir.
  • Sunucu tarafı olay: MySQL yeniden başlatılmış, durmuş veya bellek/disk gibi bir kaynak sorunu nedeniyle bağlantıyı sonlandırmış olabilir.
  • Çok uzun işlem: Büyük bir sorgunun çalışması sırasında istemci, sunucu veya ara ağ katmanı bağlantıyı zaman aşımına uğratabilir.

Örneğin uygulama gece boyunca havuzdaki bir bağlantıyı boşta tutuyor, sabah da aynı bağlantıyla sorgu çalıştırıyorsa hata oluşabilir. Buna karşılık hata yalnızca büyük bir dosya veya uzun metin eklenirken çıkıyorsa öncelikle paket boyutu ve veri aktarımı incelenmelidir.

Tanı koyma ve uygulanabilir çözüm​


Aşağıdaki adımları hatanın görüldüğü istemci ve sunucu bilgileriyle birlikte uygulayın. Değerleri körlemesine yükseltmek yerine hangi durumda hata oluştuğunu not edin.

  1. Hatanın zamanını, hassas değerleri ayıklanmış sorgu biçimini ve işlem türünü kaydedin. Hata her sorguda görülüyorsa bağlantı veya sunucu durumu; yalnızca büyük veri aktarımında görülüyorsa paket boyutu daha olasıdır.
  2. Yeni bir MySQL bağlantısı açıp basit bir kontrol sorgusu çalıştırın:
    Kod:
    SELECT 1;
    Sorgu başarılıysa sunucu o yeni bağlantıya yanıt verebiliyordur; uygulamanın kopmuş bağlantıyı yeniden kullanmadığından emin olun. Yeni bağlantı da kurulamıyorsa sunucu durumu, kimlik doğrulama, ağ ve erişim ayarlarını inceleyin.
  3. Sunucunun ilgili ayarlarını kontrol edin:
    Kod:
    SHOW VARIABLES
    WHERE Variable_name IN
    ('wait_timeout', 'interactive_timeout', 'max_allowed_packet',
     'net_read_timeout', 'net_write_timeout');
    Bu sorgu varsayılan olarak oturum değerlerini gösterebilir; global ayarı değiştirmek mevcut bağlantının değerini her zaman değiştirmez. Çıktı, boşta bekleme, paket ve veri aktarımı sınırları hakkında ipucu verir. Bu değerlerin uygun olup olmadığı kullanılan istemciye, veri boyutuna ve bağlantı mimarisine bağlıdır.
  4. Hata büyük veri gönderirken oluşuyorsa gönderilen kaydı veya toplu işlemi küçültüp yeniden deneyin. Sorunun küçültülen işlemde kaybolması boyut veya çalışma süresiyle ilişkiye işaret eder; paket sınırını aştığını günlük ve boyut ölçümüyle doğrulayın. Gerekirse max_allowed_packet değeri istemci ve sunucu tarafında uyumlu olacak şekilde, sunucu yöneticisinin onayıyla düzenlenmelidir.
  5. Hata uzun süre bekledikten sonra oluşuyorsa bağlantı havuzunun kopmuş bağlantıyı kullanmadan önce doğrulama yapmasını ve bağlantı yaşını sınırlamasını sağlayın. Uygulama bağlantıyı yeniden açabilmeli; ancak başarısız bir işlemi otomatik olarak tekrar etmek, özellikle INSERT, UPDATE veya ödeme benzeri yan etkili işlemlerde, mükerrer işlem oluşturabilir.
  6. MySQL hata günlüğünü ve servis yöneticisinin olay kayıtlarını aynı zaman aralığında inceleyin. Yeniden başlatma, çökme, disk doluluğu, bellek baskısı veya bağlantı reddi görülüyorsa yalnızca istemci ayarını değiştirmek sorunu çözmez.
  7. Sorgu çalışırken kopma oluyorsa sorguyu daha küçük parçalara bölün, gereksiz sonuç sütunlarını kaldırın ve işlemin ne kadar sürdüğünü ölçün. Sorun yalnızca belirli bir sorguda devam ediyorsa sorgu planı, kilitlenme ve kaynak kullanımını ayrıca inceleyin.

Ayar değişikliği sonrası yeni bağlantıyla ve asıl hatayı üreten kontrollü işlemle sınayın; SELECT 1 yalnız temel yanıt verebilme durumunu gösterir.

Belirtiye göre ilk odak noktası​


Gözlenen belirtiye göre ilerleyin.

Belirtiİlk kontrolMuhtemel yön
Uzun boşta kalma sonrası hataBağlantı havuzu ve timeout değerleriKapanmış bağlantının yeniden kullanılması
Büyük dosya veya BLOB sırasında hataPaket boyutu ve işlem büyüklüğümax_allowed_packet sınırı
Her bağlantı denemesinde hataServis, ağ ve hata günlükleriSunucuya erişilememe veya servis sorunu
Uzun sorgunun ortasında hataSorgu süresi, proxy ve kaynak kullanımıZaman aşımı, ağ kopması veya sunucu baskısı

Sık yapılan hatalar​


Sadece wait_timeout değerini artırmak her durumu çözmez; hata büyük paketten veya sunucunun yeniden başlamasından kaynaklanıyorsa etkisiz kalır. Benzer şekilde max_allowed_packet değerini sınırsız biçimde büyütmek bellek kullanımını artırabilir ve asıl veri aktarımı tasarım sorununu gizleyebilir. Daha doğru yaklaşım, tek seferde taşınan veriyi küçültmek, bağlantı havuzunun yaşam döngüsünü düzeltmek ve sunucu günlüklerini istemci hatasıyla aynı zaman aralığında karşılaştırmaktır.

Yazma işlemlerinde tekrar denemeden önce önceki işlemin tamamlanma durumunu ve mükerrer kaydı önleyen anahtarları doğrulayın.

Sık sorulan sorular​


wait_timeout uzun çalışan sorgunun süre sınırı mıdır?​


Hayır. Bu değişken bağlantının boşta kalmasıyla ilgilidir. Çalışan sorgunun ortasındaki kopmada istemci/proxy zaman aşımı, aktarım ve sunucu günlüklerini ayrıca inceleyin; wait_timeout artırmak genel sorgu süresi çözümü değildir.

Bağlantıyı tekrar açmak tek başına yeterli midir?​


Yalnızca geçici bir kopma veya bayat bağlantı söz konusuysa yeterli olabilir. Büyük paket, timeout, sunucu çökmesi veya ağ sorunu devam ediyorsa yeni bağlantı da aynı hatayı verir.

Hata alınca sorguyu otomatik yeniden çalıştırabilir miyim?​


Her sorgu için güvenli değildir. Okuma sorguları genellikle daha kolay değerlendirilebilir; yazma işlemlerinde ise ilk denemenin kısmen veya tamamen tamamlanmış olabileceği varsayılmalı ve mükerrer kayıtları önleyecek bir tasarım kullanılmalıdır.
 

Sende şimdi bize katılmak ister misin?

Kayıt ol

Bize katılım kolay ve ücretsizdir!

Konuyu görüntüleyenler

Bu konuyu şu anda görüntüleyen üye bulunmuyor.
Robotlar:
  • Anthropic