MySQL Hatası 2006: MySQL Sunucusu Gitti

Bazı dosyaları işlemek ve sonuçları uzak bir MySQL sunucusuna bildirmek için ofisimde bir sunucu çalıştırıyorum.

Dosyaların işlenmesi biraz zaman alır ve işlem aşağıdaki hatayla yarıya kadar ölür:

2006, MySQL server has gone away

MySQL ayarını duydum, wait_timeout , ama bunu ofisimdeki sunucuda veya uzak MySQL sunucusunda değiştirmem gerekiyor mu?

Bağlantının olup olmadığını kontrol etmek ve gerekirse yeniden kurmak daha kolay olabilir.

Bununla ilgili bilgi için PHP: mysqli_ping adresine bakın .

Bu birkaç kez karşılaştım ve normalde çok düşük bir varsayılan ayar cevabı buldum max_allowed_packet.

Onu /etc/my.cnf(altında [mysqld]) 8 veya 16M'ye yükseltmek genellikle onu düzeltir. (MySql 5.7'deki varsayılan değer 41943044MB'dir.)

[mysqld]
max_allowed_packet=16M

Not: Çizgiyi yoksa oluşturun

Not: Bu, sunucunuzda çalışırken ayarlanabilir.

Kullanın set global max_allowed_packet=104857600. Bu 100MB olarak ayarlar.

Ben aynı sorun ama changeing vardı max_allowed_packetiçinde my.ini/my.cnfaltında dosyanın [mysqld]trick yaptı.

satır ekle

max_allowed_packet = 500M

şimdi bir restart the MySQL servicekez bitti.

Aşağıdaki komutu 7GB'tan daha büyük bir MySQL veritabanını geri yüklemek için MySQL komut satırında kullandım ve işe yarıyor.

set global max_allowed_packet=268435456;

Hata: 2006 ( CR_SERVER_GONE_ERROR )

Mesaj: MySQL sunucusu kayboldu

Genellikle bu sorunu çözmek için tekrar bağlamayı ve sorguyu tekrar yapmayı deneyebilirsiniz - tamamen vazgeçmeden önce 3-4 kez deneyin.

PDO kullandığınızı varsayacağım. Eğer öyleyse, PDO İstisnasını yakalarsınız, bir sayacı arttırırsınız ve sayaç bir eşiğin altındaysa tekrar deneyin.

Zaman aşımına neden olan bir sorgunuz varsa, bu değişkeni yürüterek ayarlayabilirsiniz:

SET @@GLOBAL.wait_timeout=300;
SET @@LOCAL.wait_timeout=300;  -- OR current session only

Burada 300, sorgunun alabileceği en uzun süreyi düşündüğünüz saniye sayısıdır.

Mysql bağlantı sorunlarıyla nasıl başa çıkılacağı hakkında daha fazla bilgi.

EDIT: Ayrıca kullanmak isteyebileceğiniz diğer iki ayar net_write_timeoutve net_read_timeout.

MAMP (profesyonel olmayan versiyonda) ekledim

--max_allowed_packet=268435456

için ...\MAMP\bin\startMysql.sh

Krediler ve daha fazla ayrıntı burada

Bu hata, wait_timeout süresinin dolması nedeniyle oluşur.

Sadece wait_timeout kontrol mysql sunucusuna gidin:

mysql> DEĞERLENDİRMELERİ GÖSTER 'wait_timeout'

mysql> global wait_timeout = 600 # 10 dakika veya ihtiyacınız olan maksimum bekleme süresini ayarlayın

http://sggoyal.blogspot.in/2015/01/2006-mysql-server-has-gone-away.html

Bu hatanın birkaç nedeni vardır.

MySQL / MariaDB ile ilgili:

• wait_timeout - Sunucunun bağlantının kapanmadan önce etkinleşmesini beklediği saniye cinsinden süre.
• interactive_timeout - Sunucunun etkileşimli bir bağlantı beklediği saniye cinsinden süre.
• max_allowed_packet- Bir paketin veya oluşturulan / ara dizenin bayt cinsinden maksimum boyutu. 1024'ün katları halinde en büyük BLOB kadar büyük olarak ayarlanır.

My.cnf örneği :

[mysqld]
# 8 hours
wait_timeout = 28800
# 8 hours
interactive_timeout = 28800
max_allowed_packet = 256M

Sunucuyla ilgili:

• Sunucunuzda tam bellek var - RAM ile ilgili bilgileri kontrol edin free -h

Çerçeve ile ilgili:

• Çerçevenizin ayarlarını kontrol edin. Örneğin Django kullanımı CONN_MAX_AGE(bkz. Dokümanlar )

Nasıl hata ayıklanır:

• MySQL / MariaDB değişkenlerinin değerlerini kontrol edin.
  • sql ile: SHOW VARIABLES LIKE '%time%';
  • Komut satırı: mysqladmin variables
• Hatalar için ayrıntı düzeyini açma:
  • mariadb: log_warnings = 4
  • MySQL: log_error_verbosity = 3
• Hata hakkında daha fazla bilgi için dokümanları kontrol edin

Windows'ta xampp kullanan çocuklar bu yolu xampp / mysql / bin / my.ini kullanmalı ve max_allowed_packet ([mysqld] bölümü altında) seçim boyutuna değiştirmelidir. Örneğin

max_allowed_packet=8M

Yine php.ini'de (xampp / php / php.ini) upload_max_filesize seçim boyutunu değiştirin. Örneğin

upload_max_filesize=8M

Bunu keşfetene kadar bana bir süre baş ağrısı verdi. Umarım yardımcı olur.

Aynı hatayı DigitalOcean Ubuntu sunucumda alıyordum.

Ben max_allowed_packet ve wait_timeout ayarlarını değiştirmeyi denedim ama ikisi de sabit.

Sunucumun RAM dışı olduğu ortaya çıktı. 1GB takas dosyası ekledim ve sorunum düzeltildi.

Buna free -hneden olup olmadığını görmek için hafızanızı kontrol edin .

Benim için RAM problemiydi.

12 CPU çekirdeği ve 32 GB RAM'i olan bir sunucuda bile aynı sorunu yaşıyordum. Daha fazla araştırdım ve RAM'i boşaltmaya çalıştım. RAM'i boşaltmak için Ubuntu 14.04'te kullandığım komut:

sync && echo 3 | sudo tee /proc/sys/vm/drop_caches

Ve her şeyi düzeltti. Her saat koşmak için cron altına koydum.

crontab -e

0 * * * * bash /root/ram.sh;

Ve ne kadar boş RAM olduğunu kontrol etmek için bu komutu kullanabilirsiniz:

free -h

Ve böyle bir şey alacaksınız:

             total       used       free     shared    buffers     cached
Mem:           31G        12G        18G        59M       1.9G       973M
-/+ buffers/cache:       9.9G        21G
Swap:         8.0G       368M       7.6G

Benim durumumda open_files_limit, veri dosyalarına mysqld erişimini engelleyen değişkenin düşük değeriydi.

Şunu kontrol ettim:

mysql> SHOW VARIABLES LIKE 'open%';
+------------------+-------+
| Variable_name    | Value |
+------------------+-------+
| open_files_limit | 1185  |
+------------------+-------+
1 row in set (0.00 sec)

Değişkeni büyük değere değiştirdikten sonra sunucumuz tekrar canlıydı:

[mysqld]
open_files_limit = 100000

64Bit WAMPSERVER kullanıyorsanız, lütfen max_allowed_packet'in birden çok örneğini arayın, çünkü WAMP, benim için yanlış olanı güncellediğim için [wampmysqld64] altında ayarlanan değeri değil, [wampmysqld64] altında ayarlanan değeri kullanıyor. Bunu max_allowed_packet = 64M gibi bir şeye ayarlayın.

Umarım bu, diğer Wampserver kullanıcılarına yardımcı olur.

Bu genellikle MySQL sunucusu bağlantı sorunlarını veya zaman aşımlarını gösterir. Genellikle değiştirerek çözülebilir wait_timeout ve max_allowed_packet içinde my.cnf veya benzeri.

Bu değerleri tavsiye ederim:

wait_timeout = 28800

max_allowed_packet = 8 milyon

Vagrant Box için kutuya yeterli bellek ayırdığınızdan emin olun

config.vm.provider "virtualbox" do |vb|
  vb.memory = "4096"
end

Olası olmayan senaryo, istemci ile sunucu arasında TCP sıfırlamayı bağlantıya zorlayan bir güvenlik duvarınız olması.

Bu sorunu yaşadım ve kurumsal F5 güvenlik duvarımızın 5 dakikadan fazla boşta kalan etkin olmayan oturumları sonlandırmak için yapılandırıldığını buldum.

Bir kez daha, bu olası bir senaryodur.

Mysql sunucusunun günlüklerini kontrol etmek her zaman neden iyi bir fikirdir.

Size söyleyecektir.

Xampp sunucusu kullanıyorsanız:

Xampp -> mysql -> bin -> my.ini adresine gidin

Aşağıdaki parametreyi değiştirin:

max_allowed_packet = 500 milyon

innodb_log_file_size = 128M

Bu bana çok yardımcı oldu :)

aşağıdaki ligne uncomment my.ini/my.cnf, bu büyük dosya küçük bir parçaya bölünecek

# binary logging format - mixed recommended
# binlog_format=mixed

TO

# binary logging format - mixed recommended
binlog_format=mixed

Bu hatayı "# 2006 - MySQL sunucusu gitti" çözüm buldum. Çözüm, sadece iki dosyayı kontrol etmeniz gerektiğidir

1. config.inc.php
2. config.sample.inc.php

Bu dosyaların pencerelerdeki yolu

C:\wamp64\apps\phpmyadmin4.6.4

Bu iki dosyada bunun değeri:

$cfg['Servers'][$i]['host']must be 'localhost' .

Benim durumumda:

$cfg['Servers'][$i]['host'] = '127.0.0.1';

olarak değiştir:

"$cfg['Servers'][$i]['host']" = 'localhost';

İkisinde de emin olun:

1. config.inc.php
2. config.sample.inc.php dosyaları 'localhost' olmalıdır.

Ve son set:

$cfg['Servers'][$i]['AllowNoPassword'] = true;

Ardından Wampserver'ı yeniden başlatın.

Phpmyadmin kullanıcı adını ve şifresini değiştirmek için

Phpmyadmin kullanıcı adını ve şifresini config.inc.php dosyası üzerinden doğrudan değiştirebilirsiniz.

Bu iki çizgi

$cfg['Servers'][$i]['user'] = 'root';
$cfg['Servers'][$i]['password'] = '';

Burada yeni kullanıcı adı ve şifre verebilirsiniz. Değişikliklerden sonra dosyayı kaydedin ve WAMP sunucusunu yeniden başlatın.

Ubuntu masaüstümdeki farklı MySQL istemcileri yazılımında Hata 2006 mesajı aldım. JDBC sürücü sürümümün çok eski olduğu ortaya çıktı.

Bu, .sql dosya boyutunuzda bir sorun olabilir.

Xampp kullanıyorsanız. Xampp kontrol paneline gidin -> MySql config tıklayın -> my.ini dosyasını açın.

Paket boyutunu büyütün.

max_allowed_packet = 2M -> 10M

XAMPP kullanıyorsanız daha kolay bir yol var. XAMPP kontrol panelini açın ve mysql bölümündeki yapılandırma düğmesine tıklayın.

Şimdi my.ini dosyasına tıkladığınızda editörde açılacaktır. Max_allowed_packet öğesini istediğiniz boyuta güncelleyin.

Sonra mysql hizmetini yeniden başlatın. Mysql hizmetinde stop'a tıklayın ve tekrar başlat'a tıklayın. Birkaç dakika bekleyin.

Sonra Mysql sorgunuzu yeniden çalıştırmayı deneyin. Umarım işe yarar.

MAMP 5.3, my.cnf dosyasını bulamazsınız ve max_allowed_packet değişkenlerde saklandığından bunları eklemek işe yaramaz.

Bir çözüm olabilir:

1. Http: // localhost / phpmyadmin adresine gidin
2. SQL sekmesine git
3. DEĞİŞKENLERİ GÖSTER seçeneğini çalıştırın ve değerleri kontrol edin, eğer küçükse büyük değerlerle çalıştırın

4. Aşağıdaki sorguyu çalıştırın, max_allowed_packet değerini 7 gb olarak ayarlar:

   set global max_allowed_packet = 268435456;

Bazıları için aşağıdaki değerleri de artırmanız gerekebilir:

set global wait_timeout = 600;
set innodb_log_file_size =268435456;

XAMPP kullanan kullanıcılar için C: \ xampp \ mysql \ bin \ my.ini dosyasında 2 max_allowed_packet parametresi vardır.

Bu hata temel olarak iki nedenden kaynaklanmaktadır.

1. Çok düşük RAM'iniz var.
2. Bağlanmaya çalıştığınızda veritabanı bağlantısı kapatılır.

Bu kodu aşağıda deneyebilirsiniz.

# Simplification to execute an SQL string of getting a data from the database
def get(self, sql_string, sql_vars=(), debug_sql=0):
    try:            
        self.cursor.execute(sql_string, sql_vars)
        return self.cursor.fetchall()
    except (AttributeError, MySQLdb.OperationalError):
        self.__init__()
        self.cursor.execute(sql_string, sql_vars)
        return self.cursor.fetchall()

Özellikle ikinci nedenden dolayı, nedeni ne olursa olsun hatayı azaltır.

Düşük RAM'den kaynaklanıyorsa, veritabanı bağlantı verimliliğini koddan, veritabanı yapılandırmasından yükseltmeniz veya RAM'i yükseltmeniz gerekir.

Bunun herkese yardımcı olması durumunda:

Uygulamanın çeşitli bölümlerinden çağrılacak bir işlevde bağlantıları açıp kapattığımda bu hatayı aldım. Çok fazla bağlantımız var, bu nedenle mevcut bağlantıyı yeniden kullanmanın veya atmanın ve böyle yeni bir bağlantı kurmanın iyi bir fikir olabileceğini düşündük:

  public static function getConnection($database, $host, $user, $password)
 {
 if (!self::$instance) {
  return self::newConnection($database, $host, $user, $password);
 } elseif ($database . $host . $user != self::$connectionDetails) {

self :: $ instance-> query ('KILL CONNECTION_ID ()'); self :: $ instance = null; return self :: newConnection ($ veritabanı, $ host, $ user, $ password); } kendi kendine dönüş :: $ bulut sunucusu; } Öyle görünüyor ki, öldürme konusunda biraz fazla titiz olduk ve eski bağlantıda önemli şeyler yapan süreçler işlerini asla bitiremez. Bu satırları bıraktık

  self::$instance->query('KILL CONNECTION_ID()');
  self::$instance = null;

ve makinenin donanımı ve kurulumu izin verdiğinden, sunucudaki izin verilen bağlantı sayısını ekleyerek

max_connections = 500

yapılandırma dosyamıza. Bu, şimdilik sorunumuzu düzeltti ve mysql bağlantılarını öldürme hakkında bir şeyler öğrendik.

Bir süredir çevrimdışı olduğunuzu biliyorsanız, bağlantınızı kapatabilir, işleminizi yapabilir, raporlarınızı yeniden bağlayabilir ve yazabilirsiniz.