Easy Tec Posted May 6, 2021 Author Share Posted May 6, 2021 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' Quote Link to comment
hawihoney Posted May 6, 2021 Share Posted May 6, 2021 (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 May 6, 2021 by hawihoney 1 Quote Link to comment
Easy Tec Posted May 6, 2021 Author Share Posted May 6, 2021 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 Quote Link to comment
Easy Tec Posted May 6, 2021 Author Share Posted May 6, 2021 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 Quote Link to comment
hawihoney Posted May 6, 2021 Share Posted May 6, 2021 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. Quote Link to comment
Easy Tec Posted May 6, 2021 Author Share Posted May 6, 2021 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 Quote Link to comment
hawihoney Posted May 6, 2021 Share Posted May 6, 2021 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. Quote Link to comment
Easy Tec Posted May 6, 2021 Author Share Posted May 6, 2021 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. Quote Link to comment
Easy Tec Posted May 6, 2021 Author Share Posted May 6, 2021 3 minutes ago, hawihoney said: Die Warnung vor dem Alpine Build ist aber auch bei mir in den Logs Die kommen bei mir auch noch und müllen das Log zu... Quote Link to comment
hawihoney Posted May 6, 2021 Share Posted May 6, 2021 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. Quote Link to comment
Easy Tec Posted May 6, 2021 Author Share Posted May 6, 2021 #!/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 Quote Link to comment
Easy Tec Posted May 6, 2021 Author Share Posted May 6, 2021 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 ) Quote Link to comment
Easy Tec Posted May 6, 2021 Author Share Posted May 6, 2021 (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 May 6, 2021 by Easy Tec Quote Link to comment
hawihoney Posted May 6, 2021 Share Posted May 6, 2021 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. Quote Link to comment
mgutt Posted May 6, 2021 Share Posted May 6, 2021 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. Quote Link to comment
Easy Tec Posted May 6, 2021 Author Share Posted May 6, 2021 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.. Quote Link to comment
Easy Tec Posted May 6, 2021 Author Share Posted May 6, 2021 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 6 minutes ago, mgutt said: Mach erst das Backup von allen Datenbanken als SQL Datei. Also mit dem Skript von @hawihoney? Quote Link to comment
Easy Tec Posted May 6, 2021 Author Share Posted May 6, 2021 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? Quote Link to comment
hawihoney Posted May 6, 2021 Share Posted May 6, 2021 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. Quote Link to comment
Easy Tec Posted May 6, 2021 Author Share Posted May 6, 2021 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 Quote Link to comment
Easy Tec Posted May 6, 2021 Author Share Posted May 6, 2021 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 Quote Link to comment
mgutt Posted May 6, 2021 Share Posted May 6, 2021 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. Quote Link to comment
Easy Tec Posted May 6, 2021 Author Share Posted May 6, 2021 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 Quote Link to comment
mgutt Posted May 6, 2021 Share Posted May 6, 2021 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? Quote Link to comment
Easy Tec Posted May 6, 2021 Author Share Posted May 6, 2021 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 Quote Link to comment
Recommended Posts
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.