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.

Dit artikel heeft betrekking op een casus in januari 2016, waarbij een site werd gemigreerd van interne ontwikkelomgeving 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.

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.

Diagnose & oplossing

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?

Zie ook

Bronnen