Server has gone away-foutmelding
MySQL server has gone away is een foutmelding die aangeeft dat MySQL de verbinding heeft gesloten. Iets uitgbreider:
Error Code: 2013. Lost connection to MySQL server during query
May I introduce myself...
Als MySQL de verbinding verbreekt, kan de oorzaak zowel bij MySQL als in andere lagen van een eventuele stack liggen. In dit laatste geval lijkt het erop, dat MySQL deze gebeurtenis niet eens vermeldt in het MySQL logbestand. Een impressie:
Oorzaak is MySQL
- Onjuiste timing-parameters. Ik geloof dat deze in
my.cnfworden ingesteld - MySQL is gecrashed, of het betreffende process kreeg het kill-signaal gedurende een query
- Vermoedelijk: Als een query de maximaal toegestane executietijd overschrijft: Ik krijg deze foutmelding opvallend vaak als een query 30s-en-een-beetje bezig is geweest.
Oorzaak ligt buiten MySQL
- Timing-parameter MySQL Workbench is overschreden (standaard 30 seconde)
- Je probeert een query uit te voeren terwijl de sever is gestopt
- Je probeert een query uit te voeren op een remote server zonder de bijbehorende privileges
- Client-sided TCP/IP time-out
- Time-out zonder automatic reconnection
- Query is te groot, bv. import met te lange queries, of tabellen met te veel kolommen, of met te veel kolommen met veel data (bv. BLOB's)
- Query is out-of-order.
Casus: Jan. 2016 - Drupal stopt ermee
Deze fout betrof een database die van een interne ontwikkelserver was gemigreerd naar een externe testomgeving. Die interne ontwikkelomgeving had aangepaste en verruimde MySQL timing-parameters -- Maar dat bedacht ik me pas nadat het probleem was gediagnosticeerd.
Foutmelding
MySQL error-log
Het MySQL error-log had nergens last van.
PHP-log
Ah, nu gaat het ergens over:
[30-Jan-2016 18:03:57 Europe/Berlin] PHP Fatal error: Uncaught exception 'PDOException' with message 'SQLSTATE[HY000]: General error: 2006 MySQL server has gone away' in /var/webserver/example.com/includes/database/database.inc:2171
#0 /var/webserver/example.com/includes/database/database.inc(2171): PDOStatement->execute(Array)
#1 /var/webserver/example.com/includes/database/database.inc(683): DatabaseStatementBase->execute(Array, Array)
#2 /var/webserver/example.com/includes/database/database.inc(2350): DatabaseConnection->query('SELECT expire, ...', Array, Array)
#3 /var/webserver/example.com/includes/lock.inc(167): db_query('SELECT expire, ...', Array)
#4 /var/webserver/example.com/includes/lock.inc(146): lock_may_be_available('schema:runtime:...')
#5 /var/webserver/example.com/includes/bootstrap.inc(433): lock_acquire('schema:runtime:...')
#6 /var/webserver/example.com/inc in /var/webserver/example.com/includes/database/database.inc on line 2171
...Maar nog niets concreets.
Directe aanleiding: Toch iets met wachttijd & modules
Dit artikel gaf me opnieuw de indruk dat er een wachttijd ontstaat door een gare module, en toevallig wordt er nog steeds een concrete module genoemd in de foutmelding: views. Uitzetten middels drush dis views... Probleem opgelost. Dat wil zeggen: De directe aanleiding van het probleem is nu weggenomen. De achterliggende oorzaak misschien nog niet.
Achterliggende oorzaak: Conflicterende modules?
Er lijkt een te grote vertraging te worden veroorzaakt als de volgende Drupal-modules tegelijkertijd aanstaan:
- Core - Comments
- Views & Views UI
- Commerce - Alle modules (muv. payment example).
De volgende combinatie lijkt geen foutmelding te geven:
- Core - Comments - Uit
- Vieuws & Vieuws UI - Allebij aan
Commerce:
drush en -y commerce # Noodzakelijk
drush en -y commerce_cart # Noodzakelijk
drush en -y commerce_checkout # Noodzakelijk
drush en -y commerce_customer # Noodzakelijk
drush dis -y commerce_customer_ui # Niet nodig voor productie
drush en -y commerce_line_item # Noodzakelijk
drush dis -y commerce_line_item_ui # Niet nodig voor productie
drush en -y commerce_order # Noodzakelijk
drush dis -y commerce_order_ui # Optioneel voor productie
drush en -y commerce_payment # Noodzakelijk
drush dis -y commerce_payment_example # Optioneel
drush dis -y commerce_payment_ui # Optioneel voor productie
drush en -y commerce_price # Noodzakelijk
drush en -y commerce_product # Noodzakelijk
drush dis -y commerce_product_pricing # Dynamische prijs-aanpassing
drush dis -y commerce_product_pricing_ui # UI voor dynamische prijs-aanpassing
drush en -y commerce_product_reference # Noodzakelijk (vermoedelijk)
drush dis -y commerce_product_ui # Optioneel
drush en -y commerce_tax # Nodig voor BTW
drush dis -y commerce_tax_ui # Optioneel
drush en -y commerce_ui # Noodzakelijk?
Overigens, er is een kans dat de echte oorzaak elders ligt, al waren al veel modules uitgeschakeld.
Achterliggende oorzaak: Onhandige timing-parameters?
Laat maar. Ik ben niet verdergegaan met dit probleem.
Casus: Gedurende sql-import (feb. 2016)
Deze fout kan ook al optreden bij zo iets eenvoudigs als het importeren van een SQL-dump. In dit geval had ik de database-dump op verschillende manieren gegenereerd, maar zonder verbetering (namelijk: Via drupal - drush ard of via mysqldump):
mysql mijndatabase < backup.sql ERROR 2006 (HY000) at line 708: MySQL server has gone away
Verschillende opties geprobeerd...
- Net-nog-wat-parameter aangepast in commando mysqldump > Geen verschil
- Zelfde ruime instellingen op ontvangende server toegepast als op verzendende server > Geen verschil
Oplossing
Backup gemaakt met Drupal Backup & Migrate-module: Die laat een hoop overbodige tabellen achterwege, en dat hielp. Blijft onbevredigend.
Casus: MySQL Workbench-time-out (juli 2018)
Precies zoals beschreven aan het begin van dit artikel. Oplossing:
- Parameter aanpassen
- MySQL Workbench herstarten (MySQL hoeft niet herstart te worden).
Casus: Storing productieserver (mei 2020)
Zie ook
Bronnen
- http://dev.mysql.com/doc/refman/5.1/en/gone-away.html
- https://www.drupal.org/node/1014172 - General error: 2006 MySQL server has gone away in _drupal_session_write()