it-swarm.com.de

Das Lösen von "MySQL-Server ist verschwunden", MySQL-Fehler 2006

Ich habe eine Site bei Hostgator, die ihr "Geschäftskonto" verwendet. Es ist billig und wird mit einem privaten SSL-Zertifikat geliefert. Die MySQL-Einstellungen sind jedoch so, dass jede Datenbankverbindung ziemlich schnell veraltet ist, und dann versuchen die Hostgator-Mitarbeiter, Sie davon zu überzeugen, einen VPS- oder dedizierten Server zu einem Mehrfachen der Kosten zu verwenden.

Ich erstelle und implementiere WebAPIs, die eine "Konversation" von mehr als 60 Sekunden führen können. In diesem Fall ist das Datenbankverbindungshandle veraltet, sodass Datenbankoperationen nach meinem Timeout fehlschlagen.

Ich bin gerade dabei, die folgende Lösung zu implementieren, bin aber neugierig, ob jemand anderes dieses Problem (bei dem er seine my.ini oder my.cnf nicht ändern kann, um MySQL mehr Ressourcen zu geben) auf ähnliche oder völlig andere Weise gelöst hat.

letzter Teil eines hook_update:

$ret = db_query( "UPDATE {my_table} set field1 = '%s', field2 = %d ... WHERE vid - %d", $node->field1, $node->field2, ... $node->vid );
if (!$ret) {
       // get private storage directory for this node:
       $cexStorage    = _cex_front_getCexStore();
       $nodeFilesPath = DRUPALROOT.'/'.$cexStorage.'/'.$node->storeDir;
       $fname         = $nodeFilesPath.'/recover.node'; 
       $readyToWrite  = serialize( $node );
       file_put_contents( $fname, $readyToWrite );
       if (file_exists( $fname )) {
         _dbgReport( 'seems to have worked!' );
       }
    }

Dann wird dies in meiner hook_form aufgerufen, gleich nachdem ich festgestellt habe, dass node-> nid gültig ist:

function _cex_front_recover_node( &$node ) {
  if (!isset($node->storeDir)) {
     _dbgReport( '**************************** _cex_front_recover_node: no storeDir!!!' );
     return;
  }

  // get private storage directory for this node:
  $cexStorage    = _cex_front_getCexStore();
  $nodeFilesPath = DRUPALROOT.'/'.$cexStorage.'/'.$node->storeDir;
  $fname         = $nodeFilesPath.'/recover.node';
  if (file_exists( $fname )) {
    $recovered = file_get_contents( $fname );
    if ($recovered) {
      // no longer needed:
      unlink( $fname );
      $recoveredNode = unserialize( $recovered );
      // restore the key values I need to proceed with this node:
      $node->stage = $recoveredNode->stage;
      $node->rnid  = $recoveredNode->rnid;
      $node->iris  = $recoveredNode->iris;
      cex_front_update( $node );
    }
    else {
      _dbgReport( '********* failed to read "'.$fname.'"' );
    }
  }
}

Ich werde die Logik koppeln, um nur die Schlüsselfelder zu speichern, die ich brauche, aber das funktioniert! Sicherlich besser als ein Upgrade meines Servers zum dreifachen Preis. Macht sonst noch jemand so etwas?

5
Blake Senftner

Ich hatte einen Kunden bei einem Hosting-Unternehmen, der sich weigerte, den Wert von max_allowed_packet (2 MB) zu erhöhen, was regelmäßig dazu führte, dass dem Cache keine Informationen hinzugefügt werden konnten. Ich habe das durch Hinzufügen von Komprimierung gelöst. Siehe Cache-Daten komprimieren, bevor sie in der Datenbank gespeichert werden .

In Ihrem Fall kann die Reduzierung des Ressourcenverbrauchs durch die Verteilung auf Stapelvorgänge erfolgen.

5
fietserwin

Wir hatten ein ähnliches Problem, bei dem wir zwei Datenbanken verwenden. Wir haben einige Arbeiten an der ersten Datenbank durchgeführt und dann sehr lange laufende Prozesse für die zweite Datenbank ausgeführt. Als wir dann versuchten, die erste Datenbank erneut zu verwenden, war die Verbindung unterbrochen.

Wir haben dies mithilfe der Einstellung mysqli.reconnect in php.ini behoben. Wenn Sie keinen Zugriff darauf haben, Sie können es Ihrer settings.php hinzufügen . Es gibt einige Einschränkungen bei dieser Einstellung , z. B. Transaktionen, die teilweise abgeschlossen sind, aber diese sind wahrscheinlich für Ihr Setup nicht relevant.

4
Mark B

Dieser Fehler hängt normalerweise mit dem Parsen großer Datenmengen zusammen, sodass die Datenbank möglicherweise nicht reagiert (Zeitüberschreitung), da sie solche Größen aufgrund der angegebenen Grenzwerte nicht verarbeiten kann. Daher tritt beim Server eine Zeitüberschreitung auf und die Verbindung wird geschlossen.

Um dies zu beheben, müssen Sie den Wert von max_allowed_packet In Ihrem my.cnf (Z. B. ~/.my.cnf) Im Abschnitt [mysqld] Weiter erhöhen, z.

[mysqld]
max_allowed_packet=256M

Versuchen Sie es mit 256M. Wenn dies nicht hilft, versuchen Sie es weiter (z. B. 1G).

In Ihrem Fall denke ich, dass max_allowed_packet Speziell im Abschnitt [mysqld] Und nicht unter [mysqld_safe] Befunden werden sollte, sodass die Einstellungen auf die richtige Komponente angewendet werden.

Weitere Informationen finden Sie unter: B.5.2.9 MySQL-Server ist verschwunden .

Eine andere Sache ist, dass es in diesem speziellen Fall in der Shutdown-Funktion geschieht (die nach Drupal hat die Verarbeitung der Site beendet), daher kann es sich um einige Cron- oder Debugging-Aufgaben handeln.


Wenn Ihr Hosting-Anbieter sich weigert, max_allowed_packet Zu erhöhen, sollten Sie in Betracht ziehen, zu einem anderen Hosting-Anbieter zu wechseln, der unterstützt. Drupal-Systemanforderungen .


Verbunden:

0
kenorb