mysql kann beim Debian-Start (systemd) nicht gestartet werden, aber der manuelle Start funktioniert

mysql kann beim Debian-Start (systemd) nicht gestartet werden, aber der manuelle Start funktioniert

Ich habe ein seltsames Problem mit MySQL auf einem Debian-Server (Jessie).

Beim Neustart des Servers versucht systemd, mysqld zu starten, aber es schlägt fehl (es sieht so aus, als ob Port 3306 bereits verwendet wird, aber ich verstehe nicht, warum das sein sollte).

Wenn ich jedoch nur wenige Minuten später per SSH eine Verbindung zum Server herstelle und sudo systemctl start mysqles ausführe, ist der Vorgang erfolgreich.

Das Problem kann bei jedem Neustart des Servers reproduziert werden.

Hatte jemand dieses Problem schon einmal oder hat jemand eine Vermutung, was den korrekten Start von MySQL verhindern könnte? Ich könnte eine Verzögerung hinzufügen, bevor MySQL nach dem Neustart gestartet wird, aber ich würde gerne verstehen, was los ist, und eigentlich bin ich mir nicht einmal sicher, ob das das Problem beheben würde.

Hier ist das Ergebnis sudo systemctl status mysql -lnach dem Neustart:

● mysql.service - LSB: Start and stop the mysql database server daemon
   Loaded: loaded (/etc/init.d/mysql)
   Active: failed (Result: exit-code) since Fri 2017-09-01 21:54:44 CEST; 1min 41s ago
  Process: 581 ExecStart=/etc/init.d/mysql start (code=exited, status=1/FAILURE)

Sep 01 21:54:06 gimli systemd[1]: Starting LSB: Start and stop the mysql database server daemon...
Sep 01 21:54:44 gimli mysql[581]: Starting MySQL database server: mysqld . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . failed!
Sep 01 21:54:44 gimli systemd[1]: mysql.service: control process exited, code=exited status=1
Sep 01 21:54:44 gimli systemd[1]: Failed to start LSB: Start and stop the mysql database server daemon.
Sep 01 21:54:44 gimli systemd[1]: Unit mysql.service entered failed state.

und das entsprechende Protokoll von/var/log/mysql/error.log

170901 21:54:16 [Warning] Using unique option prefix myisam-recover instead of myisam-recover-options is deprecated and will be removed in a future release. Please use the full name instead.
170901 21:54:16 [Note] Plugin 'FEDERATED' is disabled.
170901 21:54:17 InnoDB: The InnoDB memory heap is disabled
170901 21:54:17 InnoDB: Mutexes and rw_locks use GCC atomic builtins
170901 21:54:17 InnoDB: Compressed tables use zlib 1.2.8
170901 21:54:17 InnoDB: Using Linux native AIO
170901 21:54:17 InnoDB: Initializing buffer pool, size = 128.0M
170901 21:54:17 InnoDB: Completed initialization of buffer pool
170901 21:54:17 InnoDB: highest supported file format is Barracuda.
170901 21:54:22  InnoDB: Waiting for the background threads to start
170901 21:54:23 InnoDB: 5.5.57 started; log sequence number 351234412
170901 21:54:23 [Note] Server hostname (bind-address): '192.168.1.14'; port: 3306
170901 21:54:23 [Note]   - '192.168.1.14' resolves to '192.168.1.14';
170901 21:54:23 [Note] Server socket created on IP: '192.168.1.14'.
170901 21:54:23 [ERROR] Can't start server: Bind on TCP/IP port: Cannot assign requested address
170901 21:54:23 [ERROR] Do you already have another mysqld server running on port: 3306 ?
170901 21:54:23 [ERROR] Aborting

170901 21:54:23  InnoDB: Starting shutdown...
170901 21:54:24  InnoDB: Shutdown completed; log sequence number 351234412
170901 21:54:24 [Note] /usr/sbin/mysqld: Shutdown complete

Wenn ich es jedoch sudo systemctl start mysqlmanuell ausführe, funktioniert es ordnungsgemäß:

170901 22:01:36 [Warning] Using unique option prefix myisam-recover instead of myisam-recover-options is deprecated and will be removed in a future release. Please use the full name instead.
170901 22:01:36 [Note] Plugin 'FEDERATED' is disabled.
170901 22:01:36 InnoDB: The InnoDB memory heap is disabled
170901 22:01:36 InnoDB: Mutexes and rw_locks use GCC atomic builtins
170901 22:01:36 InnoDB: Compressed tables use zlib 1.2.8
170901 22:01:36 InnoDB: Using Linux native AIO
170901 22:01:36 InnoDB: Initializing buffer pool, size = 128.0M
170901 22:01:36 InnoDB: Completed initialization of buffer pool
170901 22:01:36 InnoDB: highest supported file format is Barracuda.
170901 22:01:36  InnoDB: Waiting for the background threads to start
170901 22:01:37 InnoDB: 5.5.57 started; log sequence number 351234412
170901 22:01:37 [Note] Server hostname (bind-address): '192.168.1.14'; port: 3306
170901 22:01:37 [Note]   - '192.168.1.14' resolves to '192.168.1.14';
170901 22:01:37 [Note] Server socket created on IP: '192.168.1.14'.
170901 22:01:37 [Note] Event Scheduler: Loaded 0 events
170901 22:01:37 [Note] /usr/sbin/mysqld: ready for connections.
Version: '5.5.57-0+deb8u1'  socket: '/var/run/mysqld/mysqld.sock'  port: 3306  (Debian)

Meines Wissens wurde das systemd-Skript nicht geändert (es ist das, das im Debian-MySQL-Paket enthalten ist) und meines Wissens hat es nie richtig funktioniert. Der Port 3306 darf nicht von einem anderen Prozess verwendet werden.

Antwort1

Versuchen Sie direkt nach dem Neustart und der Ausführung als Root, sich per SSH beim Server anzumelden, netstat -lp | grep 3306um zu überprüfen, welches Programm tatsächlich auf diesem Port lauscht, damit Sie das Problem weiter debuggen können.

Antwort2

Offenbar bestand das Problem darin, dass die Netzwerkschnittstelle beim Start von MySQL nicht aktiv war. Dies hängt wahrscheinlich damit zusammen, dass DHCP etwas Zeit in Anspruch nimmt.

Nachdem ich die Schnittstelle nun auf eine statische IP eingestellt habe, tritt das MySQL-Problem zumindest nicht mehr auf (und ist auch bei jedem Start reproduzierbar). Damit ist das Problem also gelöst.

So legen Sie unter Debian eine statische IP fest:

  1. Stellen Sie sicher, dass Sie physischen Zugriff auf Ihren Server haben (Einschaltknopf, Tastatur, Bildschirm), bevor Sie versuchen, das Netzwerk zu manipulieren, da Sie sonst die SSH-Fähigkeit verlieren könnten.
  2. /etc/network/interfaces bearbeiten
  3. ersetzen iface eth0 inet dhcpdurch:

    iface eth0 inet static
        address 192.168.1.14
        network 192.168.1.0
        netmask 255.255.255.0
        broadcast 192.168.1.255
        gateway 192.168.1.1
    
  4. Neustart (Hinweis: Ein Neustart des Netzwerks sollte ausreichen, beispielsweise mit systemctl restart networking, aber in meinem Fall habe ich die Verbindung verloren, konnte sie aber nicht wiederherstellen, ohne den Server mit dem Netzschalter neu zu starten)

In diesem Beispiel weise ich die statische IP 192.168.1.14 und das Gateway 192.168.1.1 zu

Natürlich handelt es sich dabei nur um eine Problemumgehung. Das wirkliche Problem besteht darin, dass MySQL warten sollte, bis die Netzwerkschnittstelle aktiv ist, aber ich kenne mich mit systemd nicht gut genug aus, um das zu tun.

verwandte Informationen