mysql has gone away

Overzicht Reageren

Sponsored by: Vacatures door Monsterboard

Web Ontwikkelaar PHP, Nijmegen

Contactpersoon Roel Kavelaar rkavelaarATsearch-consult.nl 0243528815 0644949337 Organisatie Jong, gezond en sterk groeiende bedrijf dat webbased multimedia oplossingen bouwt in de omgeving Nijmegen. Het bedrijf bouwt voor klanten o.a. geavanceerde websites, webwinkels, webapplicaties en specifieke webbased software. Het bedrijf ontwikkelt en onderhoudt ook verschillende bekende Nederlandse websites. Op dit moment hebben zij een groeiende en brede klantenkring opgebouwd. Met betrekking tot programmeer-, onderhoud-, ontwerp-werkzaamheden wordt een PHP ontwikkelaar gezocht met kennis van contentmanagementsysteemen en frameworks. Locatie Nijmegen Verantwoordelijkheden (Her)Ontwerpen en (her)ontwikkelen in PHP ten behoeve van websites voor klanten, project klussen, onderhoud en specifieke klantwensen (Her)Ontwerpen en (her)ontwikkelen in PHP, PHP

Bekijk vacature »

Daniel van Seggelen

Daniel van Seggelen

06/05/2019 14:58:08
Quote Anchor link
Sinds ik al mijn mysql databases /lib/mysql heb verplaatst naar mijn externe bigstorage schijf op ee centos machine, krijg ik bij een cronjob wat datafeeds importeerd met LOAD DATA LOCAL INFILE de volgende foutmelding:

"mysql has gone away"

Ik heb in my.cnf de timeouts en inno_db_log verhoogt, maar dat lijkt het probleem niet te zijn.

Weet iemand wat dit probleem hier kan zijn?
 
PHP hulp

PHP hulp

25/05/2019 12:15:09
 
- Ariën -
Beheerder

- Ariën -

06/05/2019 15:13:08
Quote Anchor link
Ik vermoed dat de waarde van 'max_allowed_packet' in my.cnf te klein is dan je in te laden CSV-file.
 
Daniel van Seggelen

Daniel van Seggelen

06/05/2019 17:33:27
Quote Anchor link
In de server logs zie ik veel over InnoDB - roll back all transactions for connection.
starting crash recovery
InnoDB: To roll back : 1 transactions, 194949 rows
etc etc

Ok ik heb max_allowed_packet = 128M gedaan
kijken wat hij nu doet
 
- Ariën -
Beheerder

- Ariën -

06/05/2019 19:20:44
Quote Anchor link
En?
 
Daniel van Seggelen

Daniel van Seggelen

06/05/2019 19:29:17
Quote Anchor link
Nog steeds hetzelfde helaas. Net de cronjob weer geladen.

Transip gaat een migratie doen van Big Storage naar een andere Big Storage server te kunnen migreren om uit te sluiten dat de server de crash veroorzaakt.

Wel heel toevallig dat het net gebeurd, wanneer ik de database verplaatst heb naar big storage. Daarvoor werke alles perfect.

De error in de log begint zo met:
Quote:
PHP warning: Empty row packet body in /pad/naar/bestand/ line 340:

Dat verwijst naar een mysql query:

$o = mysqli_query($DBD->conn(),"select * from prijzen_temp pt, producten_temp prt where prt.ean = pt.ean AND prt.category != 0 ");

dan..

Quote:
PHP warning: Mysqli_query(): Mysql server has gone away in /pad/naar/bestand/ line 370:


Dan bij regel 370
$uplaatst = mysqli_query($DBD->conn(),"UPDATE datafeed SET last_cron = '".date('Y-m-d')."' WHERE id = '".$q['id']."' ");





Toevoeging op 06/05/2019 19:30:50:

TOEVOEGING:

elke keer als ik de cronjob weer laad, dan doet hij weer een aantal feeds en dat krijg ik weer hetzelfde.
Het is geen code fout iig. Het heeft altijd zonder deze fouten gewerkt.
 
Thomas van den Heuvel

Thomas van den Heuvel

06/05/2019 22:36:29
Quote Anchor link
> Het heeft altijd zonder deze fouten gewerkt.

Mja, maar de opstelling is veranderd, en je database wordt waarschijnlijk ook elke keer groter.

Heb je al gekeken of er brakke queries in zitten of dingen die veel geheugen kosten? Is het echt nodig om *alles* te selecteren (SELECT * FROM prijzen_temp)? Staan er ook indexen op relevante kolommen? Mogelijk kosten dingen teveel tijd. Loop je toevallig tegen andere limieten aan (auto increment index toevallig)?

En, heb je de foutmelding al in Ome Goegel gegooid? Het eerste resultaat geeft bijvoorbeeld al veel info.
Gewijzigd op 06/05/2019 22:37:40 door Thomas van den Heuvel
 
Aad B

Aad B

07/05/2019 11:40:17
 
Daniel van Seggelen

Daniel van Seggelen

07/05/2019 12:58:39
Quote Anchor link
Ik heb de queries aangepast, nu ook de innodb_lock_wait_timeout aangepast, want dat is de volgende fout die eraan komt.

IK denk ergens toch dat de mysql database corrupt is.

Ik heb mysql gestopt met service mysqld stop en toen de migratie van alle databases gedaan naar de bigstorage externe schijf.

Kan het dan toch zo zijn dat hier iets niet goedgegaan is zonder foutmeldingen?
Als ik het geheel weer terugzet incl de config files aanpas naar de dafault locatie en het weer probeer, zal het dan zeker goed gaan?

Ik kreeg van transip het volgende bericht:

- er toch nog statische verwijzingen naar de directory van MariaDB zijn
- je voordat je de database hebt over gekopieerd de MySQL service hebt gestopt om corruptie te voorkomen
- de MySQL service dubbel actief is met het commando 'htop'
- er voldoende schijfruimte vrij is op de Big Storage met het commando 'df -h'
- de Big Storage partitie in Read Only modus is gemount
 
- SanThe -

- SanThe -

07/05/2019 15:24:45
Quote Anchor link
Daniel van Seggelen op 07/05/2019 12:58:39:

- de Big Storage partitie in Read Only modus is gemount


Read Only?
 
- Ariën -
Beheerder

- Ariën -

07/05/2019 15:29:28
Quote Anchor link
Eh, ja.... Dat kan bewust of onbewust met partities op Linux.
 
Daniel van Seggelen

Daniel van Seggelen

07/05/2019 16:36:01
Quote Anchor link
Hoe dan ook, het werkt niet, totaal niet, zelfde problemen. Mysql is helemaal van slag lijkt het wel. Ik zal alle database files maar weer terugzetten naar de dafault locatie, waar alles nog netjes werkte.
 
Thomas van den Heuvel

Thomas van den Heuvel

07/05/2019 16:57:34
Quote Anchor link
Ben je echt met fysieke mysql-bestanden gaan schuiven? Waarom geen dumps vanaf de oude locatie en imports op de nieuwe locatie, waarbij je tussendoor in de configuratie de data-directories aanpast?

EDIT: op die manier had je ook terug gekund naar een werkende situatie. Alles zomaar verplaatsen lijkt mij inderdaad een nogal linke actie, je hebt dan geen echte exit-strategie mocht het misgaan.
Gewijzigd op 07/05/2019 16:58:38 door Thomas van den Heuvel
 
Aad B

Aad B

07/05/2019 21:14:52
Quote Anchor link
Met fysieke mysql-bestanden schuiven op het moment dat de mysql service gestopt is moet kunnen. Ik heb ook al eens zo'n actie uitgevoerd en dat werkt. Google op Move MySQL database en je vindt deze oplossing meerdere keren terug. Ben wel met Thomas eens dat backup dumps en imports op nieuwe locatie veiliger is.
Wat is hier fout gegaan? Hoe is de nieuwe big storage fysiek in het systeem geplaatst? USB of IP of anders?
Wie is owner/group van die data files en filestructuur? CHMOD -R 777 is knoeiwerk. Is er misschien een my.cnf of my.ini aangepast die niet hoort bij de actuele MySQL service?? Verder het 127.0.0.1 of localhost probleem kan bijna niet gerelateerd zijn aan MySQL tenzij hiervoor ook iets aangepast is in de conf, namelijk het adres waarop MySQL deamon "luistert". Wat staat er in de conf bij: bind-address???
Is MySQL deamon opgestart met een totaal andere conf? Kortom er is nogal wat mis en het beste is inderdaad om helemaal terug te gaan naar de oude situatie en een werkende migratie te ontwerpen.
Gewijzigd op 07/05/2019 21:46:02 door Aad B
 
Daniel van Seggelen

Daniel van Seggelen

08/05/2019 03:49:41
Quote Anchor link
Quote:
Hoe is de nieuwe big storage fysiek in het systeem geplaatst? USB of IP of anders?


dit lees ik erover:

Because Big Storage uses (Enterprise grade) HDD-disks and not the SSD's that the regular storage uses, the write- and read-speeds of this disk will be somewhat lower.

Quote:
Is er misschien een my.cnf of my.ini aangepast die niet hoort bij de actuele MySQL service?


Nee, alleen de /etc/my.cnf is aangepast.

Quote:
Verder het 127.0.0.1 of localhost probleem kan bijna niet gerelateerd zijn aan MySQL tenzij hiervoor ook iets aangepast is in de conf, namelijk het adres waarop MySQL deamon "luistert". Wat staat er in de conf bij: bind-address???

bind is defauld aar 127.0.0.1 zie mijn my.cnf hieronder. Het heeft er wel zeker mee te maken gehad, angezien, het daarvoor goed werkte met localhost.

Mijn my.cnf hieronder hoe het nu is.


Quote:

[client]
local-infile=1
#loose-local-infile = 1 // added this
socket=/mnt/bigstorage/mysql/mysql.sock


[mysqld]
#mysql.allow_local_infile=On
#local-infile=1
max_allowed_packet = 128M
innodb_lock_wait_timeout = 100
wait_timeout=600
interactive_timeout = 600
innodb_log_file_size= 128M
bind-address = 127.0.0.1
datadir=/mnt/bigstorage/mysql
socket=/mnt/bigstorage/mysql/mysql.sock
#datadir=/var/lib/mysql
#socket=/var/lib/mysql/mysql.sock
# Disabling symbolic-links is recommended to prevent assorted security risks symbolic-links=0
# Settings user and group are ignored when systemd is used.
# If you need to run mysqld under a different user or group,
# customize your systemd unit file for mariadb according to the
# instructions in http://fedoraproject.org/wiki/Systemd

[mysqld_safe]
log-error=/var/log/mariadb/mariadb.log
pid-file=/var/run/mariadb/mariadb.pid

#
# include all files from the config directory
#
!includedir /etc/my.cnf.d

loose-local-infile = 1


Ik heb een secondary my.cnf voor diretadmin hier:

/usr/local/directadmin/conf/my.cnf

dat is gewoon een extentie, en staat alleen een gebruikersnaam/wachtwoord en geen overige informatie.



Ik ga nu helemaal weer terug

Toevoeging op 08/05/2019 04:47:23:

En een update,

alles if weer terug gezet, incl de config naar:

#datadir=/var/lib/mysql
#socket=/var/lib/mysql/mysql.sock


phpmyadmin werkt weer, localhost en dus het had er hoe dan ook ZEKER welmee te maken.
de cronjob gaat nu weer niet door tot het einde en mysql verdwijnt. Ik denk omdat er niet genoeg ruimte is op de schijf.

Alleen nu is de schijf 99% vol, dus ik probeer deze maar uit te breiden. een externe schijf raad ik dus niet aan uit deze ervaring.



Toevoeging op 08/05/2019 05:15:13:

update log:

Quote:
May 08 05:12:16 ivomedia.nl mysqld[15462]: pthread_create.c:0(start_thread)[0x7f98db43ddd5]
May 08 05:12:16 ivomedia.nl mysqld[15462]: /lib64/libc.so.6(clone+0x6d)[0x7f98d95abead]
May 08 05:12:16 ivomedia.nl mysqld[15462]: The manual page at http://dev.mysql.com/doc/mysql/en/crashing.html contains
May 08 05:12:16 ivomedia.nl mysqld[15462]: information that should help you find out what is causing the crash.
May 08 05:12:16 ivomedia.nl abrt-hook-ccpp[15580]: Process 15462 (mysqld) of user 993 killed by SIGABRT - dumping core
May 08 05:12:18 ivomedia.nl abrt-hook-ccpp[15580]: Failed to create core_backtrace: waitpid failed: No child processes
May 08 05:12:18 ivomedia.nl systemd[1]: mariadb.service: main process exited, code=killed, status=6/ABRT
May 08 05:12:18 ivomedia.nl systemd[1]: Unit mariadb.service entered failed state.
May 08 05:12:18 ivomedia.nl systemd[1]: mariadb.service failed.
May 08 05:12:18 ivomedia.nl abrt-server[15668]: Package 'MariaDB-server' isn't signed with proper key
May 08 05:12:18 ivomedia.nl abrt-server[15668]: 'post-create' on '/var/spool/abrt/ccpp-2019-05-08-05:12:16-15462' exited with 1
May 08 05:12:18 ivomedia.nl abrt-server[15668]: Deleting problem directory '/var/spool/abrt/ccpp-2019-05-08-05:12:16-15462'
May 08 05:12:23 ivomedia.nl systemd[1]: mariadb.service holdoff time over, scheduling restart.
May 08 05:12:23 ivomedia.nl systemd[1]: Stopped MariaDB database server.
-- Subject: Unit mariadb.service has finished shutting down
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
--
-- Unit mariadb.service has finished shutting down.
May 08 05:12:23 ivomedia.nl systemd[1]: Starting MariaDB database server...
-- Subject: Unit mariadb.service has begun start-up
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Gewijzigd op 08/05/2019 04:49:59 door Daniel van Seggelen
 



Overzicht Reageren

 
 

Om de gebruiksvriendelijkheid van onze website en diensten te optimaliseren maken wij gebruik van cookies. Deze cookies gebruiken wij voor functionaliteiten, analytische gegevens en marketing doeleinden. U vindt meer informatie in onze privacy statement.