mysql has gone away
"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?
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
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.
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
https://stackoverflow.com/questions/33250453/how-to-solve-general-error-2006-mysql-server-has-gone-away
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
Daniel van Seggelen op 07/05/2019 12:58:39:
- de Big Storage partitie in Read Only modus is gemount
- de Big Storage partitie in Read Only modus is gemount
Read Only?
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
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
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
[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
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