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
Anmeldungsdatum: 6. Dezember 2009
Beiträge: 12067
|
Hallo! Rechte / Benutzer und Gruppen Die Ausgabe von df -h; df -i auch uns zugänglich machen. 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
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
|