HATA 2006 (HY000): MySQL sunucusu kullanımdan kaldırıldı

Ben büyük bir SQL dosyası (büyük bir INSERTsorgu) kaynak çalıştığınızda bu hatayı alıyorum .

mysql>  source file.sql
ERROR 2006 (HY000): MySQL server has gone away
No connection. Trying to reconnect...
Connection id:    2
Current database: *** NONE ***

ERROR 2006 (HY000): MySQL server has gone away
No connection. Trying to reconnect...
Connection id:    3
Current database: *** NONE ***

Tablodaki hiçbir şey güncellenmiyor. MySQL'i yeniden başlatmanın yanı sıra tablo / veritabanını silmeyi ve silmeyi denedim. Bunların hiçbiri sorunu çözmüyor.

İşte benim maksimum paket boyutum:

+--------------------+---------+
| Variable_name      | Value   |
+--------------------+---------+
| max_allowed_packet | 1048576 |
+--------------------+---------+

İşte dosya boyutu:

$ ls -s file.sql 
79512 file.sql

Diğer yöntemi denediğimde ...

$ ./mysql -u root -p my_db < file.sql
Enter password: 
ERROR 2006 (HY000) at line 1: MySQL server has gone away

max_allowed_packet=64M

Bu satırı my.cnfdosyaya eklemek sorunumu çözer.

Bu, sütunlara neden olan büyük değerlere sahip olduğunda yararlıdır, açıklamayı burada bulabilirsiniz .

Windows'da bu dosya şu konumda bulunur: "C: \ ProgramData \ MySQL \ MySQL Server 5.6"

Linux'ta (Ubuntu): / etc / mysql

İzin Verilen Maksimum Paketi artırabilirsiniz

SET GLOBAL max_allowed_packet=1073741824;

http://dev.mysql.com/doc/refman/5.5/en/server-system-variables.html#sysvar_max_allowed_packet

Genel güncelleştirme ve my.cnf ayarları bir nedenden dolayı benim için çalışmadı. Geçme max_allowed_packetmüşteriye doğrudan değerini burada çalıştı:

mysql -h <hostname> -u username -p --max_allowed_packet=1073741824 <databasename> < db.sql

Genel olarak hata:

Hata: 2006 ( CR_SERVER_GONE_ERROR) - MySQL sunucusu kullanımdan kaldırıldı

istemcinin sunucuya soru gönderemediği anlamına gelir .

mysql ithalat

Özel durumunuzda veritabanı dosyasını üzerinden alırken mysql, bu büyük olasılıkla SQL dosyasındaki sorguların bazılarının içe aktarılamayacak kadar büyük olduğu ve sunucuda yürütülemediği anlamına gelir, bu nedenle istemci ilk oluşan hatada başarısız olur.

Yani aşağıdaki olasılıklara sahipsiniz:

• İçin kuvvet ekle seçeneği ( -f)mysqlDevam etmek ve sorguların geri kalanını yürütmek .

  Veritabanının önbellekle ilgili zaten önemli olmayan bazı büyük sorguları varsa yararlıdır.

• Artırın max_allowed_packetvewait_timeout sunucu yapılandırmanızda (örn. ~/.my.cnf).

• --skip-extended-insertBüyük sorguları yıkmak için seçeneği kullanarak veritabanını boşaltın. Sonra tekrar içe aktarın.

• İçin --max-allowed-packetseçenek uygulamayı deneyin mysql.

Ortak nedenler

Genel olarak bu hata aşağıdakiler gibi birkaç anlama gelebilir:

• sunucuya yapılan bir sorgu yanlış veya çok büyük,

  Çözüm: Değişkeni artırınmax_allowed_packet .

  • Değişkenin [mysqld]bölüm altında olduğundan emin olun [mysql].

  • Test için büyük sayılar kullanmaktan korkmayın (gibi 1G).

  • MySQL / MariaDB sunucusunu yeniden başlatmayı unutmayın.

  • Değerin doğru ayarlandığını iki kez kontrol edin:

    mysql -sve "SELECT @@max_allowed_packet" # or:
    mysql -sve "SHOW VARIABLES LIKE 'max_allowed_packet'"

• İstemci tarafındaki TCP / IP bağlantısından bir zaman aşımı var.

  Çözüm: Değişkeni artırınwait_timeout .

• Sunucu bağlantısı kapatıldıktan sonra bir sorgu çalıştırmayı denediniz.

  Çözüm: Uygulamadaki bir mantık hatası düzeltilmelidir.

• Ana bilgisayar adı aramaları başarısız oldu (örn. DNS sunucusu sorunu) veya sunucu ile başlatıldı --skip-networking seçenek .

  Başka bir olasılık da güvenlik duvarınızın MySQL portunu engellemesidir (örneğin varsayılan olarak 3306).

• Çalışan iplik öldü, tekrar deneyin.

• Sorguyu yürütürken sunucunun öldüğü bir hatayla karşılaştınız.

• Farklı bir ana bilgisayarda çalışan bir istemcinin bağlanmak için gerekli ayrıcalıkları yoktur.

• Ve daha pek çoğu, daha fazla bilgi için: B.5.2.9 MySQL sunucusu yok oldu .

Hata ayıklama

İşte uzman düzeyinde birkaç hata ayıklama fikri:

• Günlükleri kontrol edin, örn.

  sudo tail -f $(mysql -Nse "SELECT @@GLOBAL.log_error")

• Senin aracılığıyla bağlantıyı test mysql, telnetveya ping fonksiyonları (örn mysql_pingPHP'de).

• tcpdumpMySQL iletişimini koklamak için kullanın (soket bağlantısı için çalışmaz), örneğin:

  sudo tcpdump -i lo0 -s 1500 -nl -w- port mysql | strings

• Linux'ta kullanın strace. BSD / Mac kullanımda dtrace/ dtruss, örneğin

  sudo dtruss -a -fn mysqld 2>&1

  Bkz: DTracing MySQL ile çalışmaya başlama

MySQL sunucusunda veya istemcide hata ayıklama hakkında daha fazla bilgi için: 26.5 MySQL Hata Ayıklama ve Taşıma .

Başvuru için, istemci komutunun hatalarını sql-common/client.catmaktan sorumlu dosyadaki kaynak kodunu kontrol edin CR_SERVER_GONE_ERROR.

MYSQL_TRACE(SEND_COMMAND, mysql, (command, header_length, arg_length, header, arg));
if (net_write_command(net,(uchar) command, header, header_length,
          arg, arg_length))
{
  set_mysql_error(mysql, CR_SERVER_GONE_ERROR, unknown_sqlstate);
  goto end;
}

Her ihtimale karşı, değişkenleri kontrol etmek için kullanabilirsiniz

$> mysqladmin variables -u user -p 

Bu, mevcut değişkenleri görüntüler, bu durumda max_allowed_packet ve başka bir cevapta birinin söylediği gibi, geçici olarak

mysql> SET GLOBAL max_allowed_packet=1072731894

Benim durumumda cnf dosyası dikkate alınmadı ve neden bilmiyorum, bu yüzden SET GLOBAL kodu gerçekten yardımcı oldu.

Hatayı ERROR 2006 (HY000) at line 97: MySQL server has gone awayçözdüm ve aşağıdaki iki adımı sırayla uygulayarak> 5GB sql dosyasını başarıyla taşıdım:

1. Diğerlerinin önerdiği gibi /etc/my.cnf, aşağıdaki içeriklerle oluşturuldu:

   [mysql]
   connect_timeout = 43200
   max_allowed_packet = 2048M
   net_buffer_length = 512M
   debug-info = TRUE

2. Bayrakları --force --wait --reconnectkomuta ekleme (yani mysql -u root -p -h localhost my_db < file.sql --verbose --force --wait --reconnect).

Önemli Not: Her iki adımı da uygulamak gerekiyordu, çünkü /etc/my.cnf dosyasında değişiklik yapma ve bu bayrakları eklemeyi zahmet etmediysem, içe aktarmadan sonra bazı tablolar eksikti.

Kullanılan sistem: OSX El Capitan 10.11.5; mysql Ver 14.14 osx10.8 (i386) için 5.5.51 dağıtın

Ben de aynı sorun vardı ama [mysqld] altında my.ini / my.cnf dosyasında max_allowed_packet değiştirmek hile yaptı.

satır ekle

max_allowed_packet=500M

işiniz bittiğinde MySQL hizmetini yeniden başlatın.

Ayrıca veritabanına root (veya SUPER ayrıcalığı) olarak giriş yapabilir ve

set global max_allowed_packet=64*1024*1024;

MySQL yeniden başlatmayı da gerektirmez. my.cnfDosyanızı diğer çözümlerde belirtildiği gibi düzeltmeniz gerektiğini unutmayın :

[mysqld]
max_allowed_packet=64M

Ve MySQL'i yeniden başlattıktan sonra değişikliği onaylayın:

show variables like 'max_allowed_packet';

Komut satırını da kullanabilirsiniz, ancak bu, sistem güncelleştirmelerinde ve düzeltme eklerinden sağ çıkamayan başlatma / durdurma komut dosyalarının güncelleştirilmesini gerektirebilir.

İstendiği gibi buraya kendi cevabımı ekliyorum. Çalıştığını görmek sevindim!

Çözüm, etiketinizde seçenekler dosyanızda verilen değerleri wait_timeoutve connect_timeoutparametreleri arttırmaktır [mysqld].

Ben 400MB mysql yedek kurtarmak zorunda kaldı ve bu benim için çalıştı (aşağıda kullandığım değerler biraz abartılı, ama nokta olsun):

[mysqld]
port=3306
explicit_defaults_for_timestamp = TRUE
connect_timeout = 1000000
net_write_timeout = 1000000
wait_timeout = 1000000
max_allowed_packet = 1024M
interactive_timeout = 1000000
net_buffer_length = 200M
net_read_timeout = 1000000
set GLOBAL delayed_insert_timeout=100000

blockquote

Burada birkaç şey olabilir;

• Sizin INSERTuzun sürüyor ve istemcinizin bağlantısı kesiliyor. Yeniden bağlandığında bir veritabanı seçmez, dolayısıyla hata. Buradaki bir seçenek, toplu iş dosyanızı komut satırından çalıştırmak ve bağımsız değişkenlerdeki veritabanını seçmek;

$ mysql db_name <kaynak.sql

• Bir diğeri, komutunuzu phpveya başka bir dilde çalıştırmaktır. Uzun süren her deyimden sonra, her bir sorgunun başında bağlandığınızdan emin olarak bağlantıyı kapatabilir ve yeniden açabilirsiniz.

Mac kullanıyorsanız ve mysql'i benim gibi demlemek yoluyla yüklediyseniz, aşağıdakiler işe yaradı.

1. cp $(brew --prefix mysql)/support-files/my-default.cnf /usr/local/etc/my.cnf

Kaynak: Homebrew mysql kurulumları için my.cnf nerede?

2. eklemek max_allowed_packet=1073741824için/usr/local/etc/my.cnf

3. mysql.server restart

Mysql kümesini kullandığımda bu hatayla karşılaştım, bu sorunun küme kullanımından olup olmadığını bilmiyorum. Hata tamamen aynı olduğundan, burada çözümümü ver. Veri düğümleri aniden çöktüğü için bu hatayı alıyorum. Ancak düğümler çöktüğünde, cmd'yi kullanarak yine de doğru sonucu alabilirsiniz:

ndb_mgm -e 'ALL REPORT MEMORYUSAGE'

Ve mysqld da düzgün çalışıyor.Bu yüzden ilk önce neyin yanlış olduğunu anlayamıyorum. Ve yaklaşık 5 dakika sonra, ndb_mgm sonucu hiçbir veri düğümü çalışmıyor. Sonra problemin farkındayım. Bu nedenle, tüm veri düğümlerini yeniden başlatmayı deneyin, ardından mysql sunucusu geri döndü ve her şey yolunda.

Ama bir şey benim için garip, bazı sorgular için mysql sunucusunu kaybettikten sonra, cmd gibi kullandığımda show tables, hala gibi dönüş bilgilerini alabilirim 33 rows in set (5.57 sec), ancak tablo bilgisi görüntülenmez.

Amazon RDS için (benim durumum), max_allowed_packetparametre değerini, sahip olabileceğiniz herhangi bir ekteki en büyük veriler için anlamlı olan bayt cinsinden herhangi bir sayısal değerle değiştirebilirsiniz (örneğin: ekinizde 50mb blob değerleriniz varsa, max_allowed_packet64M = 67108864), yeni veya mevcut parameter-group. Ardından bu parametre grubunu MySQL örneğinize uygulayın (örneğin yeniden başlatılması gerekebilir).

Yeniden bağlanıyor ve bağlantı kimliği 2 alınıyorsa, sunucu neredeyse kesinlikle çöktü.

Sunucu yöneticisine başvurun ve sorunu teşhis etmelerini sağlayın. Kötü amaçlı olmayan hiçbir SQL sunucuyu çökmemelidir ve mysqldump çıktısı kesinlikle olmamalıdır.

Muhtemelen sunucu yöneticisinin, mimarinin adres alanı sınırlarından daha büyük veya sanal bellek kapasitesinden daha fazla arabellek boyutu atama gibi bazı büyük operasyonel hatalar yapmış olması muhtemeldir. MySQL hata günlüğü muhtemelen bazı ilgili bilgilere sahip olacaktır; yine de yetkin olmaları halinde bunu izleyeceklerdir.

Bu daha nadir görülen bir sorundur, ancak eğer birisi DB'sini başka bir sunucuya geçirmenin bir yolu olarak tüm / var / lib / mysql dizinini kopyaladıysa bunu gördüm. Çalışmamasının nedeni, veritabanının günlük dosyalarını çalıştırması ve kullanmasıdır. / Var / log / mysql dosyasında günlükler varsa bazen çalışmaz. Çözüm / var / log / mysql dosyalarını da kopyalamaktır.

DB içe aktarma hatası için çözüm arayan Drupal 8 kullanıcıları için:

Sql dökümü dosyasının sonunda "webprofiler" tablosuna veri ekleme komutları olabilir. Bu bazı hata ayıklama günlük dosyası sanırım ve tüm bu kaldırılabilir böylece sitenin çalışması için gerçekten önemli değildir. LOCK TABLES ve UNLOCK TABLES (ve aralarındaki her şey) dahil tüm bu ekleri sildim. Sql dosyasının en altında. Sorun burada açıklanmaktadır:

https://www.drupal.org/project/devel/issues/2723437

Ancak bu tabloyu kesmenin yanı sıra bunun için bir çözüm yok.

BTW Yukarıdaki yanıtlardan tüm çözümleri denedim ve başka hiçbir şey yardımcı olmadı.

Yukarıdaki çözümlerin hepsini denedim, hepsi başarısız oldu.

Ben -h 127.0.0.1varsayılan kullanmak yerine kullanarak sona erdi var/run/mysqld/mysqld.sock.

Bu hata iletisi, SCHEMA'yı, dökümde kullanılandan farklı bir COLLATION ile oluşturduğunuzda da oluşur. Damper içeriyorsa

CREATE TABLE `mytab` (
..
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci;

bunu SCHEMA harmanlamasına da yansıtmalısınız:

CREATE SCHEMA myschema COLLATE utf8_unicode_ci;

Şemada utf8mb4_general_ci kullanıyordum, komut dosyamın yeni bir V8 kurulumundan gelmesine neden oldum, şimdi eski 5.7'de bir DB yükleniyor çöktü ve beni neredeyse çıldırdı.

Yani, belki bu biraz frustating saat tasarrufu yardımcı olur ... :-)

(MacOS 10.3, MySQL 5.7)

Bu cevapların hiçbiri sorunu çözmezse, tabloları kaldırarak ve bunları otomatik olarak bu şekilde tekrar oluşturarak çözdüm:

when creating the backup, first backup structure and be sure of add:
DROP TABLE / VIEW / PROCEDURE / FUNCTION / EVENT
CREATE PROCEDURE / FUNCTION / EVENT
IF NOT EXISTS
AUTO_INCREMENT

o zaman db ile bu yedeklemeyi kullanın ve ihtiyacınız olan tabloları kaldıracak ve yeniden oluşturacaktır.

Sonra sadece veri yedekleme ve aynı şeyi yapmak, ve işe yarayacak.

Mysql istemcisini şu şekilde kullanmaya ne dersiniz:

mysql -h <hostname> -u username -p <databasename> < file.sql