ubuntuusers.de

MySQL startet nicht

Status: Ungelöst | Ubuntu-Version: Ubuntu 18.04 (Bionic Beaver)
Antworten |

CountOmega

Anmeldungsdatum:
26. Mai 2019

Beiträge: 53

Hi Leute,

ich habe eine nextcloud Instanz auf einem SBC mit ubuntu 18.04 laufen. Mein Problem: mysql startet micht. Ich bekomme folgende Fehlermeldung:

 /usr/sbin/mysqld: Can't create file '/var/log/mysql/mysql_error.log' (errno: 13 "Permission denied") 

.

Hier die Verzeichnisberechtigungen:

 ls -la /var/log/mysql
total 45796
drwxr-s---  2 root  root       4096 Jan 12 20:00 .
drwxrwxr-x 15 root  syslog     4096 Jan 12 20:05 ..
-rw-rw----  1 root  root       1311 Jan  3 14:29 mariadb-bin.000001
-rw-rw----  1 root  root     494769 Jan  3 15:07 mariadb-bin.000002
-rw-rw----  1 root  root    1420755 Jan  3 18:31 mariadb-bin.000003
-rw-rw----  1 root  root    4789997 Jan  4 07:20 mariadb-bin.000004
-rw-rw----  1 root  root   34152536 Jan  8 18:59 mariadb-bin.000005
-rw-rw----  1 root  root      13745 Jan  9 18:42 mariadb-bin.000006
-rw-rw----  1 root  root    5718901 Jan  9 22:02 mariadb-bin.000007
-rw-rw----  1 root  root        367 Jan  9 22:15 mariadb-bin.000008
-rw-rw----  1 root  root     266240 Jan 10 16:19 mariadb-bin.000009
-rw-rw----  1 root  root        306 Jan 10 14:49 mariadb-bin.index
-rw-rw----  1 root  root         10 Jan  9 22:15 mariadb-bin.state
-rw-rw----  1 root  root          0 Jan 12 19:59 mariadb-bin.~rec~
-rw-r-----  1 mysql adm           0 Jan 14 22:00 mariadb-slow.log
-rw-rw----  1 root  root          0 Jan 14 22:00 mysql_error.log

Ich weiß, dass diese entsprechend angepasst werden müssen. Was sind hier die richtigen? Zudem habe ich festgestellt,dass

 df -h 

mir einen zu 100% volles var/log anzeigt. Was kann ich hier tun?

Danke

mit freundlichen Grüßen

ChickenLipsRfun2eat Team-Icon

Anmeldungsdatum:
6. Dezember 2009

Beiträge: 12067

Hallo!

  1. Rechte / Benutzer und Gruppen

  2. Die Ausgabe von df -h; df -i auch uns zugänglich machen.

  3. Platz in /var/log/ schaffen, z.B. mit logrotate oder manuell.

CountOmega

(Themenstarter)

Anmeldungsdatum:
26. Mai 2019

Beiträge: 53

Ja die richtigen Berechtigungen wären mysql:adm oder? Und für mysql dann bei logrotate einen cronjob erstellen?

CountOmega

(Themenstarter)

Anmeldungsdatum:
26. Mai 2019

Beiträge: 53

Hier die df - i Ausgabe:

countolan@rock64:~$ df -i
Filesystem        Inodes  IUsed     IFree IUse% Mounted on
udev              251108    433    250675    1% /dev
tmpfs             254231    620    253611    1% /run
/dev/mmcblk1p1   3681216 118232   3562984    4% /
tmpfs             254231      1    254230    1% /dev/shm
tmpfs             254231      3    254228    1% /run/lock
tmpfs             254231     18    254213    1% /sys/fs/cgroup
tmpfs             254231     23    254208    1% /tmp
/dev/sda1      122101760    260 122101500    1% /mnt/sda1
/dev/zram0         12800     66     12734    1% /var/log
tmpfs             254231     19    254212    1% /run/user/1000

CountOmega

(Themenstarter)

Anmeldungsdatum:
26. Mai 2019

Beiträge: 53

Also

 chown -R mysql:adm /var/log/mysql 

hat das Berechtigungsproblem gelöst.

CountOmega

(Themenstarter)

Anmeldungsdatum:
26. Mai 2019

Beiträge: 53

  service logrotate restart 

hat jetzt den Speicher auf 87% geleert.

CountOmega

(Themenstarter)

Anmeldungsdatum:
26. Mai 2019

Beiträge: 53

Jetzt ist /var/log wieder bei 100 % voll. Infolgedessen startet mysql wieder nicht.

Cranvil

Anmeldungsdatum:
9. März 2019

Beiträge: 990

Du bist uns noch ein

df -h 

schuldig geblieben.

Der Unterschied zwischen -h und -i ist vor allem, der, dass wir mit der ersten Option den freien, genutzten und gesamt vorhandenen Speicherplatz sehen können und nicht nur die Zahl der verfügbaren und genutzten Inodes.

Ich habe das Gefühl, dass dein /var/log auf einer ziemlich kleinen Partition liegt.

Du könntest mit einem

apt-get autoclean
# alternativ
apt-get clean 

dafür sorgen, dass dein lokaler Paketcache aufgeräumt wird und du damit mehr Platz in /var übrig hast. Im nächsten Schritt kannst du dann ncdu installieren und nachsehen, was da wirklich den Platz belegt.

CountOmega

(Themenstarter)

Anmeldungsdatum:
26. Mai 2019

Beiträge: 53

df -h

liefert

Filesystem      Size  Used Avail Use% Mounted on
udev            981M     0  981M   0% /dev
tmpfs           199M   21M  179M  11% /run
/dev/mmcblk1p1   57G   24G   33G  42% /
tmpfs           994M     0  994M   0% /dev/shm
tmpfs           5.0M     0  5.0M   0% /run/lock
tmpfs           994M     0  994M   0% /sys/fs/cgroup
tmpfs           994M   12K  994M   1% /tmp
/dev/sda1       1.8T   32G  1.7T   2% /mnt/sda1
/dev/zram0       49M   32M   14M  71% /var/log
tmpfs           199M  8.0K  199M   1% /run/user/1000

Ich dachte, dass eine Verkleinerung des Binlogs in der my.cnf etwas gebracht hätte. Dies ist anscheinend aber nicht der Fall. Weiß jemand, wie man diesen deaktiviert?

Cranvil

Anmeldungsdatum:
9. März 2019

Beiträge: 990

CountOmega schrieb:

Filesystem      Size  Used Avail Use% Mounted on
/dev/mmcblk1p1   57G   24G   33G  42% /
/dev/sda1       1.8T   32G  1.7T   2% /mnt/sda1
/dev/zram0       49M   32M   14M  71% /var/log

Ich dachte, dass eine Verkleinerung des Binlogs in der my.cnf etwas gebracht hätte. Dies ist anscheinend aber nicht der Fall. Weiß jemand, wie man diesen deaktiviert?

Das binäre Log von MySQL ist kein Log, das in /var/log gespeichert werden sollte. Es ist vielmehr ein Änderungslog, das MySQL für die Replikation zwischen Teilnehmern eines MySQL-Clusters verwendet und in bestimmten Wiederherstellungsszenarien (Quelle).

Hast du die Datenbank noch am Standardspeicherort liegen oder hast du sie von der SD-Karte (/dev/mmcblk1p1) auf die (externe?) Festplatte (/dev/sda1) geschoben? Mit Blick auf Performance und Lebenszeit könnte es interessant sein, die Datenbank von der SD-Karte wegzuziehen.

CountOmega

(Themenstarter)

Anmeldungsdatum:
26. Mai 2019

Beiträge: 53

Danke für die schnelle Antwort. Ich habe mariadb ganz normal installiert. Da ich ein eMMC-Modul benutze, wäre eine Verlegung der Datenbank eine Option.

CountOmega

(Themenstarter)

Anmeldungsdatum:
26. Mai 2019

Beiträge: 53

Das eigentliche Problem ist wiegesagt dass der Binlog zu schnell voll wird.

Cranvil

Anmeldungsdatum:
9. März 2019

Beiträge: 990

Ich habe nicht überprüft, wo MySQL sein Binlog in der Regel speichert, würde aber nicht unbedingt /var/log erwarten.

Hast du eigentlich einen Mechanismus, der dein /var/log regelmäßig auf einen persistenten Speicher synchronisiert? Momentan liegt es in einer 32 MB großen (z)RAM-Disk, was zumindest für mich bedeutet, dass du nie eine Möglichkeit haben wirst, eine Absturzursache anhand von Logs zu ermitteln.

CountOmega

(Themenstarter)

Anmeldungsdatum:
26. Mai 2019

Beiträge: 53

logrotate ist installiert verschiebt aber anscheinend die logs nicht. log2ram ist nicht installiert. Vielleicht zum besseren Verständnis hier die my.cnf:

[client]
default-character-set = utf8mb4
port = 3306
socket = /var/run/mysqld/mysqld.sock

[mysqld_safe]
log_error = /var/log/mysql/mysql_error.log
nice = 0
socket = /var/run/mysqld/mysqld.sock

[mysqld]
basedir = /usr
bind-address = 127.0.0.1
binlog_format = ROW
bulk_insert_buffer_size = 16M
character-set-server = utf8mb4
collation-server = utf8mb4_general_ci
concurrent_insert = 2
connect_timeout = 5
datadir = /var/lib/mysql
default_storage_engine = InnoDB
expire_logs_days = 1
general_log_file = /var/log/mysql/mysql.log
general_log = 0
innodb_buffer_pool_size = 1024M
innodb_buffer_pool_instances = 1
innodb_flush_log_at_trx_commit = 2
innodb_log_buffer_size = 32M
innodb_max_dirty_pages_pct = 90
innodb_file_per_table = 1
innodb_open_files = 400
innodb_io_capacity = 4000
innodb_flush_method = O_DIRECT
key_buffer_size = 128M
lc_messages_dir = /usr/share/mysql
lc_messages = en_US
log_bin = /var/log/mysql/mariadb-bin
log_bin_index =/var/log/mysql/mariadb-bin.index
log_error=/var/log/mysql/mysql_error.log
log_slow_verbosity = query_plan
log_warnings = 0
long_query_time = 1
max_allowed_packet = 16M
max_binlog_size = 10M
max_connections = 200
max_heap_table_size = 64M
myisam_recover_options = BACKUP
myisam_sort_buffer_size = 512M
port = 3306
pid-file = /var/run/mysqld/mysqld.pid
query_cache_limit = 2M
query_cache_size = 64M
query_cache_type = 1
query_cache_min_res_unit = 2k
read_buffer_size = 2M
read_rnd_buffer_size = 1M
skip-external-locking
skip-name-resolve
slow_query_log_file = /var/log/mysql/mariadb-slow.log
slow-query-log = 1
socket = /var/run/mysqld/mysqld.sock
sort_buffer_size = 4M
table_open_cache = 400
thread_cache_size = 128
tmp_table_size = 64M
tmpdir = /tmp
transaction_isolation = READ-COMMITTED
user = mysql
wait_timeout = 600

[mysqldump]
max_allowed_packet = 16M
quick
quote-names

[isamchk]
!include /etc/mysql/mariadb.cnf
!includedir /etc/mysql/conf.d/
key_buffer = 16M

Cranvil

Anmeldungsdatum:
9. März 2019

Beiträge: 990

Du stoppst deinen MySQL-Dienst (und ggf. den auf anderen Nodes eines Clusters) und kopierst dann das in datadir angegebene Verzeichnis an den gewünschten Zielort. Nach dem Kopieren die Berechtigungen überprüfen und natürlich das datadir anpassen. Die unten genannten Logdateien kannst du nach demselben Muster umziehen, wobei du die binlogs nicht unbedingt kopieren brauchst, da die nach einem geregelten Shutdown der Datenbank für den Server irrelevant sein sollten.

Hast du keine Replikation zu anderen Servern, kannst du nach den Änderungen deinen Datenbankdienst wieder starten und im Error-Log nachsehen, was dir alles um die Ohren fliegt. Wenn es beim ersten Versuch nicht klappt, kannst du gern die Fehler hier posten. Solang du das Quellverzeichnis nicht veränderst, solltest du den Vorgang auch beliebig oft wiederholen können. Es spricht natürlich trotzdem nichts gegen eine Sicherung (z.B. mit mysqldump). ☺

Falls du noch zu anderen Hosts replizierst, solltest du die Datenbankdaten einfach auf die anderen Nodes kopieren. Zumindest macht diese Nachricht 🇬🇧 den Eindruck.

general_log_file = /var/log/mysql/mysql.log
log_bin = /var/log/mysql/mariadb-bin
log_bin_index =/var/log/mysql/mariadb-bin.index
log_error=/var/log/mysql/mysql_error.log
slow_query_log_file = /var/log/mysql/mariadb-slow.log
Antworten |