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.ini
wijziging 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_packet
van 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_timeout
en 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
- Meestal duidt dit op problemen met de netwerkverbinding en u moet de toestand van uw netwerk controleren als deze fout vaak optreedt
- Soms wordt het formulier ‘tijdens zoekopdracht’ gebruikt wanneer miljoenen rijen worden verzonden als onderdeel van een of meer zoekopdrachten.
- 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_BYTES
waarbij 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 Execute
toestaan 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:
- Of meerdere zoekopdrachten een verbroken verbinding tonen?
- hoe gebruik je setquery in MySQL?
- hoe verwijder + update tegelijkertijd query?
Antwoorden:
- 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
- Stel de waarde altijd bovenaan in, maar na DELETE als de voorwaarde geen SET-waarde bevat.
- 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”.