mysql has gone away

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.

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.

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.

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.

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.

[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

[size=xsmall]Toevoeging op 08/05/2019 04:47:23:[/size]

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.



[size=xsmall]Toevoeging op 08/05/2019 05:15:13:[/size]

update log:

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