Nach dem Update auf 31.0.0 beta 1 erscheint die Meldung „Falsches Zeilenformat in Ihrer Datenbank gefunden. ROW_FORMAT=Dynamic bietet die beste Datenbankleistung für Nextcloud. Bitte aktualisieren Sie das Zeilenformat in der folgenden Liste: DGdhx_accounts, … [es folgt eine lange Liste].
Der Link zur Doku leitet zwar zum passenden Thema – aber ich verstehe nur Bahnhof und weiß nicht, was ich tun soll (mal abgesehen davon, dass das auf Englisch zu schwierig ist).
Ich hatte dieses Problem auf einer älteren Testinstanz und habe ein kleines Skript erstellt, das automatisch das ROW_FORMAT in allen Tabellen der Nextcloud Datenbank auf DYNAMIC ändert.
Ob du allerdings das Skript oder die mysql Befehle im Skript direkt auf der CLI deines Webhostings ausführen kannst weiss ich nicht, da müsstest du allenfalls die Doku deines Hosters konsultieren oder eine Supportanfrage stellen.
WARNUNG:
Ich bin kein Datenbank/Mysql/MariaDB-Experte und dieses Skript wurde mit der Hilfe von KI erstellt. Also unbedingt ein Backup der Datenbank erstellen bevor du das Skript ausführst!
#!/bin/bash
# Prompt for database credentials
read -p "Enter Database Name: " DB_NAME
read -p "Enter Username: " DB_USER
read -s -p "Enter Password: " DB_PASS
echo
# Generate ALTER TABLE statements and execute them
mysql -u "$DB_USER" -p"$DB_PASS" -e "
SELECT CONCAT('ALTER TABLE \`', TABLE_NAME, '\` ROW_FORMAT=DYNAMIC;')
FROM INFORMATION_SCHEMA.TABLES
WHERE TABLE_SCHEMA = '$DB_NAME'
AND ENGINE = 'InnoDB';
" -B -N | while read -r sql; do
mysql -u "$DB_USER" -p"$DB_PASS" -e "$sql" "$DB_NAME"
done
du fährst eine Beta-Version. Dann hoffe ich zweierlei @Mogeywuca
es handelt sich um eine Testinstanz und um keine produktive Instanz
du hast ein Backup, das du wieder einspielen kannst, um auf NC30.x zu wechseln.
Warum? Weil Beta-Version von NC wirkliche Beta-versionen sind, die noch gehörig getestet werden müssen. Und wenn Probleme auftreten, solltest du einigermaßen wissen, wie du sie beheben kannst.
Ich denke in diesem Fall wird das “Problem” aber nicht weggehen, auch wenn 31 irgendwann Final ist. Habe den Code nicht durchsucht, aber ich vermute stark, dass es sich hierbei um einen neuen Check handelt, der mit Nextcloud 31 eingeführt wird, und wenn die Datenbank mit COMPRESSED oder irgend einem aderen Zeileformat als DYNAMIC erstellt wurde, wird man wohl diese Meldung erhalten.
Das mag hier etwas offtopic sein, aber die Nextcloud Devs sollten wirklich endlich eine Möglichkeit einführen, solche Meldungen zu “bestätigen” und dann in irgendeinem Untermenü verschwinden zu lassen. Vor allem wenn es sich wie hier nur um Warnungen oder Empfehlungen handelt, so dass das Dashboard nicht mit riesigen Meldungen zugemüllt wird, falls man sich entscheiden sollte bestimmten Empfehlungen nicht zu folgen. /Rant Ende!
Ist immer so ein bisschen die Frage ;-). So ein Check hat ja durchaus einen Sinn. Andererseits ist auch ein wenig die Frage, wie sehr man sich von solchen Meldungen verrückt machen lässt, wenn man weiß, was Sache ist und warum es ggf. zu einer Meldung kommt.
In der Tat ist es ein neuer Check, der das Rowformat überprüft. Die Empfehlung ist “Dynamic” für die beste Leistung (wie die Meldung ja sagt). Wenn ich mich recht erinnere, hat das “falsche” Format insbesondere Auswirkungen bei sehr großen Instanzen, aber es ist halt die allgemeine Empfehlung die nun in Form eines Checks eingeführt wurde.
Vielleicht sollte noch ergänzt werden, dass man es im ‘raw’ ausgabeformat benötigt.
Für alle Debian/Ubuntu Nutzer, die wenig Datenbank-Konsole Erfahrung haben:
Mit → dem nc-sql Skript ← bekommt man ganz einfach eine raw-Shell als den Datenbankbenutzer deiner Nextcloud-Instanz mit:
nc-sql --raw
dort dann einfach den Code von @Dirk_Klaus hinein pasten.
Die Ausgabe kann dann einfach wieder mit copy&paste übernommen werden und in der gleichen (oder einer weiteren, NICHT-raw Konsole) weiter benutzt werden.
Ja versteh’ mich bitte nicht falsch, ich finde diese Checks sehr nützlich, und befolge die Anweisungen in der Regel auch. Aber es wäre halt schön, wenn man in bestimmten Situationen die Meldungen verstecken/ausblenden könnte. Das wäre vorallem auch beim Log Counter sinnvoll, denn so wie er monentan funktioniert (Anzahl Meldungen der letzten sieben Tage), ist er nur bedingt nützlich, denn man sieht so nicht auf den ersten Blick, ob allenfalls neue Fehler im Log hinzugekommen sind, seit man das letzte mal gekuckt hat.
Mein Skript mach alles in einem Rutsch weil es die ALTER TABLE-Anweisungen in eine while Schleife übergibt, die dann für jede Anweisung die entsprechenden mysql-Befehle direkt aus der Shell ausführt.
Ist aber vielleicht generell eh besser/stabiler, wenn man es direkt in Datenbank-Konsole macht, und auf einer Shared Web Hosting Platform, wie sie @Mogeywuca verwendet, evtl. auch die einzige Möglichkeit. Ausser villeicht noch https://www.phpmyadmin.net/, was viele Webhoster anbieten, aber k.A. ob man da Skripts nutzen kann, oder ob man jede Tabelle, einzeln von Hand ändern muss.
Ich halte es für falsch die Warnungen als “unwichtig” abzutun - gerade für unerfahrene Admins der SOHO Installationen sind sie eine wichtige Hilfe. Die Checks und Warnings haben absolut Sinn und es ist gut dass immer mehr Checks eingebaut werden um das System automatisch auf Probleme zu prüfen… Auch ich mit zig Jahren IT Erfahrung wüsste nicht was der Unterschied von RAW zu DYNAMIC ist und was besser performt… und wäre erst Recht nicht auf die Idee gekommen das selbst zu kontrollieren ausser es gäbe ein Problem…
Das Problem ist die Darstellung - “nice to have” wird wild mit funktionalen und Sicherheitsrelevanten Themen vermischt… und manchmal etwas “roh” ins Produkt eingebaut so wie die reihenweise fehlerhaften Checks im NC29 (?).
Hast du eine Idee ob/wie/wo man das Thema generell diskutieren kann und ggf in die richtige Richtung lenken?
War nicht gerade ideal formuliert von mir, stimmt schon. Aber das bloße „es muss nen grüner Haken da sein“ ist manchmal halt nicht hilfreich.
Im einfachsten Fall mal nen github issue machen mit nem Vorschlag wie es aussehen kann. Würde das hier sonst mal weiterleiten, aber deutsch ist nicht ganz ideal.
An dieser Sache gibt es mehreres was mir absolut nicht gefällt:
Es wird hier einfach so, bei einer Sache wo man durchaus geteilter Meinung sein kann:
(Compression=less space vs. Dynamic=less cpu) EINE Lösung als den einzig richtigen dargestellt.
Es kommt vielmehr darauf an um WELCHE Tabelle es sich genau handelt und was, bzw. welche Ressource dem Admin am wichtigsten ist.
Ich wüsste da noch eine ganze Menge an überprüfbaren Sachen, käme aber nicht auf die Idee, diese in SetupChecks wie diesen unter zu bringen!
Beim Pull Request ist eine sehr gute Idee “gebrainstormed” worden:
Good idea @kesselb, gut das wir drüber gesprochen haben!
Ist auch tatsächlich etwas aus der idee geworden?
Warum ist nicht zuerst ein (z.B.)
./occ db:alter_row_format
geschrieben worden, wie für solche Datenbankanpassungen bisher eigentlich schon fast üblich? Jetzt wird der Benutzer mit einer Meldung alleine gelassen, ohne dass er einen von den devs entwickelten OCC Befehl ausführen kann um es zu beheben. Die Folge - und wir mods können ein Lied davon singen - alle werden hier im Forum kommen und fragen, weil sie ein grünes Häckchen wollen, gerne auch jeder mit seinen eigenen Thread.
Die Anpassung des Row Formats ist ein relativ einfacher Task und gerade WEIL es so einfach ist: wieso hat denn nicht jemand den PR davon abhängig gemacht, dass dieser occ-Task dazu angeboten wird?
EDIT:
Ich sehe jetzt, beim näher hinsehen, dass
occ db:convert-mysql-charset
genau diesen task auch ausführt!
Wenn ich den Code lese, scheint das auch so zu sein!
Dann aber sollte das in der Doku mit aufgenommen bzw. präzisiert werden und DAS sollte verlinkt werden beim Setup Check und NICHT den Link zur MySQL Dokumentation.
EDIT2:
Auch wenn es diese Zeile gibt:
führt er es nicht aus, wenn die collation bereits in Ordnung ist:
# occ db:convert-mysql-charset
All tables already have the correct collation -> nothing to do
Und bei der Instanz sind ettliche Tabellen mit row-Format COMPRESSED
