MySQL-fout 2006: mysql-server is verdwenen

Ik gebruik een server op mijn kantoor om enkele bestanden te verwerken en de resultaten te rapporteren aan een externe MySQL-server.

Het verwerken van de bestanden duurt even en het proces stopt halverwege met de volgende fout:

2006, MySQL server has gone away

Ik heb gehoord over de MySQL-instelling, wait_timeout, maar moet ik dat wijzigen op de server op mijn kantoor of de externe MySQL-server?

Antwoord 1, autoriteit 100%

Het is misschien gemakkelijker om te controleren of de verbinding is gemaakt en indien nodig opnieuw tot stand te brengen.

Zie PHP:mysqli_pingvoor informatie hierover.

Antwoord 2, autoriteit 91%

Ik ben dit een aantal keer tegengekomen en normaal gesproken vond ik het antwoord een zeer lage standaardinstelling van max_allowed_packet.

Verhogen in /etc/my.cnf(onder [mysqld]) naar 8 of 16M lost het meestal op. (De standaardwaarde in MySql 5.7 is 4194304, wat 4 MB is.)

[mysqld]
max_allowed_packet=16M

Opmerking: maak gewoon de regel aan als deze niet bestaat

Opmerking: dit kan worden ingesteld op uw server terwijl deze actief is.

Gebruik set global max_allowed_packet=104857600. Dit stelt het in op 100 MB.

Antwoord 3, autoriteit 91%

Ik had hetzelfde probleem, maar het wijzigen van max_allowed_packetin het bestand my.ini/my.cnfonder [mysqld]maakte de truc.

voeg een regel toe

max_allowed_packet=500M

Nu restart the MySQL serviceZodra u klaar bent.

Antwoord 4, Autoriteit 117%

Ik heb volgende opdracht in MySQL-opdrachtregel gebruikt om een ​​MySQL-database te herstellen welke maat meer dan 7 GB, en het werkt.

set global max_allowed_packet=268435456;

Antwoord 5, Autoriteit 53%

FOUT: 2006 (CR_SERVER_GONE_ERROR )

Bericht: MySQL Server is verdwenen

Over het algemeen kunt u het aansluiten opnieuw proberen en vervolgens de vraag opnieuw doen om dit probleem op te lossen – probeer als 3-4 keer voordat u volledig opgeven.

Ik neem aan dat u PDO gebruikt. Zo ja, dan zou u de PDO-uitzondering ophalen, een teller verhogen en vervolgens opnieuw proberen als de teller onder een drempel is.

Als u een query hebt die een time-out veroorzaakt, kunt u deze variabele instellen door:

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

waarbij 300 het aantal seconden is dat u denkt dat de maximale tijd de vraag kan nemen.

Meer informatie over het omgaan met MySQL-verbindingskwesties.

EDIT: Twee andere instellingen die u mogelijk wilt gebruiken is net_write_timeouten net_read_timeout.

Antwoord 6, Autoriteit 47%

in mamp (niet-pro-versie) heb ik

toegevoegd

--max_allowed_packet=268435456

naar ...\MAMP\bin\startMysql.sh

Credits en meer details hier

Antwoord 7, autoriteit 36%

Er zijn verschillende oorzaken voor deze fout.

MySQL/MariaDB gerelateerd:

• wait_timeout– Tijd in seconden dat de server wacht tot een verbinding actief wordt voordat deze wordt gesloten.
• interactive_timeout– Tijd in seconden dat de server wacht op een interactieve verbinding.
• max_allowed_packet– Maximale grootte in bytes van een pakket of een gegenereerde/tussenliggende tekenreeks. Stel zo groot in als de grootste BLOB, in veelvouden van 1024.

Voorbeeld van my.cnf:

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

Server gerelateerd:

• Uw server heeft vol geheugen – controleer informatie over RAM met free -h

Raamwerk gerelateerd:

• Controleer de instellingen van uw framework. Django gebruikt bijvoorbeeld CONN_MAX_AGE(zie documenten)

Hoe debuggen:

• Controleer de waarden van MySQL/MariaDB-variabelen.
  • met sql: SHOW VARIABLES LIKE '%time%';
  • opdrachtregel: mysqladmin variables
• Schakel breedsprakigheid in voor fouten:
  • MariaDB: log_warnings = 4
  • MySQL: log_error_verbosity = 3
• Bekijk docs voor meer informatie over de fout

Antwoord 8, autoriteit 33%

Deze fout treedt op vanwege het verlopen van wait_timeout .

Ga gewoon naar de mysql-server en controleer de wait_timeout :

mysql> TOON VARIABELEN ZOALS ‘wait_timeout’

mysql> set global wait_timeout = 600 # 10 minuten of maximale wachttijd
uit je nodig hebt

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

Antwoord 9, autoriteit 31%

In Windows zouden die gasten die xampp gebruiken dit pad xampp/mysql/bin/my.ini moeten gebruiken en max_allowed_packet(onder sectie[mysqld]) moeten wijzigen in de grootte van uw keuze.
bijv.

max_allowed_packet=8M

Opnieuw op php.ini(xampp/php/php.ini) verander upload_max_filesize de keuzegrootte.
bijv.

upload_max_filesize=8M

Ik kreeg er een tijdje hoofdpijn van totdat ik dit ontdekte. Ik hoop dat het helpt.

Antwoord 10, autoriteit 28%

Als je de xampp-server gebruikt:

Ga naar xampp -> mysql -> bin -> mijn.ini

Wijzig onderstaande parameter:

max_allowed_packet = 500M

innodb_log_file_size = 128M

Dit heeft me erg geholpen 🙂

Antwoord 11, autoriteit 28%

Ik kreeg dezelfde fout op mijn DigitalOcean Ubuntu-server.

Ik heb geprobeerd de instellingen voor max_allowed_packet en wait_timeout te wijzigen, maar geen van beide heeft het opgelost.

Het blijkt dat mijn server geen RAM meer had. Ik een wisselbestand van 1 GB toegevoegd en dat loste mijn probleem op.

Controleer je geheugen met free -hom te zien of dat de oorzaak is.

Antwoord 12, autoriteit 25%

Het was een RAM-probleem voor mij.

Ik had hetzelfde probleem, zelfs op een server met 12 CPU-kernen en 32 GB RAM. Ik heb meer onderzocht en geprobeerd RAM vrij te maken. Hier is de opdracht die ik op Ubuntu 14.04 heb gebruikt om RAM vrij te maken:

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

En het loste alles op. Ik heb het onder cron zo ingesteld dat het elk uur wordt uitgevoerd.

crontab -e
0 * * * * bash /root/ram.sh;

En u kunt deze opdracht gebruiken om te controleren hoeveel vrije RAM beschikbaar is:

free -h

En je krijgt zoiets als dit:

            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

Antwoord 13, autoriteit 17%

In mijn geval was het een lage waarde van de variabele open_files_limit, die de toegang van mysqld tot gegevensbestanden blokkeerde.

Ik heb het gecontroleerd met :

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

Nadat ik de variabele in grote waarde had veranderd, leefde onze server weer:

[mysqld]
open_files_limit = 100000

Antwoord 14, autoriteit 17%

Als je de 64-bits WAMPSERVER gebruikt, zoek dan naar meerdere exemplaren van max_allowed_packetomdat WAMP de waarde gebruikt die is ingesteld onder [wampmysqld64] en niet de waarde die is ingesteld onder [mysqldump], wat voor mij de probleem, ik was de verkeerde aan het updaten. Stel dit in op iets als max_allowed_packet = 64M.

Hopelijk helpt dit andere Wampserver-gebruikers die er zijn.

Antwoord 15, autoriteit 17%

Dit duidt doorgaans op verbindingsproblemen of time-outs van MySQL-server.
Kan over het algemeen worden opgelost door wait_timeouten max_allowed_packetin my.cnfof iets dergelijks te wijzigen.

Ik stel deze waarden voor:

wait_timeout = 28800

max_allowed_packet = 8M

Antwoord 16, autoriteit 14%

Het is altijd een goed idee om de logs van de Mysql-server te controleren op de reden waarom deze is verdwenen.

Het zal je vertellen.

Antwoord 17, autoriteit 14%

Er is een eenvoudigere manier als u XAMPP gebruikt.
Open het XAMPP-configuratiescherm en klik op de configuratieknop in het mysql-gedeelte.

Klik nu op de my.ini en deze wordt geopend in de editor. Werk het max_allowed_packet bij naar de gewenste grootte.

Herstart vervolgens de mysql-service. Klik op stop op de Mysql-service klik opnieuw op start. Wacht een paar minuten.

Probeer vervolgens uw Mysql-query opnieuw uit te voeren. Hoop dat het zal werken.

Antwoord 18, autoriteit 14%

MAMP 5.3, u zult my.cnf niet vinden en het toevoegen ervan werkt niet omdat het max_allowed_packet wordt opgeslagen in variabelen.

Een oplossing kan zijn:

1. Ga naar http://localhost/phpmyadmin
2. Ga naar het tabblad SQL
3. Voer SHOW VARIABLES uit en controleer de waarden, als het klein is, voer dan uit met grote waarden

4. Voer de volgende query uit, het stelt max_allowed_packet in op 7 gb:

   stel globaal max_allowed_packet=268435456 in;

Voor sommigen moet u mogelijk ook de volgende waarden verhogen:

set global wait_timeout = 600;
set innodb_log_file_size =268435456;

Antwoord 19, autoriteit 11%

Zorg er voor Vagrant Box voor dat u voldoende geheugen aan de box toewijst

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

Antwoord 20, autoriteit 11%

Het onwaarschijnlijke scenario is dat u een firewall tussen de client en de server hebt die de TCP-reset in de verbinding dwingt.

Ik had dat probleem en ontdekte dat onze zakelijke F5-firewall was geconfigureerd om inactieve sessies te beëindigen die langer dan 5 minuten inactief waren.

Nogmaals, dit is het onwaarschijnlijke scenario.

Antwoord 21, autoriteit 11%

Dit kan een probleem zijn met uw .sql-bestandsgrootte.

Als u xampp. Ga naar het xampp-configuratiescherm -> Klik op MySql-configuratie -> Open mijn.ini.

Vergroot de pakketgrootte.

max_allowed_packet = 2M -> 10M

Antwoord 22, autoriteit 8%

uncommentaar de ligne hieronder in uw my.ini/my.cnf, dit zal uw grote bestand in kleinere delen splitsen

# binary logging format - mixed recommended
# binlog_format=mixed

NAAR

# binary logging format - mixed recommended
binlog_format=mixed

Antwoord 23, autoriteit 8%

Ik heb de oplossing gevonden voor “#2006 – MySQL-server is verdwenen” deze fout.
De oplossing is dat u alleen twee bestanden moet controleren

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

Pad van deze bestanden in Windows is

C:\wamp64\apps\phpmyadmin4.6.4

In deze twee bestanden de waarde hiervan:

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

In mijn geval was het:

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

wijzig het in:

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

Zorg ervoor dat in beide:

1. config.inc.php
2. config.sample.inc.php-bestanden moet ‘localhost’ zijn.

En laatste set:

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

Herstart vervolgens Wampserver.

De gebruikersnaam en het wachtwoord van phpmyadmin wijzigen

U kunt de gebruikersnaam en het wachtwoord van PHPMYADMIN direct wijzigen via Config.inc.php-bestand

Deze twee regels

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

Hier kunt u een nieuwe gebruikersnaam en wachtwoord geven.
Nadat wijzigingen het bestand opslaan en WAMP Server opnieuw opstarten.

Antwoord 24, Autoriteit 6%

Ik heb fout 2006 bericht in verschillende MySQL-clientsoftware op mijn Ubuntu-desktop. Het bleek dat mijn JDBC-stuurprogramma-versie te oud was.

Antwoord 25, Autoriteit 3%

Deze fout gebeurt in principe om twee redenen.

1. Je hebt een te lage ram.
2. De databaseverbinding is gesloten wanneer u probeert verbinding te maken.

U kunt deze code hieronder proberen.

# 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()

Het bepaalt de fout, ongeacht de reden erachter, vooral voor de tweede reden.

Als het wordt veroorzaakt door laag RAM, moet u ofwel de efficiëntie van de databaseverbinding uit de code verhogen, van de databaseconfiguratie, of eenvoudigweg de RAM verhogen.

Antwoord 26, Autoriteit 3%

Ik had hetzelfde probleem in Docker toevoegen hieronder instelling in docker-compose.yml:

db:
    image: mysql:8.0
    command: --wait_timeout=800 --max_allowed_packet=256M --character-set-server=utf8 --collation-server=utf8_general_ci --default-authentication-plugin=mysql_native_password
    volumes:
      - ./docker/mysql/data:/var/lib/mysql
      - ./docker/mysql/dump:/docker-entrypoint-initdb.d
    ports:
      - 3306:3306
    environment:
      MYSQL_ROOT_PASSWORD: ${MYSQL_ROOT_PASSWORD}
      MYSQL_DATABASE: ${MYSQL_DATABASE}
      MYSQL_USER: ${MYSQL_USER}
      MYSQL_PASSWORD: ${MYSQL_PASSWORD}

Antwoord 27, autoriteit 3%

Ik ben deze fout ook tegengekomen. Maar zelfs met het verhoogde max_allowed_packetof enige verhoging van de waarde in my.cnf, blijft de fout bestaan.

Wat ik deed, is problemen met mijn database oplossen:

• Ik heb de tabellen gecontroleerd waar de fout zich blijft voordoen
• Vervolgens controleerde ik elke rij
• Er zijn rijen die goed kunnen worden opgehaald en er zijn rijen waar de fout alleen verschijnt
• Het lijkt erop dat er waarde in deze rijen is die deze fout veroorzaakt
• Maar zelfs door alleen de primaire kolom te selecteren, verschijnt de fout nog steeds (SELECT primary_id FROM table)

De oplossing waar ik aan dacht is om de database opnieuw te importeren. Gelukkig heb ik een back-up van deze database. Maar ik liet alleen de problematische tabel vallen en importeerde vervolgens mijn back-up van deze tabel. Dat loste mijn probleem op.

Mijn oplossing voor dit probleem:

• Houd altijd een back-up van uw database. Handmatig of via CRON-taak
• Ik heb gemerkt dat er speciale tekens in de betreffende rijen staan. Dus toen ik de tabel herstelde, veranderde ik onmiddellijk de sortering van deze tabel van latin1_swedish_ciin utf8_general_ci
• Mijn database werkte prima voordat mijn systeem plotseling met dit probleem te maken kreeg. Misschien heeft het ook iets te maken met de upgrade van de MySQL-database door onze hostingprovider. Dus frequente back-up is een must!

Antwoord 28

Voor gebruikers die XAMPP gebruiken, zijn er 2 max_allowed_packetparameters in C:\xampp\mysql\bin\my.ini.

Antwoord 29

Voor het geval dit iemand helpt:

Ik kreeg deze foutmelding toen ik verbindingen opende en sloot in een functie die vanuit verschillende delen van de applicatie zou worden aangeroepen.
We hebben te veel verbindingen, dus het leek ons een goed idee om de bestaande verbinding opnieuw te gebruiken of weg te gooien en een nieuwe te maken, zoals:

   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($database, $host, $user, $password);
    }
      return self::$instance;
    }

Het blijkt dat we een beetje te grondig zijn geweest met het doden en dus konden de processen die belangrijke dingen doen op de oude verbinding hun werk nooit afmaken.
Dus we hebben deze regels laten vallen

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

en aangezien de hardware en configuratie van de machine dit toelaten, hebben we het aantal toegestane verbindingen op de server verhoogd door toe te voegen

max_connections = 500

naar ons configuratiebestand. Dit loste ons probleem voor nu op en we hebben iets geleerd over het uitschakelen van mysql-verbindingen.

Antwoord 30

Als u weet dat u een tijdje offline gaat, kunt u uw verbinding verbreken, uw verwerking doen, opnieuw verbinding maken en uw rapporten schrijven.