Foutcode: 2013. Verbinding met MySQL-server verbroken tijdens zoekopdracht

Ik kreeg de Foutcode: 2013. Verbinding met MySQL-server verbroken tijdens zoekopdrachttoen ik probeerde een index aan een tabel toe te voegen met MySQL Workbench.
Ik merkte ook dat het verschijnt wanneer ik een lange query uitvoer.

Is er een mogelijkheid om de time-outwaarde te verhogen?


Antwoord 1, autoriteit 100%

Nieuwe versies van MySQL WorkBench hebben een optie om specifieke time-outs te wijzigen.

Voor mij was het onder Bewerken → Voorkeuren → SQL-editor → Time-out voor lezen van DBMS-verbinding (in seconden): 600

De waarde gewijzigd in 6000.

Ook niet-aangevinkte limietrijen omdat het vermoeiend wordt om elke keer dat ik de hele dataset wil doorzoeken een limiet te geven.


Antwoord 2, autoriteit 7%

Als uw zoekopdracht blobgegevens bevat, kan dit probleem worden opgelost door een my.iniwijziging als toe te passen voorgesteld in dit antwoord:

[mysqld]
max_allowed_packet=16M

Standaard is dit 1M (de toegestane maximale waarde is 1024M). Als de opgegeven waarde geen veelvoud van 1024K is, wordt deze automatisch afgerond naar het dichtstbijzijnde veelvoud van 1024K.

Terwijl de thread waarnaar wordt verwezen gaat over de MySQL-fout 2006, heeft het instellen van de max_allowed_packetvan 1M tot 16M deedde 2013-fout verholpen die opdook voor mij bij het uitvoeren van een lange zoekopdracht.

Voor WAMP-gebruikers: u vindt de vlag in het gedeelte [wampmysqld].


Antwoord 3, autoriteit 6%

Start de DB-server met de opdrachtregeloptie net_read_timeout/ wait_timeouten een geschikte waarde (in seconden) – bijvoorbeeld: --net_read_timeout=100.

Zie voor referentie hieren hier.


Antwoord 4, autoriteit 2%

Voeg het volgende toe aan het bestand /etc/mysql/cnf:

innodb_buffer_pool_size = 64M

voorbeeld:

key_buffer              = 16M
max_allowed_packet      = 16M
thread_stack            = 192K
thread_cache_size       = 8
innodb_buffer_pool_size = 64M

Antwoord 5, autoriteit 2%

SET @@local.net_read_timeout=360;

Waarschuwing: het volgende werkt niet wanneer u het toepast in een externe verbinding:

SET @@global.net_read_timeout=360;

Antwoord 6, autoriteit 2%

Je moet de eigenschappen ‘interactive_timeout’ en ‘wait_timeout’ in het mysql-configuratiebestand instellen op de waarden die je nodig hebt.


Antwoord 7, autoriteit 2%

Er zijn drie mogelijke oorzaken voor deze foutmelding

  1. Meestal duidt dit op problemen met de netwerkverbinding en u moet de toestand van uw netwerk controleren als deze fout vaak optreedt
  2. Soms wordt het formulier ‘tijdens zoekopdracht’ gebruikt wanneer miljoenen rijen worden verzonden als onderdeel van een of meer zoekopdrachten.
  3. Zeer zelden kan het gebeuren wanneer de client de eerste verbinding met de server probeert te maken

Voor meer details lees >>

Oorzaak 2:

SET GLOBAL interactive_timeout=60;

van de standaardwaarde van 30 seconden naar 60 seconden of langer

Oorzaak 3:

SET GLOBAL connect_timeout=60;

Antwoord 8

In mijn geval werkte het niet om het time-outinterval voor de verbinding in te stellen op 6000 of iets hoger.

Ik heb net gedaan wat de werkbank zegt dat ik kan doen.

De maximale tijd die de query nodig heeft om gegevens van de DBMS te retourneren. Stel 0 in om de leestime-out over te slaan.

Op Mac
Voorkeuren -> SQL-editor -> Ga naar MySQL-sessie -> stel time-outinterval voor het lezen van de verbinding in op 0.

En het werkt 😄


Antwoord 9

Voer gewoon een MySQL-upgrade uit die de innoDB-engine opnieuw zal bouwen, samen met het opnieuw opbouwen van vele tabellen die nodig zijn voor een goede werking van MySQL, zoals performance_schema, information_schema, enz.

Geef het onderstaande commando vanuit je shell:

sudo mysql_upgrade -u root -p

Antwoord 10

Ik weet dat het oud is, maar op mac

1. Control-click your connection and choose Connection Properties.
2. Under Advanced tab, set the Socket Timeout (sec) to a larger value.

Antwoord 11

Als je dit probleem ervaart tijdens het terugzetten van een groot dumpbestand en je kunt uitsluiten dat het iets met het netwerk te maken heeft (bijv. uitvoering op localhost), dan kan mijn oplossing nuttig zijn.

Mijn mysqldump bevatte minstens één INSERT die te groot was voor mysql om te berekenen. Je kunt deze variabele bekijken door show variables like "net_buffer_length";in je mysql-cli te typen.
Je hebt drie mogelijkheden:

  • verhoog de net_buffer_length binnen mysql -> hiervoor is een herstart van de server nodig
  • maak een dump aan met --skip-extended-insert, per insert wordt één regel gebruikt -> hoewel deze stortplaatsen veel prettiger zijn om te lezen, is deze niet geschikt voor grote stortplaatsen > 1 GB omdat het vaak erg traag is
  • maak een dump aan met uitgebreide inserts (wat de standaard is) maar beperk de net-buffer_length, b.v. met --net-buffer_length NR_OF_BYTESwaarbij NR_OF_BYTES kleiner is dan de net_buffer_length -> Ik denk dat dit de beste oplossing is, hoewel langzamer geen herstart van de server nodig is.

Ik heb het volgende mysqldump-commando gebruikt:
mysqldump --skip-comments --set-charset --default-character-set=utf8 --single-transaction --net-buffer_length 4096 DBX > dumpfile


Antwoord 12

Probeer de limietrijen uit te schakelen in Bewerken → Voorkeuren →SQL-query’s

omdat je de eigenschappen ‘interactive_timeout’ en ‘wait_timeout’ in het mysql-configuratiebestand moet instellen op de waarden die je nodig hebt.


Antwoord 13

Wijzig de tijd voor “lees time-out” in Edit->Preferences->SQL editor->MySQL-sessie


Antwoord 14

Soms loopt je SQL-server vast, ik heb dit probleem wel 100 keer gehad. U kunt ofwel uw computer/laptop opnieuw opstarten om de server opnieuw op te starten (eenvoudige manier) OF u kunt naar task-manager>services>YOUR-SERVER-NAME(voor mij was het MySQL785 zoiets als dit). En klik met de rechtermuisknop > herstarten.
Probeer de zoekopdracht opnieuw uit te voeren.


Antwoord 15

Ik kreeg hetzelfde probleem bij het laden van een .csv-bestand.
Het bestand geconverteerd naar .sql.

Met het onderstaande commando lukt het me om dit probleem te omzeilen.

mysql -u <user> -p -D <DB name> < file.sql

Ik hoop dat dit zou helpen.


Antwoord 16

Als alle andere oplossingen hier niet werken, controleer dan uw syslog (/var/log/syslog of iets dergelijks) om te zien of uw server onvoldoende geheugen heeft tijdens de query.

Heb dit probleem gehad toen innodb_buffer_pool_size te dicht bij het fysieke geheugen was ingesteld zonder dat een swapfile was geconfigureerd. MySQL raadt aan voor een databasespecifieke serverinstelling innodb_buffer_pool_size op een maximum van ongeveer 80% van het fysieke geheugen, ik had het ingesteld op ongeveer 90%, doodde de kernel het mysql-proces. Innodb_buffer_pool_size teruggezet naar ongeveer 80% en dat loste het probleem op.


Antwoord 17

Ik heb met hetzelfde probleem te maken gehad. Ik geloof dat het gebeurt als je externe sleutels hebt voor grotere tabellen (wat tijd kost).

Ik heb geprobeerd de instructie create table opnieuw uit te voeren zonder de declaraties van de refererende sleutel en merkte dat het werkte.

Na het maken van de tabel heb ik de externe-sleutelbeperkingen toegevoegd met behulp van de ALTER TABLE-query.

Ik hoop dat dit iemand zal helpen.


Antwoord 18

Dit overkwam mij omdat mijn innodb_buffer_pool_size groter was ingesteld dan de beschikbare RAM op de server. Dingen werden hierdoor onderbroken en het geeft deze fout. De oplossing is om my.cnf bij te werken met de juiste instelling voor innodb_buffer_pool_size.


Antwoord 19

Ga naar Workbench Edit → Voorkeuren → SQL Editor → Time-out voor lezen van DBMS-verbindingen: tot 3000.
De fout is niet meer opgetreden.


Antwoord 20

Ga naar:

Bewerken -> Voorkeuren -> SQL-editor

Daarin ziet u drie velden in de groep “MySQL Session”, waar u nu de nieuwe verbindingsintervallen (in seconden) kunt instellen.


Antwoord 21

Het blijkt dat onze firewallregel mijn verbinding met MYSQL blokkeerde. Nadat het firewallbeleid is opgeheven om de verbinding mogelijk te maken, kon ik het schema met succes importeren.


Antwoord 22

Ik had hetzelfde probleem – maar voor mij was de oplossing een DB-gebruiker met te strikte machtigingen.
Ik moest de mogelijkheid Executetoestaan in de tabel mysql. Nadat ik dat had toegestaan, had ik geen verbroken verbindingen meer


Antwoord 23

Controleer eerst of de indexenop hun plaats staan.

SELECT *
FROM INFORMATION_SCHEMA.STATISTICS
WHERE TABLE_SCHEMA = '<schema>'

Antwoord 24

Ik kwam dit tegen tijdens het uitvoeren van een opgeslagen proces, dat veel rijen aanmaakte in een tabel in de database.
Ik zag dat de fout direct na de grens van 30 seconden kwam.

Ik heb alle suggesties in de andere antwoorden geprobeerd. Ik ben er echter zeker van dat een deel ervan heeft geholpen – wat het echt voor mij deed werken, was het overschakelen naar SequelPro van Workbench.

Ik vermoed dat het een client-side-verbinding was die ik niet kon vinden in Workbench.
Misschien helpt dit iemand anders ook ?


Antwoord 25

Als u SQL Work Bench gebruikt, kunt u proberen Indexing te gebruiken, door een index aan uw tabellen toe te voegen, om een index toe te voegen, klik op het moersleutelsymbool op de tafel, dit zou de instellingen voor de tabel, klik hieronder op de indexweergave, typ een indexnaam en stel het type in op index. Selecteer in de indexkolommen de primaire kolom in uw tabel.

Voer dezelfde stap uit voor andere primaire sleutels op andere tabellen.


Antwoord 26

Er lijkt hier een antwoord te ontbreken voor degenen die SSH gebruiken om verbinding te maken met hun MySQL-database. U moet twee plaatsen aanvinken, niet 1 zoals gesuggereerd door andere antwoorden:

Workbench Edit → Voorkeuren → SQL Editor → DBMS

Werkbank bewerken → Voorkeuren → SSH → Time-outs

Mijn standaard SSH-time-outs waren erg laag ingesteld en veroorzaakten sommige (maar blijkbaar niet alle) time-outproblemen. Vergeet daarna niet MySQL Workbench opnieuw op te starten!

Ten slotte kan het de moeite waard zijn om contact op te nemen met uw DB-beheerder en hen te vragen de wait_timeout & interactieve_timeout eigenschappen in mysql zelf via my.conf + mysql herstart of doe een globale set als herstarten van mysql geen optie is.

Hopelijk helpt dit!


Antwoord 27

Drie dingen die moeten worden gevolgd en zorg ervoor dat:

  1. Of meerdere zoekopdrachten een verbroken verbinding tonen?
  2. hoe gebruik je setquery in MySQL?
  3. hoe verwijder + update tegelijkertijd query?

Antwoorden:

  1. Probeer altijd de definitie te verwijderen, aangezien MySQL zijn eigen definiëring maakt en als er meerdere tabellen bij betrokken zijn voor het bijwerken, probeer dan een enkele query te maken, omdat soms meerdere query’s een verbroken verbinding laten zien
  2. Stel de waarde altijd bovenaan in, maar na DELETE als de voorwaarde geen SET-waarde bevat.
  3. Gebruik EERST VERWIJDEREN DAARNA UPDATEN ALS BEIDE BEWERKINGEN WORDEN UITGEVOERD OP VERSCHILLENDE TABELLEN

Antwoord 28

Ik kreeg deze foutmelding vanwege een probleem na de upgrade van Mysql. De fout verscheen onmiddellijknadat ik een zoekopdracht had uitgevoerd

Controleer mysql-foutlogbestanden in pad /var/log/mysql(linux)

In mijn geval werkte het opnieuw toewijzen van de Mysql-eigenaar aan de Mysql-systeemmap voor mij

chown -R mysql:mysql /var/lib/mysql

Antwoord 29

controleer over

OOM on /var/log/messages ,
modify innodb_buffer_pool_size value ; when load data , use 50% of os mem ; 

Hopelijk helpt dit


Antwoord 30

Dit betekent meestal dat u “incompatibiliteiten heeft met de huidige versie van MySQL Server”, zie mysql_upgrade. Ik kwam hetzelfde probleem tegen en moest gewoon uitvoeren:

mysql_upgrade –wachtwoord
De documentatie stelt dat “mysql_upgrade elke keer dat u MySQL opwaardeert moet worden uitgevoerd”.

Other episodes