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?
Ik vermoed dat de waarde van 'max_allowed_packet' in my.cnf te klein is dan je in te laden CSV-file.
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
En?
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:

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..


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']."' ");





[size=xsmall]Toevoeging op 06/05/2019 19:30:50:[/size]

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.
> 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.
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

Daniel van Seggelen op 07/05/2019 12:58:39


- de Big Storage partitie in Read Only modus is gemount



Read Only?
Eh, ja.... Dat kan bewust of onbewust met partities op Linux.
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.

Reageren