# Immer wieder MySQL Problem: Lost connection to MySQL server..



## 3Dnavigator (27. Juni 2013)

Sporadisch setzt die reibungslose Funktion meines MySQL-Servers (5.6.12) aus und folgende Fehlermeldungen werden angezeigt:

Web-Browser:

```
Warning: mysqli::mysqli() [mysqli.mysqli]: (HY000/2006): MySQL server has gone away in /www/site-folder/lib/class/arDb.php on line 11
Warning: mysqli::query() [mysqli.query]: Couldn't fetch arDb in /www/site-folder/lib/class/arDb.php on line 12
```

Terminal (Eingabe: "mysql -uroot -p" und anschliessend Passwort):

```
ERROR 2013 (HY000): Lost connection to MySQL server at 'sending authentication information', system error: 32
```

Terminal (Eingabe: "mysqladmin version"):

```
mysqladmin: connect to server at 'localhost' failed
error: 'Lost connection to MySQL server at 'sending authentication information', system error: 32'
```

Während das Problem anhält kann ich wie nichts mit dem Server anstellen. Einige Minuten später läuft dann plötzlich alles wieder normal - bis zum nächsten Mal einige Zeit später.
Im Inet finde ich nichts schlaues (ausser Leute, welche scheinbar das gleiche Problem kennen aber ebenfalls keine Lösung finden).

Ich bezahle auch einen Stundenlohn nach Absprache für Remote-Hilfe - ich will nur, dass mein MySQL Server wieder zuverlässig und unterbruchsfrei läuft...
Jede Hilfe sehr willkommen!

Vielen Dank!


----------



## Bullja (29. Juni 2013)

Was sagt die Fehler-Logdatei zb in /var/log/mysqld.log?
Die Logs können sich auch an anderer Stelle befinden, siehe die Argumentliste deines laufenden mysqld Prozesses.


----------



## 3Dnavigator (3. Juli 2013)

Hallo Bullja
Leider finde ich dieses Logfile nicht.
Wenn ich in der my.cnf unter mysqld die Zeile log=/var/log/mysql-query.log einfüge, kann ich MySQL gar nicht mehr starten..
Was kann ich da tun?


----------



## Bullja (3. Juli 2013)

Dies sollte dir anzeigen in welche Datei die Logs geschrieben werden: *ps ax | grep mysqld*
Bei mir z.b:
3764 ?        Sl    19:50 /usr/libexec/mysqld --basedir=/usr --datadir=/var/lib/mysql --user=mysql *--log-error=/var/log/mysqld.log* --pid-file=/var/run/mysqld/mysqld.pid --socket=/var/lib/mysql/mysql.sock

Falls der Service gar nicht startet, würde ich in /var/log/message oder syslog einen Hinweis erwarten.


----------



## 3Dnavigator (4. Juli 2013)

Ok, meine Antwort auf das Kommando lautet:


```
205   ****  S      0:00.04 /bin/sh /usr/local/mysql/bin/mysqld_safe --datadir=/usr/local/mysql/data --pid-file=/usr/local/mysql/data/mysqld.pid
  467   ****  S      0:31.68 /usr/local/mysql/bin/mysqld --basedir=/usr/local/mysql --datadir=/usr/local/mysql/data --plugin-dir=/usr/local/mysql/lib/plugin --user=mysql --log-error=/usr/local/mysql/data/[hostname].err --pid-file=/usr/local/mysql/data/[hostname].pid
15080 s000  S+     0:00.00 grep mysqld
```

Das Errorlog um den Zeitpunkt eines dieser Problem-Zeiten sieht folgendermassen aus:


```
2013-07-03 07:27:16 437 [Note] /usr/local/mysql/bin/mysqld: ready for connections.
Version: '5.6.12'  socket: '/tmp/mysql.sock'  port: 3306  MySQL Community Server (GPL)
2013-07-03 08:01:05 437 [Warning] IP address '42.96.187.130' could not be resolved: nodename nor servname provided, or not known
2013-07-03 14:19:47 437 [Warning] IP address '42.121.105.43' could not be resolved: nodename nor servname provided, or not known

--> ca. um 15:32 ist das Problem aufgetaucht. Im Log ist jedoch nichts verzeichnet. Was bedeuten die vorhergehenden beiden Meldungen bzgl. den IP-Adressen? Mir sagen diese überhaupt nichts.. Kann das sein, dass diese ein Problem verursachten, das sich erst zwei Stunden später auswirkt?
--> als ich das Problem festgestellt habe, habe ich den Server neu gebootet. Damit sind für mich die nachfolgenden Meldungen erklärt.

2013-07-03 15:36:38 437 [Note] /usr/local/mysql/bin/mysqld: Normal shutdown

2013-07-03 15:36:38 437 [Note] Giving 2 client threads a chance to die gracefully
2013-07-03 15:36:38 437 [Note] Event Scheduler: Purging the queue. 0 events
2013-07-03 15:36:38 437 [Note] Shutting down slave threads
2013-07-03 15:36:40 437 [Note] Forcefully disconnecting 2 remaining clients
2013-07-03 15:36:40 437 [Warning] /usr/local/mysql/bin/mysqld: Forcing close of thread 13503  user: 'root'

2013-07-03 15:36:40 437 [Warning] /usr/local/mysql/bin/mysqld: Forcing close of thread 13502  user: 'root'

2013-07-03 15:36:40 437 [Note] Binlog end
2013-07-03 15:36:40 437 [Note] Shutting down plugin 'partition'
2013-07-03 15:36:40 437 [Note] Shutting down plugin 'PERFORMANCE_SCHEMA'
2013-07-03 15:36:40 437 [Note] Shutting down plugin 'INNODB_SYS_DATAFILES'
2013-07-03 15:36:40 437 [Note] Shutting down plugin 'INNODB_SYS_TABLESPACES'
2013-07-03 15:36:40 437 [Note] Shutting down plugin 'INNODB_SYS_FOREIGN_COLS'
2013-07-03 15:36:40 437 [Note] Shutting down plugin 'INNODB_SYS_FOREIGN'
2013-07-03 15:36:40 437 [Note] Shutting down plugin 'INNODB_SYS_FIELDS'
2013-07-03 15:36:40 437 [Note] Shutting down plugin 'INNODB_SYS_COLUMNS'
2013-07-03 15:36:40 437 [Note] Shutting down plugin 'INNODB_SYS_INDEXES'
2013-07-03 15:36:40 437 [Note] Shutting down plugin 'INNODB_SYS_TABLESTATS'
2013-07-03 15:36:40 437 [Note] Shutting down plugin 'INNODB_SYS_TABLES'
2013-07-03 15:36:40 437 [Note] Shutting down plugin 'INNODB_FT_INDEX_TABLE'
2013-07-03 15:36:40 437 [Note] Shutting down plugin 'INNODB_FT_INDEX_CACHE'
2013-07-03 15:36:40 437 [Note] Shutting down plugin 'INNODB_FT_CONFIG'
2013-07-03 15:36:40 437 [Note] Shutting down plugin 'INNODB_FT_BEING_DELETED'
2013-07-03 15:36:40 437 [Note] Shutting down plugin 'INNODB_FT_DELETED'
2013-07-03 15:36:40 437 [Note] Shutting down plugin 'INNODB_FT_DEFAULT_STOPWORD'
2013-07-03 15:36:40 437 [Note] Shutting down plugin 'INNODB_METRICS'
2013-07-03 15:36:40 437 [Note] Shutting down plugin 'INNODB_BUFFER_POOL_STATS'
2013-07-03 15:36:40 437 [Note] Shutting down plugin 'INNODB_BUFFER_PAGE_LRU'
2013-07-03 15:36:40 437 [Note] Shutting down plugin 'INNODB_BUFFER_PAGE'
2013-07-03 15:36:40 437 [Note] Shutting down plugin 'INNODB_CMP_PER_INDEX_RESET'
2013-07-03 15:36:40 437 [Note] Shutting down plugin 'INNODB_CMP_PER_INDEX'
...
...
```


----------



## Bullja (4. Juli 2013)

Die zwei IP Adressen sind irgendwelche Clients die sich auf den MySQL Service verbinden. Der Server versucht eine Namensauflösung, diese gibt aber nichts zurück. Sollte nichts mit dem Ausfall zu tun haben (ausser da loggt sich ein Bösewicht ein und stellt unheil an).

Du sagst "Während das Problem anhält kann ich wie nichts mit dem Server anstellen"... Bist Du sicher, dass der MySQL Service das Problem ist?
Ich nehme an, dass irgendein Service deinen Server komplett auslastet, diesen gilt es zu finden. Sobald das Problem wieder auftaucht, rufe mal *top *auf und schau welcher Prozess das Problem ist.

Falls es der mysqld sein sollte, könnte es an üblen Queries liegen, also mal slow-query-log aktivieren. Weiters dann general-log und general-log-file, das wird aber so ziemlich alles mitloggen.


----------



## 3Dnavigator (4. Juli 2013)

Hatte soeben die Gelegenheit während einem weiteren kurzen Ausfall *top* aufzurufen. Allerdings sehe ich da auch nichts verdächtiges.


----------



## 3Dnavigator (4. Juli 2013)

Habe noch das slow_query_log und general_log aktiviert und bin es derzeit am beobachten. Muss abwarten, bis das Problem wieder auftaucht..


----------



## Bullja (4. Juli 2013)

3Dnavigator hat gesagt.:


> Hatte soeben die Gelegenheit während einem weiteren kurzen Ausfall *top* aufzurufen. Allerdings sehe ich da auch nichts verdächtiges.



Sortier die Ausgabe nach der CPU Auslastung, damit man die interessanten Prozesse sieht. Versuche mal *top -o cpu*, falls das nicht korrekt sortiert, schau dir die man pages an.


----------



## 3Dnavigator (4. Juli 2013)

Auch das bringt mir nicht viel mehr Klarheit.
Ich frage mich nur, was die vielen "ruby" Prozesse zu bedeuten haben.. Meiner Meinung nach habe ich keine Ruby'on'Rales Dinge auf dem Server laufen..


----------



## 3Dnavigator (6. Juli 2013)

Also, zwischenzeitlich hat sich viel getan. Mit Bullja's Hilfe konnte ich so einiges Ausfindig machen:

- die Ruby Prozesse sind dem Mac OS X Wiki sowie dem Profil-Manager geschuldet und somit ok.
- es sind keine fehlerhaften und/oder unsachgemässe Queries am Werk, welche verantwortlich für die zeitweisen Ausfälle sind

stattdessen, haben wir herausgefunden, dass immer wenn 3 gleichzeitige Server-Verbindungen (siehe: *mysqladmin -uroot -p processlist*) geöffnet sind, der Server keine weiteren Verbindungen zulässt.
Die eine oder andere Website auf meinem Server haben zB. mit mysql_pconnect (persistent connect) Verbindungen hergestellt, welche teilweise nicht sofort wieder beendet wurden (darunter Typo3-Websites!). Dies verursachte, dass teilweise ein Benutzer schon mehrere gleichzeitige Verbindungen verursachen konnte. Das habe ich nun angepasst und verwende nur noch normale connects. Da diese nach dem Aufbau einer Seite sofort wieder geschlossen werden, besteht das Problem nun nur noch, wenn mehr als 3 Anfragen im gleichen Zeitraum den Server erreichen.

Diese drei Verbindungen sind unabhängig davon, ob diese via TCP oder Socket hergestellt wurden und auch unabhängig ob drei mal mit dem gleichen User oder nicht.

Nun gilt es nur noch zu klären, weshalb meine MySQL-Installation nach 3 statt 600 Verbindungen bereits zu macht..


----------



## saftmeister (6. Juli 2013)

Bist du sicher, das du nur 3 Verbindungen offen hast? Kannst du das mit netstat bzw. lsof verifzieren?


----------



## para_noid (6. Juli 2013)

3Dnavigator hat gesagt.:


> Nun gilt es nur noch zu klären, weshalb meine MySQL-Installation nach 3 statt 600 Verbindungen bereits zu macht..




Prüf mal den Wert für MAX_USER_CONNECTIONS [Link] bzw MAX_CONNECTIONS [Link].


----------



## 3Dnavigator (8. Juli 2013)

@saftmeister:
Leider finde ich nicht heraus, wie ich diesbezüglich netstat und/oder lsof anwenden muss, um das zu verifizieren.
Gemäss *mysqladmin -uroot -p processlist* sind immer 3 Prozesse aktiv, wenn der Fehler besteht. Wird einer davon beendet, (entweder mittels logout, oder der Server schiesst einen davon nach Ablauf der max_sleep_time (5 Minuten) ab) ist das Problem weg und alles funktioniert wieder wie es soll.

@para_noid:
Gemäss *mysqld --verbose --help*:
max-user-connections: 0
max-connections: 151


----------



## saftmeister (8. Juli 2013)

```
$ netstat -naop 2>/dev/null |grep 3306
$ lsof -n -P -p `pidof mysqld`
```


----------



## 3Dnavigator (8. Juli 2013)

netstat gibt keine Rückmeldung aufgrund des Befehls.
Beim lsof kommt:


```
-bash: pidof: command not found
lsof: no process ID specified
lsof 4.85
 latest revision: ftp://lsof.itap.purdue.edu/pub/tools/unix/lsof/
 latest FAQ: ftp://lsof.itap.purdue.edu/pub/tools/unix/lsof/FAQ
 latest man page: ftp://lsof.itap.purdue.edu/pub/tools/unix/lsof/lsof_man
 usage: [-?abhlnNoOPRtUvV] [+|-c c] [+|-d s] [+D D] [+|-f[cgG]]
 [-F [f]] [-g [s]] [-i [i]] [+|-L [l]] [+|-M] [-o [o]] [-p s]
[+|-r [t]] [-s [p:s]] [-S [t]] [-T [t]] [-u s] [+|-w] [-x [fl]] [--] [names]
Use the ``-h'' option to get more help information.
```


----------



## saftmeister (8. Juli 2013)

Läuft dein MySQL-Server nicht im Standard-Port 3306?


----------



## 3Dnavigator (8. Juli 2013)

Doch, das tut er


----------

