hawihoney

OMG, I need to move to your country. Triple that for Germany.

Ich meine das ganz normale Unraid Array. In den oben gezeigten drei Gehäusen läuft ein Unraid Server mit zwei Unraid VMs, insgesamt drei Unraid Arrays. Ein LSI 9300-8i HBA, drei mit Expander bestückte Supermicro BPN-SAS2-EL1 Backplanes. Benötigt werden insgesamt drei Unraid Lizenzen und drei USB-Sticks. Die Platten sind derzeit individuell an die VMs durchgereicht. Für normale Dateioperationen ist das ok. Parity Check/Rebuld ist allerdings ca. 25% langsamer als mit durchgereichten HBAs pro VM. Dafür würde man dann aber auch zwei weitere Steckplätze fur HBAs benötigen. Auf dem Host erzeugt das Durchreichen individueller Festplatten hohe IOWAiTs durch die QEMU Emulationsschicht bei Parity Check/Rebuild. Ich kann damit leben. Bei solchen Systemen gilt es die Vorteile/Nachteile abzuwägen. Die bewertet jeder anders. Shares löse ich array-übergreifend mit eigenen Mount/Unmount Skripten im User Scripts plugin. Diese Installtion läuft seit 2019 mehr oder weniger fehlerfrei.

Nur zum Verständnis: Du hast ein Gehäuse (oder mehrere) in denen mehr als 30 (28+2) Festplatten angesteuert werden könnten? Also zum Beispiel 2x 30 Festplatten (2x 28+2)? Dazu gibt es tatsächlich eine Lösung die bei mir seit Jahren hervorragend funktioniert. Unraid läuft problemlos in einer VM die wiederum auf Unraid läuft. Die Vorteile: Du könntest mehrere (jeweils bis zu 28+2) Arrays in einem Server betreiben. Du nutzt die in meinen Augen absolut stabile Unraid Array Technik und keine noch (wiederum meiner Meinung nach) experimentellen BTRFS Features. Wenn alles glatt läuft kannst Du diese zusätzlichen Unraid Arrays aus den VMs weiternutzen sobald multiple Arrays in Unraid implementiert wurden. Die Festplatten können individuell "passed-through" werden oder, was performance-technik besser ist, an zusätzlichen HBAs durchgereicht werden. Beides habe ich in den vergangenen Jahren schon produktiv genutzt. Die Nachteile (wenn man in diesen Dimensionen überhaupt von Nachteil spricht): Du benötigst pro Unraid Array in einer VM eine weitere Unraid Lizenz sowie einen weiteren USB-Stick. Die Einrichtung ist relativ simpel. Das Ganze geht natürlich nicht nur in einem Gehäuse sondern auch über mehrere Gehäuse hinweg. Im Bild ist ein einzelner Unraid Server zu sehen:

--> Array --> Pool Kenne mich damit nicht aus. Würde einen zweiten Pool verwenden. Da Du aber nur zwei NVMe's besitzt würden beide Pools nur jeweils aus einem Device bestehen. Die wären dann aber ungesichert. Wenn beides hingegen auf einem Pool läuft könnten sie sich gegenseitig behindern.

After looking at Github and the Main page again I see what's the problem: In english the header is called Reads/Writes for both displays (Toogle reads/writes display). So it seems there is only one translation possible for both displays. @ich777 Please forget my change request I wrote here. Sorry about that.

Ich habe gerade im deutschen Forum einen Screenshot der Main Page in Deutsch gesehen. Auf dem Screenshot war die Einstellung der Schreibrate zu sehen. Also 0 B/s und nicht die Summe der Lese-/Schreibaktivitäten. Die Header hierzu lauten "Gelesen" bzw. "Geschrieben" was meines Erachtens nicht korrekt ist. Gelesen/Geschrieben passt zur anderen Darstellung mit den Summen, aber nicht zur aktuellen Schreib-/Leseaktivität. Meiner Meinung nach müssten die Header z.B. "Leserate" bzw. "Schreibrate" lauten, oder? Alternativ "Lesen" und "Schreiben".

Ich mochte die nicht alle als jeweilige Root-Ordner/-Shares neben meinen eigenen. Einen - system - kann ich akzeptieren. Im Übrigen gibt es alte Videos in denen das von anderen ebenfalls so abgewandelt genutzt wird - die haben mich inspiriert.

Meinem eigenen Verständnis nach ist nicht alles appdata - deswegen habe ich das bei mir leicht abgeändert. Apps bekomme ich über den tab Apps system/appdata/nextcloud/config ist der config Ordner von Nextcloud, das ist klar appdata system/appdata/nextcloud/data ist der data Ordner von Nextcloud, das ist klar appdata system/docker/docker.img bzw. system/docker/ ist m.V.n. nicht appdata system/VM/libvirt.img ist m.V.n. ebenfalls kein appdata system/domains/VM01/VM01.img - über das habe ich mit mir selbst gerungen. Könnte auch unter system/VM. Treu nach dem Motto: Think big. Evtl splitte ich das alles später mal auf mehrere Pools. Meine Struktur gibt das auf jeden Fall her.

Bei zwei Datenbanken solltest Du das aber ausführen ohne zwei mal den Container zu stoppen. In einem meiner Posts findest Du dazu etwas mit dbname #1, etc.

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.

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

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.

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.

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.

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

... 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

2.) ist für später, kurz bevor Du beschlossen hast alles neu aufzusetzen 3.) ist für später, nachdem Du alles wieder am Laufen hast - wie auch immer.

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

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?

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

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.

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.

Thanks a lot. IMHO the question is, what activitiy is a host responsible for on passed through disks: #1 check SMART: yes (VM can't check SMART for passed through disks, don't know how or if this works currently) #2 spinup/spindown: yes (VM can't spinup/spindown passed through disks, currently it works perfect, no change required) #3 show "Format" text: no (host does not catch the finish until host reboot - host reboot is not done if VM formats/rebuilds a passed through disk) #4 show Partitions: no (host does not catch new partitions until host reboot - host reboot is not done if VM creates/deletes partitions on a passed through disk) So in my opinion the checkbox "passed through" within UD disk settings becomes the driver for #1 to #4 mentioned above on passed through disks. Perhaps you need to talk to Limetech about their vision. Thanks again.

Da wäre ich mir nicht so sicher. Im Grunde genommen ist das Parity-Protected Array eine Ausfallsicherheit von Vielen. Stell Dir einfach vor, in einem der kommenden Unraid Versionen stünde in der Dropdownliste beim Pool neben RAID-0, RAID-5 zusätzlich P-Array oder PQ-Array ...