Datei /var/lib/mysql/user.lower-test kann nicht erstellt werden

Die MySQL-Datenbank ist seit einigen Monaten problemlos. Als ich heute mit dem Synaptic Package Manager nach aktualisierbaren Paketen suchte, kamen die verschiedenen MySQL-Komponenten (-common, -client, -server usw.) auf. Ich entschied mich daher für ein Upgrade (ich habe vergessen, die installierte Version zu notieren, glaube aber, dass es 5.6.21 war) auf 5.6.25-1-ubuntu2.0. Als ich anschließend die Datenbank abfragte, erhielt ich die folgende Meldung:

Error occured: Can't connect to MySQL server on '127.0.0.1' (111)

Ich fand dann, dass der Server nicht lief. In der Protokolldatei finde ich es gut, dass die Nachricht: -

Can't create file /var/lib/mysql/user.lower-test

Ich habe ungefähr eine Stunde online gesucht und obwohl das Problem bereits gemeldet wurde, habe ich es nicht im Zusammenhang mit einem Problem nach dem Update gesehen, bei dem ich mir über meinen nächsten Schritt nicht sicher bin.

Dieses Problem scheint Berechtigungsprobleme zu verursachen oder das MySQL-Datenverzeichnis an einen anderen Speicherort als / var / lib / mysql zu ändern.

Versuche mit sudo zu rennen

Es sieht so aus, als ob / var / lib / mysql dem mysql-Benutzer gehört und die Gruppe ebenfalls auf mysql gesetzt ist.

$ sudo chown -R mysql /var/lib/mysql
$ sudo chgrp -R mysql /var/lib/mysql
$ sudo chmod 755 /var/lib/mysql

Haben Sie überprüft, ob das Verzeichnis / var / lib / mysql tatsächlich existiert und Ihrem Datenverzeichnis entspricht? Wenn dies nicht der Fall ist, müssen Sie wahrscheinlich den Parameter datadir im Abschnitt mysqld anderweitig angeben

[mysqld]
datadir=/var/lib/mysql

Anschließend können Sie zwischen der Konfiguration von Apparmor wählen, damit MySQL das neue Datenverzeichnis und die Unterverzeichnisse lesen \ ausführen \ ändern kann, oder Apparmor auf eigenes Risiko entfernen. Möglicherweise müssen Sie root sein, um Folgendes zu tun:

/etc/init.d/apparmor stop
/etc/init.d/apparmor teardown
update-rc.d -f apparmor remove
apt-get purge apparmor
reboot

Ich bin auf dieses Problem gestoßen, als ich versucht habe, mehrere Instanzen von MySQL auszuführen, aber anstatt Apparmor zu entfernen, habe ich die Datei usr.sbin.mysqld aktualisiert:

vim /etc/apparmor.d/usr.sbin.mysqld

So sieht beispielsweise meine Datei aus, und nachdem ich die Ordner hinzugefügt habe, für die Schreibberechtigungen erforderlich sind, funktionierten alle ordnungsgemäß.

/usr/sbin/mysqld {

  capability dac_override,
  capability sys_resource,
  capability setgid,
  capability setuid,

  network tcp,

  /etc/hosts.allow r,
  /etc/hosts.deny r,

  /etc/mysql/*.pem r,
  /etc/mysql/conf.d/ r,
  /etc/mysql/conf.d/* r,
  /etc/mysql/*.cnf r,
  /usr/lib/mysql/plugin/ r,
  /usr/lib/mysql/plugin/*.so* mr,
  /usr/sbin/mysqld mr,
  /usr/share/mysql/** r,
  /var/log/mysql.log rw,
  /var/log/mysql.err rw,
  /var/lib/mysql/ r,
  /var/lib/mysql/** rwk,
  /var/lib/mysql1/ r,
  /var/lib/mysql1/** rwk,
  /var/log/mysql/ r,
  /var/log/mysql/* rw,
  /var/run/mysqld/mysqld.pid rw,
  /var/run/mysqld/mysqld.sock w,
  /var/run/mysqld/mysqld1.pid rw,
  /var/run/mysqld/mysqld1.sock w,
  /run/mysqld/mysqld.pid rw,
  /run/mysqld/mysqld.sock w,

  /sys/devices/system/cpu/ r,

}

Das Problem ist mir passiert, als ich versucht habe, / var / lib / mysql auf eine andere Festplatte zu verschieben und das ursprüngliche Verzeichnis durch einen Symlink zu ersetzen.

Apparmor verweigert den Zugriff in dieser Konfiguration siehe

• https://bugs.launchpad.net/apparmor/+bug/1485055

Warum dies von den Apparmor-Entwicklern nicht als Fehler angesehen wird. Die Problemumgehung besteht darin, ein Bind-Mount zu verwenden. Sehen

• /unix/198590/what-is-a-bind-mount

für eine Erklärung.

So

mount --bind /newmysqldatadir /var/lib/mysql
service mysql start

Das Problem wurde für mich behoben.

Ich hatte ein ähnliches Problem. Ich habe Ubuntu Server auf meinem Computer neu installiert, eine vollständige Sicherung von / etc / auf einer Festplatte erstellt und nach der Neuinstallation eine Kopie aller wichtigen Dateien von / drive / etc / auf meine Systeme / etc. Erstellt.

Dabei habe ich ein Bak für die Datei usr.sbin.mysqld mit dem Namen usr.sbin.mysqld.bak erstellt und im selben Verzeichnis /etc/apparmor.d/ gespeichert.

Bei weiterer Suche fand ich diesen Blog-Beitrag: https://blogs.oracle.com/jsmyth/apparmor-and-mysql

Apparmor-utils installiert und versucht, sich auf / usr / sbin / mysqld zu beschweren, und es wurde angegeben, dass ich 2 Apparmor-Konfigurationen definiert habe (beide meiner Dateien).

Ich weiß, dass es möglicherweise nicht das Problem ist, mit dem Sie konfrontiert sind, aber aus Gründen der Klarheit sollten Sie nicht so dumm sein wie ich und eine Sicherungsdatei im selben Verzeichnis wie das Verzeichnis apparmor sbin erstellen.

Überprüfen Sie auch, ob Ihre Partition nicht voll ist, was mein Fall war.

Aus einem unbekannten Grund funktionierte das Verschieben der Daten auf eine andere Partition ebenfalls nicht.

Für eine schnelle Lösung habe ich meine /swapfileGröße reduziert, anstatt mich mit llvm oder gparted herumzuschlagen .