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


84 posts in this topic Last Reply

Recommended Posts

3 minutes ago, hawihoney said:
17 minutes ago, Easy Tec said:

/usr/bin/mysqladmin: connect to server at '192.168.178.56' failed

 

... und wenn Du das hier jetzt in der mariadb Container Console eingibst:

 


/usr/bin/mysqladmin -h <deine ip> -P <dein port> --user=root --password=<dein passwort> status

Da bekomme ich das hier:

 

/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'

Link to post
  • Replies 83
  • Created
  • Last Reply

Top Posters In This Topic

Popular Days

Top Posters In This Topic

Popular Posts

Bingo!   Mach das mal aus der mariadb Console "mysqld --tc-heuristic-recover rollback"  

Posted Images

Posted (edited)
7 minutes ago, Easy Tec said:

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.

 

Bingo!

 

Mach das mal aus der mariadb Console "mysqld --tc-heuristic-recover rollback"

 

Edited by hawihoney
Link to post
2 minutes ago, hawihoney said:

Mach das mal aus der mariadb Console "mysqld --tc-heuristic-recover rollback"

Dann kommt das hier:

 

# mysqld --tc-heuristic-recover rollback
2021-05-06 16:42:52 0 [Note] mysqld (mysqld 10.4.18-MariaDB-1:10.4.18+maria~bionic-log) starting as process 20441 ...
2021-05-06 16:42:52 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:42:56 0 [Note] InnoDB: Using Linux native AIO
2021-05-06 16:42:56 0 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins
2021-05-06 16:42:56 0 [Note] InnoDB: Uses event mutexes
2021-05-06 16:42:56 0 [Note] InnoDB: Compressed tables use zlib 1.2.11
2021-05-06 16:42:56 0 [Note] InnoDB: Number of pools: 1
2021-05-06 16:42:56 0 [Note] InnoDB: Using SSE2 crc32 instructions
2021-05-06 16:42:56 0 [Note] mysqld: O_TMPFILE is not supported on /tmp (disabling future attempts)
2021-05-06 16:42:56 0 [Note] InnoDB: Initializing buffer pool, total size = 256M, instances = 1, chunk size = 128M
2021-05-06 16:42:56 0 [Note] InnoDB: Completed initialization of buffer pool
2021-05-06 16:42:56 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:42:56 0 [Note] InnoDB: Transaction 14467775 was in the XA prepared state.
2021-05-06 16:42:56 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:42:56 0 [Note] InnoDB: Trx id counter is 14467776
2021-05-06 16:42:56 0 [Note] InnoDB: 128 out of 128 rollback segments are active.
2021-05-06 16:42:56 0 [Note] InnoDB: Starting in background the rollback of recovered transactions
2021-05-06 16:42:56 0 [Note] InnoDB: Rollback of non-prepared transactions completed
2021-05-06 16:42:56 0 [Note] InnoDB: Creating shared tablespace for temporary tables
2021-05-06 16:42:56 0 [Note] InnoDB: Setting file './ibtmp1' size to 12 MB. Physically writing the file full; Please wait ...
2021-05-06 16:42:56 0 [Note] InnoDB: File './ibtmp1' size is now 12 MB.
2021-05-06 16:42:56 0 [Note] InnoDB: 10.4.18 started; log sequence number 6481427492; transaction id 14467777
2021-05-06 16:42:56 0 [Note] InnoDB: Loading buffer pool(s) from /config/databases/ib_buffer_pool
2021-05-06 16:42:56 0 [Note] Plugin 'FEEDBACK' is disabled.
2021-05-06 16:42:56 0 [Note] Heuristic crash recovery mode
2021-05-06 16:42:56 0 [Note] InnoDB: Starting recovery for XA transactions...
2021-05-06 16:42:56 0 [Note] InnoDB: Transaction 14467775 in prepared state after recovery
2021-05-06 16:42:56 0 [Note] InnoDB: Transaction contains changes to 1 rows
2021-05-06 16:42:56 0 [Note] InnoDB: 1 transactions in prepared state after recovery
2021-05-06 16:42:56 0 [Note] Found 1 prepared transaction(s) in InnoDB
2021-05-06 16:42:56 0 [Note] Please restart mysqld without --tc-heuristic-recover
2021-05-06 16:42:56 0 [ERROR] Can't init tc log
2021-05-06 16:42:56 0 [ERROR] Aborting

Link to post
3 minutes ago, hawihoney said:
10 minutes ago, Easy Tec said:

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.

 

Bingo!

 

Mach das mal aus der mariadb Console "mysqld --tc-heuristic-recover rollback"

HEY! Danke! Es geht wieder alles!
Muss ich jetzt noch irgendetwas machen?

Wahrscheinliche jetzt das, wovon vorhin die rede war oder

 

Link to post

Ich würde jetzt zunächst kontrollieren ob Du die aktuelle Version des MariaDB Containers nutzt. Also Update Check und ggfs. updaten.

 

Wenn nicht aktualisiert wurde würde ich den MariaDB Container selbst mal neu starten und kontrollieren ob noch alles läuft.

 

Wenn alles läuft würde ich für alle MariaDB Datenbanken folgenden Befehl absetzen und einen Dump ziehen und sicher auf Seite legen. Die Befehle rufst Du von der Server Konsole auf. Die Ziel Verzeichnisse passt Du bitte an Deine Umgebung an:

 

docker exec mariadb /usr/bin/mysqldump --user=root --password=<dein passwort> <dbname #1> > /mnt/Backup/MariaDB/dump/<dbname #1>/dump.sql
docker exec mariadb /usr/bin/mysqldump --user=root --password=<dein passwort> <dbname #2> > /mnt/Backup/MariaDB/dump/<dbname #2>/dump.sql

 

Über eine vernünftige Backup-Strategie kannst Du dann ja mal nachdenken.

 

Link to post
Just now, hawihoney said:

ch würde jetzt zunächst kontrollieren ob Du die aktuelle Version des MariaDB Containers nutzt. Also Update Check und ggfs. updaten.

Sicher? Weil vorhin haben wir ja festgestellt, das genau das ja wohl das Problem erstell hat...

Die "neuste Version" die ich laden kann, müsste doch die sein, die offiziel noch nicht da ist... oder

 

Link to post
1 minute ago, Easy Tec said:

Sicher?

 

Hmm, ich nutze einfach nur linuxserver/mariadb. Das ist angeblich der neue Alpine Build. Die Warnung vor dem Alpine Build ist aber auch bei mir in den Logs. Bin mir nicht sicher was ich derzeit im Einsatz habe. Weiß jemand wie man das erkenne kann?

 

Mach mal keinen Update solange ich das nicht rausbekommen habe.

 

Die Backups würde ich an Deiner Stelle aber auf jeden Fall ziehen.

 

Link to post
1 minute ago, hawihoney said:

 

Mach mal keinen Update solange ich das nicht rausbekommen habe.

Okay. Vielen Dank!

 

1 minute ago, hawihoney said:

Die Backups würde ich an Deiner Stelle aber auf jeden Fall ziehen.

Jip. Die mache ich jetzt.

Link to post
1 minute ago, Easy Tec said:

Die kommen bei mir auch noch und müllen das Log zu...

 

Du hast aber noch das alte Release, oder? Da wäre das verständlich. Ich vermute, dass ich das Neue habe. Auf Linuxserver.io ist der stable mariadb Container identisch mit der Alpine Version. Also habe ich vermutlich das neue Release. Ich tippe, will Dich aber nicht verleiten, dass es nicht am Update lag.

 

Als bekennendes Spielkind würde ich das natürlich sofort ausprobieren. Ich hätte ja jetzt Sicherungen der Datenbanken (die würde ich an zwei verschiedene Stellen legen, eine extern auf USB). Aber wie gesagt, Du musst das nicht tun.

 

Link to post

#!/bin/bash
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

 

So würde das skript für eine Datenbanksicherung (ohne meine Daten) abgespeichert werden in Userskripts von Unraid...

Das passt ja dann so, aber noch ne frage:
Dieses skript würde wenn ich es autostarten lasse, dann jeden Abend (kommt drauf an, wie ich es einstelle) ein Backup von der einen Datenbank die im Skript steht im Pfad /mnt/Backup/MariaDB/dump/<der name meiner Datenbank>/dump.sql speichern.
Heißt ich brauche für jede Datenbank dann en solches skript... oder

Link to post
4 minutes ago, hawihoney said:

Du hast aber noch das alte Release, oder?

Genau. Hab ich vorhin runtergeladen...

Der Genaue Name: linuxserver/mariadb:amd64-110.4.18mariabionic-ls18

5 minutes ago, hawihoney said:

Ich tippe, will Dich aber nicht verleiten, dass es nicht am Update lag.

Hm... Okay. Ich lasse e wohl erstmal so, aber werde wohl bald das update machen müssen...

Aber eigendlich kann ich jederzeit wieder ein update machen...

(Und selbst WENN wieder etwas schiefgeht beim Update, weiß ich ja jetzt, wenn ich fragen kann :))

 

Link to post
Posted (edited)
9 minutes ago, Easy Tec said:

#!/bin/bash
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

 

So würde das skript für eine Datenbanksicherung (ohne meine Daten) abgespeichert werden in Userskripts von Unraid...

Das passt ja dann so, aber noch ne frage:
Dieses skript würde wenn ich es autostarten lasse, dann jeden Abend (kommt drauf an, wie ich es einstelle) ein Backup von der einen Datenbank die im Skript steht im Pfad /mnt/Backup/MariaDB/dump/<der name meiner Datenbank>/dump.sql speichern.
Heißt ich brauche für jede Datenbank dann en solches skript... oder

also ausgefüll würde des für meine NC also so aussehen:

 

#!/bin/bash
docker exec mariadb /usr/bin/mysqldump --user=root --<mein Passwort von MariaDB> <Mein NextcloudDB user> > /mnt/Backup/MariaDB/dump/<Mein NextcloudDB user>/dump.sql
docker stop mariadb
rsync -avPX --delete-during /mnt/pool_nvme/system/appdata/mariadb/ /mnt/Backup/MariaDB/config/
docker start mariadb

 

Das müsste so gehen oder
Weil des mit den Pfaden hab ich nicht so ganz verstanden

Edited by Easy Tec
Link to post
10 minutes ago, Easy Tec said:

Weil des mit den Pfaden hab ich nicht so ganz verstanden

 

Du musst die anpassen. Wo ist Dein mariab Container Verzeichnis - anpassen. Wo willst Du den Dump hinlegen - anpassen.

 

Link to post

Mach erst das Backup von allen Datenbanken als SQL Datei.

 

Danach stoopst du Nextcloud und WP. Erst dann kannst du den Namen vom Repository zurück ändern. Das entspricht dann "latest". @hawihoney alpine ist noch nicht im normalen Release. Dazu müsste man extra einen separaten alpine tag angeben.

 

Und das machst du in Zukunft immer so. Erst die anderen Container stoppen, bevor du die DB aktualisierst. Ich vermute nämlich, dass während dem DB Update zb Nextcloud gerade was in die DB schreiben wollte, was dann nicht mehr vollständig erledigt werden konnte.

Link to post
5 minutes ago, hawihoney said:

Du musst die anpassen. Wo ist Dein mariab Container Verzeichnis - anpassen. Wo willst Du den Dump hinlegen - anpassen.

#!/bin/bash
docker exec mariadb /usr/bin/mysqldump --user=root --password=<mein Passwort von MariaDB> <MariaDB user von nextcloud> > /mnt/user/mariadb_backups/dump/nextcloud/dump.sql
docker stop mariadb
rsync -avPX --delete-during /mnt/pool_nvme/system/appdata/mariadb/ /mnt/Backup/MariaDB/config/
docker start mariadb

 

So?
Muss ich "/usr/bin/mysqldump" noch anpassen? (wenn ja wie)

Und "/mnt/pool_nvme/system/appdata/mariadb/ /mnt/Backup/MariaDB/config/" muss ich das auch anpassen? (wenn ja wie)

 

Tut mir leid, das ich das noch frage.. :/

Link to post
4 minutes ago, mgutt said:

Und das machst du in Zukunft immer so. Erst die anderen Container stoppen, bevor du die DB aktualisierst. Ich vermute nämlich, dass während dem DB Update zb Nextcloud gerade was in die DB schreiben wollte, was dann nicht mehr vollständig erledigt werden konnte.

Das kann gut sein! Okay.

 

5 minutes ago, mgutt said:

 

Danach stoopst du Nextcloud und WP. Erst dann kannst du den Namen vom Repository zurück ändern. Das entspricht dann "latest".

Okay. Also das ändere ich gleich (schreib auch gleich rein, ob es geklappt hat)

Davor möchte ich dann aber noch ein backup davon haben.. verständlich :D

6 minutes ago, mgutt said:

Mach erst das Backup von allen Datenbanken als SQL Datei.

Also mit dem Skript von @hawihoney?

Link to post

Und wie könnte man diese ganzen Backups dann auseinader halten? Überschreiben die sich gegenseitig?

oder kann man da noch einen teil einfügen, der dann noch das datum zum Beispiel vor .sql schreibt?

Link to post
7 minutes ago, Easy Tec said:

Und wie könnte man diese ganzen Backups dann auseinader halten?

Je einen Verzeichnisnamen pro Datenbank am Ziel würde ich nehmen. Und meine system/appdata Angabe musst Du auf Deinen appdata Ordner anpassen. Du kannst nicht einfach meine Verzeichnisse nehmen. Wenn Du solche Systeme betreiben willst solltest Du Dir auch ein paar eigene Gedanken machen und nicht einfach alles kopieren.

 

 

Link to post
7 minutes ago, hawihoney said:

Je einen Verzeichnisnamen pro Datenbank am Ziel würde ich nehmen.

Also z.B. nextcloud (oder wordpress)?

Des habe ich ja schon...
 

9 minutes ago, hawihoney said:

Und meine system/appdata Angabe musst Du auf Deinen appdata Ordner anpassen.

Heißt von:

/mnt/pool_nvme/system/appdata/mariadb/

müsste ich also auf:

/mnt/user/appdata/mariadb/

wechseln... okay

 

Okay. Dann probiere ich es mal so aus

Link to post

So. Das hier ist mein fertiges skript, so wie es in unraid steht.

#!/bin/bash
docker exec mariadb /usr/bin/mysqldump --user=root --<Mein MariaDB passwort> <MariaDB user> > /mnt/user/mariadb_backups/dump/nextcloud/dump.sql
docker stop mariadb
rsync -avPX --delete-during /mnt/user/appdata/mariadb/ /mnt/user/mariadb_backups/MariaDB/config/
docker start mariadb

 

 

Dieser Pfad "/mnt/user/mariadb_backups/dump/nextcloud/dump.sql" wird wahrscheinlich mit ertellt wenn er nicht existiert. Oder muss ich die jeweiligen Ordner noch erstellen

Link to post
34 minutes ago, Easy Tec said:

Und "/mnt/pool_nvme/system/appdata/mariadb/ /mnt/Backup/MariaDB/config/" muss ich das auch anpassen? (wenn ja wie)

 

In Unraid liegen alle Shares und Platten unter /mnt. Hast du zB eine disk1 im Array, dann erreicht man die über /mnt/disk1. Hast du einen Cache Pool mit dem Namen "cache", dann den über /mnt/cache. Hast du einen Share erstellt, dann erreichst du den über /mnt/user/sharename.

 

hawihoney hat zB als Quelle "mnt/nvme_pool/system" genommen. Er will also, dass sein Backup Script direkt auf den Pool namens "nvme_pool" zugreift. Genauso gut hätte er aber auch "mnt/user/system" schreiben können. Warum er dann noch appdata unterhalb von system hat ist sein Geheimnis. Ist auf jeden Fall "nicht normal" ^^

 

Jedenfalls liegen standardmäßig alle Container Nutzerdaten im share "appdata" und wenn du also nun "mnt/user/appdata" als Quelle angibst, dann wirst du alle Nutzerdaten aller Container auf die Art erfassen können.

 

Was du nun als Ziel angibst, liegt dir natürlich frei. Sagen wir du hast einen Share namens "Backups". Dann wäre zB ein passendes Ziel "/mnt/user/Backups/appdata".

 

Hinweis: Es ist nicht empfohlen Container zu sichern, die gerade laufen. Besser ist es alle Container zu stoppen und erst dann ein Backup zu erstellen. Ich verkompliziere ungern die Sache, aber das muss einfach gesagt werden. Aus dem Grund empfehle ich dir kein Script, sondern das Plugin "Appdata Backup". Der Entwickler hat diesen Punkt bereits berücksichtigt.

 

Analog dazu kannst du natürlich zusätzlich noch das Script ausführen um die Datenbanken als SQL zu exportieren.

Link to post
3 minutes ago, mgutt said:

Aus dem Grund empfehle ich dir kein Script, sondern das Plugin "Appdata Backup". Der Entwickler hat diesen Punkt bereits berücksichtigt.

 

Analog dazu kannst du natürlich zusätzlich noch das Script ausführen um die Datenbanken als SQL zu exportieren.

Danke für diese Ausführliche Nachricht.

Ich werde dann also erstmal keine Autorisiereung dieses Skriptes machen, statdessen versuche ich ein backup täglich per hand zum machen (vorrübergehende lösung).

Dann überlege ich mir, ob ich das Plugin installiere :)

Link to post
1 hour ago, Easy Tec said:

# mysqld --tc-heuristic-recover rollback
2021-05-06 16:42:52 0 [Note] mysqld (mysqld 10.4.18-MariaDB-1:10.4.18+maria~bionic-log) starting as process 20441 ...
2021-05-06 16:42:52 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:42:56 0 [Note] Please restart mysqld without --tc-heuristic-recover
2021-05-06 16:42:56 0 [ERROR] Can't init tc log
2021-05-06 16:42:56 0 [ERROR] Aborting

 

Dazu nur mal kurz gefragt. Obwohl es mit einem ERROR endete, hat es trotzdem geholfen?

Link to post

Anscheinend ja... Ich muss gleich nur noch ein backup machen, dann das Update auf die neuste version von MariaDB und dann kann ich nochmal schreiben, ob es geht

Link to post

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.