Server has gone away-foutmelding

Uit De Vliegende Brigade
Naar navigatie springen Naar zoeken springen

MySQL server has gone away is een foutmelding die aangeeft dat MySQL de verbinding heeft gesloten, typisch een time-out-probleem.

May I introduce myself...

Als MySQL de verbinding verbreekt, ligt de oorzaak meestal elders in de stack, bv. bij Drupal of PHP. Sterker nog: MySQL vermeldt deze gebeurtenis niet eens in het MySQL logbestand. Deze foutmelding kan veel oorzaken hebben. Een impressie:

Fout ligt bij MySQL

  • Onjuiste timing-parameters. Ik geloof dat deze in my.cnf worden ingesteld
  • MySQL is gecrashed, of het betreffende process kreeg het kill-signaal gedurende een query.

Fout ligt buiten MySQL

  • 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

Foutmelding. mysqladmin version gaf aan dat MySQL actief was. Iteratief uitzetten van de genoemde Drupal-modules (drupal dis {naam}) hielp niet. We pakken de boeken erbij!

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 feb. 2016: Gedurende sql-import

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.

Zie ook

Bronnen

Overgenomen van "https://wiki.devliegendebrigade.nl/index.php?title=Server_has_gone_away-foutmelding&oldid=3184"