I NEED HELP! MariaDB does not start properly after update!


Recommended Posts

7 minutes ago, mgutt said:

Aber von Nextcloud nicht oder evtl zu klein?

Bei mir sieht das so aus: terminal-screenshot.png.a96ad2a7f00e099ac4f6cc29e2b03e2f.png

 

Ich bin gleich soweit, um den text daraus zu kopieren.

 

Und:
Ich habe grade HeidiSQL auf meinem Rechner installiert, habe aber diesen fehler hier bekommen:
fehler-heididql.png.270e3b2cc9d96e33db8157f2c395d449.png

Link to comment

Ok und als Port hattest du 3306 in HeidiSQL stehen?

 

Das ist nicht gut.

 

Dann probiere mal was @vakilando empfahl. Und zwar gehst du hin und änderst den Repository Namen von MariaDB von:

linuxserver/mariadb

 

in:

linuxserver/mariadb:amd64-110.4.18mariabionic-ls18

 

Das ist eine Version von vor 19 Tagen:

https://hub.docker.com/r/linuxserver/mariadb/tags?page=1&ordering=last_updated&name=amd64

image.png.a09b3619b32d37b7f9d7842e332d1b2f.png

 

Der letzte amd64-latest ist von vor 12 Tagen:

image.png.efb42c20fa3a7ab5f70d111568d317dd.png

 

Die "DIGEST" ist auch die, die der "latest" entspricht und die hast du demnach aktuell drauf:

image.thumb.png.df1f1f4d549aaccd505caf96f2dbd2bf.png

 

Du könntest dann auch weiter zurückspringen zB die 2 Monate alte "amd64-110.4.18mariabionic-ls14". Es darf nur eben keine Version mit "alpine" im Namen sein.

Link to comment

Hm.

 

 

This image will soon be rebased *
* from ubuntu to alpine. *
* Please be aware, this may cause issues *
* It is strongly recommended to make backups *
* of your config and databases before *
* updating your image to the alpine base. *
* *
* *
******************************************************
******************************************************
[cont-init.d] 90-warning: exited 0.
[cont-init.d] 99-custom-scripts: executing...
[custom-init] no custom files found exiting...
[cont-init.d] 99-custom-scripts: exited 0.
[cont-init.d] done.
[services.d] starting services
[services.d] done.
210506 14:46:16 mysqld_safe Logging to syslog.
210506 14:46:16 mysqld_safe Starting mysqld daemon with databases from /config/databases
210506 14:46:19 mysqld_safe Logging to syslog.
210506 14:46:19 mysqld_safe Starting mysqld daemon with databases from /config/databases
210506 14:46:21 mysqld_safe Logging to syslog.
210506 14:46:21 mysqld_safe Starting mysqld daemon with databases from /config/databases
210506 14:46:24 mysqld_safe Logging to syslog.
210506 14:46:24 mysqld_safe Starting mysqld daemon with databases from /config/databases
210506 14:46:26 mysqld_safe Logging to syslog.
210506 14:46:26 mysqld_safe Starting mysqld daemon with databases from /config/databases
210506 14:46:28 mysqld_safe Logging to syslog.
210506 14:46:28 mysqld_safe Starting mysqld daemon with databases from /config/databases
210506 14:46:31 mysqld_safe Logging to syslog.
210506 14:46:31 mysqld_safe Starting mysqld daemon with databases from /config/databases
210506 14:46:33 mysqld_safe Logging to syslog.
210506 14:46:33 mysqld_safe Starting mysqld daemon with databases from /config/databases
210506 14:46:35 mysqld_safe Logging to syslog.
210506 14:46:35 mysqld_safe Starting mysqld daemon with databases from /config/databases
210506 14:46:38 mysqld_safe Logging to syslog.
210506 14:46:38 mysqld_safe Starting mysqld daemon with databases from /config/databases
210506 14:46:38 mysqld_safe Logging to syslog.
210506 14:46:38 mysqld_safe Starting mysqld daemon with databases from /config/databases
210506 14:46:40 mysqld_safe Logging to syslog.
210506 14:46:40 mysqld_safe Starting mysqld daemon with databases from /config/databases
210506 14:46:40 mysqld_safe Logging to syslog.
210506 14:46:40 mysqld_safe Starting mysqld daemon with databases from /config/databases
210506 14:46:42 mysqld_safe Logging to syslog.
210506 14:46:43 mysqld_safe Starting mysqld daemon with databases from /config/databases

 

 

 

 

 

 

 

Das ist ein kleiner abschmitt aus dem Log... es geht immer noch nicht.

Link to comment

Bin etwas spät zur Party hier:

 

1.) Netzwerk: Kontrolliere vorsichtshalber die my.cnf Datei im mariadb Container. Hier vor allen Dingen a.) steht 3306 im Port der Client Section und b.) sind beide bind-address auskommentiert?

 

2.) DB: Nach Deinen Backups, bevor Du komplett neu aufsetzt, kann es nicht schaden eine evtl. hängende und blockierende Transaktion zu beenden. Das ist mir mal passiert und ich konnte aus der mariadb Container Konsole mit folgendem Befehl die DB wieder reanimieren "mysqld --tc-heuristic-recover rollback".

 

3.) Nachdem Du alles wieder aufgesetzt hast: Zusätzlich zum nackten Backup der Dateien empfiehlt sich jede Nacht einen mysqldump zu ziehen. Kann man gut mit User Scripts machen:

 

docker exec mariadb /usr/bin/mysqldump --user=root --password=<dein passwort> <dbname> > /mnt/Backup/MariaDB/dump/<dbname>/dump.sql
docker stop mariadb
rsync -avPX --delete-during /mnt/pool_nvme/system/appdata/mariadb/ /mnt/Backup/MariaDB/config/
docker start mariadb

 

3b.) Da Nextcloud oder/und andere Container auf mariadb aufsetzen können, sollte man diese alternativ immer als Einheit betrachten. Beispiel:

 

docker exec mariadb /usr/bin/mysqldump --user=root --password=<dein passwort> <dbname> > /mnt/Backup/MariaDB/dump/<dbname>/dump.sql
docker stop nextcloud
docker stop mariadb
rsync -avPX --delete-during /mnt/pool_nvme/system/appdata/mariadb/ /mnt/Backup/MariaDB/config/
rsync -avPX --delete-during /mnt/pool_nvme/system/appdata/nextcloud/ /mnt/Backup/Nextcloud/config/
rsync -avPX --delete-during /mnt/pool_nvme/NextCloud/ /mnt/Backup/Nextcloud/data/
docker start mariadb
docker start nextcloud

 

Containernamen, Datenbanknamen, Pfadangaben, User und Passwort musst Du natürlich an Deine Umgebung anpassen.

 

Ich nutze ein Python Skript Backup in User Scripts und füge nach jedem der o.g. Befehle eine kurze Pause ein. User Script selbst jagt die Befehle hintereinander raus, was bei mir manchmal den Dump abgebrochen hat.

 

Es gibt aber auch eine Pause in bash, etc.

 

Edited by hawihoney
Link to comment

Kannst du einfach 

4 minutes ago, hawihoney said:

Das ist mir mal passiert und ich konnte aus der mariadb Container Konsole mit folgendem Befehl die DB wieder reanimieren "mysqld --tc-heuristic-recover rollback".

Es gibt doch bestimmt Befehle wo man den Status der Datenbanken prüfen kann oder?

Link to comment
7 minutes ago, Easy Tec said:

wo finde ich diese my.cnf

 

Click auf das Icon des MariaDB Container auf der Docker Seite und starte die Console. In der Console gibst Du "cat /etc/mysql/my.cnf" ein.

 

Und wenn Du schon mal dabei bist. Mach das gleiche mit dem Nextcloud Container. Also auf das Icon des Nextcloud Container klicken und die Console öffnen. Dort dann diesen Befehl eingeben "cat /config/www/nextcloud/config/config.php". Dort gibt es eine ganze Latte an db Variablen. Stimmen dort Datenbankname, Host IP und der 3306 Port sowie der User und das Passwort? Der User und das Passwort an der Stelle sind ein tatsächlicher User und nicht root.

 

Edited by hawihoney
Link to comment
18 minutes ago, hawihoney said:

1.) Netzwerk: Kontrolliere vorsichtshalber die my.cnf Datei im mariadb Container. Hier vor allen Dingen a.) steht 3306 im Port der Client Section und b.) sind beide bind-address auskommentiert?

Also: Port ist 3306 (also richtig)
Und beide "Bind-adress":

;bind-address           = 127.0.0.1

#bind-address=0.0.0.0

Link to comment
10 minutes ago, hawihoney said:

Und wenn Du schon mal dabei bist. Mach das gleiche mit dem Nextcloud Container. Also auf das Icon des Nextcloud Container klicken und die Console öffnen. Dort dasnn diesen Befehl eingeben "cat /config/www/nextcloud/config/config.php". Dort gibt es eine ganze Latte an db Variablen. Stimmen dort Datenbankname, Host IP und der 3306 Port sowie der User und das Passwort? Der User und das Passwort an der Stelle sind ein User und nicht root.

Hier in Nextcloud ist alles richtig.

 

Link to comment
7 minutes ago, mgutt said:

Es gibt doch bestimmt Befehle wo man den Status der Datenbanken prüfen kann oder?

 

Klar, diesmal aber vom Host ausführen und nicht aus der Container Console:

 

root@Tower:~# docker exec mariadb /usr/bin/mysqladmin --user=root --password=<dein passwort> status
Uptime: 39648  Threads: 8  Questions: 82991  Slow queries: 0  Opens: 78  Flush tables: 1  Open tables: 72  Queries per second avg: 2.093

 

Link to comment
4 minutes ago, Easy Tec said:

Hier in Nextcloud ist alles richtig.

 

Dann guck mal ob Du den Status abrufen kannst. Das steht in dem Post hier drüber. Ich denke, dass das nicht klappen wird, denn ich vermute immer noch ein Netzwerk Problem. Ich habe in den vergangenen über 40 Jahren fette Datenbanken administriert (IBM, Microsoft, ...) und das eine professionelle Dastenbank kaputt geht ist sehr, sehr, sehr, sehr selten. Da tippe ich immer zunächst auf andere Ursachen. Du kannst den Stecker mitten in Transaktionen ziehen, das macht alles nichts. Ich konzentriere mich immer zunächst auf möglicherweise defekte Platten, Filesysteme oder Fehlkonfigurationen.

 

Ist denn außer des Updates irgendetwas Außergewöhnliches passiert?

 

Link to comment
4 minutes ago, hawihoney said:

Klar, diesmal aber vom Host ausführen und nicht aus der Container Console:

 


root@Tower:~# docker exec mariadb /usr/bin/mysqladmin --user=root --password=<dein passwort> status
Uptime: 39648  Threads: 8  Questions: 82991  Slow queries: 0  Opens: 78  Flush tables: 1  Open tables: 72  Queries per second avg: 2.093

Bei mir kommt das hier wenn ich es eingebe:

 

root@Space:~# docker exec mariadb /usr/bin/mysqladmin --user=root --password=<mein passwort von mariaDB> status
/usr/bin/mysqladmin: connect to server at 'localhost' failed
error: 'Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (2)'
Check that mysqld is running and that the socket: '/var/run/mysqld/mysqld.sock' exists!

 

(natürlich habe ich die klammern < und > rausgenommen...)

Link to comment
3 minutes ago, hawihoney said:

Ist denn außer des Updates irgendetwas Außergewöhnliches passiert?

Nein.
Direkt nach dem update von MariaDB habe ich meine WP sites und Nextcloud aufgerufen und alle drei websites hatten nur errors...
MariaDB hat laut log nicht richtig starten können (siehe oben)

Link to comment
6 minutes ago, Easy Tec said:

connect to server at 'localhost' failed

 

Oh, interessant. Dann hänge mal IP und Port an. Das müssen die Werte sein, die in der Nextcloud Konfiguration unter dbhost angegeben sind - Du musst sie für den Befehl unten splitten:

 

docker exec mariadb /usr/bin/mysqladmin -h <die IP> -P <der Port> --user=root --password=<dein Passwort> status

 

Link to comment
4 minutes ago, hawihoney said:

Oh, interessant. Dann hänge mal IP und Port an. Das müssen die Werte sein, die in der Nextcloud Konfiguration unter dbhost angegeben sind - Du musst sie für den Befehl unten splitten:

 


docker exec mariadb /usr/bin/mysqladmin -h <die IP> -P <der Port> --user=root --password=<dein Passwort> status

Hierbei kommt:

 

/usr/bin/mysqladmin: connect to server at '192.168.178.56' failed
error: 'Lost connection to MySQL server at 'handshake: reading initial communication packet', system error: 11'
root@Space:~#

Link to comment
52 minutes ago, hawihoney said:

2.) DB: Nach Deinen Backups, bevor Du komplett neu aufsetzt, kann es nicht schaden eine evtl. hängende und blockierende Transaktion zu beenden. Das ist mir mal passiert und ich konnte aus der mariadb Container Konsole mit folgendem Befehl die DB wieder reanimieren "mysqld --tc-heuristic-recover rollback".

 

3.) Nachdem Du alles wieder aufgesetzt hast: Zusätzlich zum nackten Backup der Dateien empfiehlt sich jede Nacht einen mysqldump zu ziehen. Kann man gut mit User Scripts machen:

 


docker exec mariadb /usr/bin/mysqldump --user=root --password=<dein passwort> <dbname> > /mnt/Backup/MariaDB/dump/<dbname>/dump.sql
docker stop mariadb
rsync -avPX --delete-during /mnt/pool_nvme/system/appdata/mariadb/ /mnt/Backup/MariaDB/config/
docker start mariadb

 

3b.) Da Nextcloud oder/und andere Container auf mariadb aufsetzen können, sollte man diese alternativ immer als Einheit betrachten. Beispiel:

 


docker exec mariadb /usr/bin/mysqldump --user=root --password=<dein passwort> <dbname> > /mnt/Backup/MariaDB/dump/<dbname>/dump.sql
docker stop nextcloud
docker stop mariadb
rsync -avPX --delete-during /mnt/pool_nvme/system/appdata/mariadb/ /mnt/Backup/MariaDB/config/
rsync -avPX --delete-during /mnt/pool_nvme/system/appdata/nextcloud/ /mnt/Backup/Nextcloud/config/
rsync -avPX --delete-during /mnt/pool_nvme/NextCloud/ /mnt/Backup/Nextcloud/data/
docker start mariadb
docker start nextcloud

 

Containernamen, Datenbanknamen, Pfadangaben, User und Passwort musst Du natürlich an Deine Umgebung anpassen.

 

Ich nutze ein Python Skript Backup in User Scripts und füge nach jedem der o.g. Befehle eine kurze Pause ein. User Script selbst jagt die Befehle hintereinander raus, was bei mir manchmal den Dump abgebrochen hat.

 

Es gibt aber auch eine Pause in bash, etc.

Ganz kurz ne frage:

Es ist schon klar, das ich das hier noch nicht gemacht habe oder?  8-)

Link to comment
2 minutes ago, mgutt said:
31 minutes ago, Easy Tec said:

Also mit dem Befehl hier:

/config/databases/er.log

oder

Container Console:

mysqld_safe --log-error=er.log

 

Und dann:

cat /config/databases/er.log

Hier kam folgendes raus:

 

1)

210506 16:30:51 mysqld_safe Can't log to error log and syslog at the same time.  Remove all --log-error configuration options for --syslog to take effect.
210506 16:30:51 mysqld_safe Logging to '/config/databases/er.log'.
210506 16:30:51 mysqld_safe Starting mysqld daemon with databases from /config/databases

 

2)

# cat /config/databases/er.log
210506 16:30:51 mysqld_safe Starting mysqld daemon with databases from /config/databases
2021-05-06 16:30:51 0 [Note] /usr/sbin/mysqld (mysqld 10.4.18-MariaDB-1:10.4.18+maria~bionic-log) starting as process 12088 ...
2021-05-06 16:30:51 0 [ERROR] mysqld: Can't lock aria control file '/config/databases/aria_log_control' for exclusive use, error: 11. Will retry for 30 seconds
2021-05-06 16:30:53 0 [Note] InnoDB: Using Linux native AIO
2021-05-06 16:30:53 0 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins
2021-05-06 16:30:53 0 [Note] InnoDB: Uses event mutexes
2021-05-06 16:30:53 0 [Note] InnoDB: Compressed tables use zlib 1.2.11
2021-05-06 16:30:53 0 [Note] InnoDB: Number of pools: 1
2021-05-06 16:30:53 0 [Note] InnoDB: Using SSE2 crc32 instructions
2021-05-06 16:30:53 0 [Note] mysqld: O_TMPFILE is not supported on /tmp (disabling future attempts)
2021-05-06 16:30:54 0 [Note] InnoDB: Initializing buffer pool, total size = 256M, instances = 1, chunk size = 128M
2021-05-06 16:30:54 0 [Note] InnoDB: Completed initialization of buffer pool
2021-05-06 16:30:54 0 [Note] InnoDB: If the mysqld execution user is authorized, page cleaner thread priority can be changed. See the man page of setpriority().
2021-05-06 16:30:54 0 [Note] InnoDB: Transaction 14467775 was in the XA prepared state.
2021-05-06 16:30:54 0 [Note] InnoDB: 1 transaction(s) which must be rolled back or cleaned up in total 0 row operations to undo
2021-05-06 16:30:54 0 [Note] InnoDB: Trx id counter is 14467776
2021-05-06 16:30:54 0 [Note] InnoDB: 128 out of 128 rollback segments are active.
2021-05-06 16:30:54 0 [Note] InnoDB: Starting in background the rollback of recovered transactions
2021-05-06 16:30:54 0 [Note] InnoDB: Rollback of non-prepared transactions completed
2021-05-06 16:30:54 0 [Note] InnoDB: Creating shared tablespace for temporary tables
2021-05-06 16:30:54 0 [Note] InnoDB: Setting file './ibtmp1' size to 12 MB. Physically writing the file full; Please wait ...
2021-05-06 16:30:54 0 [Note] InnoDB: File './ibtmp1' size is now 12 MB.
2021-05-06 16:30:54 0 [Note] InnoDB: 10.4.18 started; log sequence number 6481424660; transaction id 14467777
2021-05-06 16:30:54 0 [Note] InnoDB: Loading buffer pool(s) from /config/databases/ib_buffer_pool
2021-05-06 16:30:54 0 [Note] Plugin 'FEEDBACK' is disabled.
2021-05-06 16:30:54 0 [Note] InnoDB: Starting recovery for XA transactions...
2021-05-06 16:30:54 0 [Note] InnoDB: Transaction 14467775 in prepared state after recovery
2021-05-06 16:30:54 0 [Note] InnoDB: Transaction contains changes to 1 rows
2021-05-06 16:30:54 0 [Note] InnoDB: 1 transactions in prepared state after recovery
2021-05-06 16:30:54 0 [Note] Found 1 prepared transaction(s) in InnoDB
2021-05-06 16:30:54 0 [ERROR] Found 1 prepared transactions! It means that mysqld was not shut down properly last time and critical recovery information (last binlog or tc.log file) was manually deleted after a crash. You have to start mysqld with --tc-heuristic-recover switch to commit or rollback pending transactions.
2021-05-06 16:30:54 0 [ERROR] Aborting
210506 16:30:56 mysqld_safe mysqld from pid file /var/run/mysqld/mysqld.pid ended

 

 

 

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.