Hallo,
bei mir hat das Update des ROW_FORMAT größtenteils gut geklappt.
Einzig die Tabelle oc_filecache lässt sich nicht umstellen.
Bekomme dabei immer eine Fehlermeldung.
MariaDB Logs:
Hat hier jemand eine Idee dazu?
Hallo,
bei mir hat das Update des ROW_FORMAT größtenteils gut geklappt.
Einzig die Tabelle oc_filecache lässt sich nicht umstellen.
Bekomme dabei immer eine Fehlermeldung.
MariaDB Logs:
Hat hier jemand eine Idee dazu?
Kann es sein, dass der freie Speicherplatz auf deinem System knapp ist, genauer gesagt der freie Speicherplatz auf der Disk, auf der sich das temporäre Verzeichnis befindet, das MySQL oder MariaDB verwendet?
Ich habe die Fehlermeldung gegoogelt und was ich gefunden habe, deutet eigentlich alles in diese Richtung.
Zum Beispiel hier: alter - ERROR 1878 (HY000): Temporary file write failure in mysql - Stack Overflow
…oder hier: MYSQL ERROR 1878 (HY000): Temporary file write failure. - Webmaster2020.com
Vielen Dank für den Hinweis!
Das Problem war das ich das Verzeichnis /tmp per Docker extra Parameter auf den RAM verlagert habe und hier das Verzeichnis zu klein war.
–mount type=tmpfs,destination=/tmp,tmpfs-mode=1777,tmpfs-size=256000000
Nachdem ich das entfernt habe ging der Datenbank Befehl ohne Probleme durch.
Hallo Zäma,
ich bin auch in diese Falle gelaufen, obwohl ich bei meinen vielen update immer der stabil Update-Kanal angezeigt wurde.
Ich bin Nextcloud user only und weiß nun wirklich nicht, was ich definitiv machen soll/muss, damit die Meldung:
Falsches Zeilenformat
verschwindet - ich sehe/lese hier gerade zu viele Ideen.
Also was tippe ich nun auf meiner Konsole ein?
Danke für jeden Tipp
Lese gerade in einem anderen Text:
sudo mariadb
Ist das die Lösung?
Wenn deine Nextcloud schon älter ist, wurde sie damals noch mit einem anderen Zeilenformat erstellt, und mittlerweile empfiehlt Nextcloud halt ein anderes. Konnte man damals noch nicht wissen.
Wie ist denn deine Nextcloud installiert?
Wenn es eine “Baremetal” Installation ist, sprich eine manuelle Installation ohne Docker oder Snap, empfehle ich dir mein Bash Script zu verwenden, dann ist der ganze Zauber in wenigen Sekunden erledigt. Ich habe das Skript mittlerweile auf mehreren Instanzen ohne Probleme verwendet.
Zuerst öffnest du auf der Konsole einen Texteditor, z.B. nano, und gibst ihm einen Dateinamen für die Datei, die er erstellen soll…
nano alter_row_format.sh
Dann kopierst du das Skript von hier und fügst es in nano ein.
Danach speichern…
Ctrl + o
…nano verlassen…
Ctrl + x
…und das Skript ausführen:
bash alter_row_format.sh
Die nachfolgenden Prompts sollten selbsterklärend sein.
Falls du deine Notizen gerade nicht zur Hand hast, findest du die entsprechenden Angaben auch in der config.php deiner Nextcloud. Bei mir sehen die entsprechenden Zeilen dort z.B. so aus:
'dbname' => 'ncdb',
'dbuser' => 'ncdbuser',
'dbpassword' => 'sup3r$3r3tpa$$w00rd'
Hoffe das hilft dir weiter.
Danke, das liest sich doch prima. Teste das morgen.
Es ist eine Baremetal Installation. Alles von Hand aufgesetzt – vor langer, langer Zeit.
Nun waren mal wieder upgrade angesagt und ich wollte bis ganz nach oben, damit ich Ruhe habe. Leider zeigte das Upgrade von 30.x.y.z nach 31, die bekannten Fehler.
Vielen Dank und Grüße aus dem Süden
Alles wunderbar - hat geklappt.
Jetzt muss ich nur mal checken, was bei meinem Provider möglich ist; hier habe ich eine InternetCloud (NextCloud). Aber ein Update auf 31 kann warten.
Vielen Dank bb77
Hallo zusammen,
ich habe mit dem folgenden Skript die Namen angepasst:
SELECT CONCAT(‘ALTER TABLE `’, TABLE_NAME, ‘` ROW_FORMAT=DYNAMIC;’)
FROM INFORMATION_SCHEMA.TABLES
WHERE ENGINE = ‘InnoDB’;
Hier da Ergebnis:
ich bekomme trotzdem eine Warnung in der Nextcloud.
Habe ich was vergessen ?
Vielen Dank im voraus ![]()
Achtung: in der dritten Zeile ( read -s -p "Enter Password: " ) ist der Parameter -s zu viel!
Bei mir hatte er dafür gesorgt, dass die Passwortabfrage in einer Endlosschleife hängen blieb und das Script ab dieser Stelle nicht weiter ausgeführt wurde.
Nach dem Löschen von -s lief das Script fehlerfrei durch und anschließend waren die Warnungen in der Nextcloud weg.
Ich hatte keine Probleme deswegen, und gemäss manpage, soll der -s Parameter lediglich verhindern, dass die Eingaben an das Terminal zurückgesendet werden, sprich, dass das Passwort auf dem Bildschirm angezeigt wird.
help read
-s do not echo input coming from a terminal
Ich habe auch noch ein wenig gegoogelt und nicht wirklich etwas spezifisches gefunden, warum -s ein Problem sein sollte. Es könnte aber sein, dass der Parameter nicht mit anderen Shells wie sh, zsh, dash etc. kompatibel ist.
Was da helfen könnte, wäre vor dem Ausführen des Skripts erst in eine Bash shell zu wechseln…
bash
./skript.sh
oder es direk mit bash zu starten:
bash skript.sh
Oder #!/usr/bin/env bash anstatt #!/bin/bash als Shebang zu verwenden.
Oder, wie du es gemacht hast, -s einfach weglassen ![]()
Ich hatte mir tatsächlich nicht die Mühe gemacht, die Bedeutung von -s nachzuschlagen. Da die beiden ersten Zeilen des Scripts diesen Parameter nicht enthielten, war ich davon ausgegangen, dass sich -s hierher “verirrt” hatte.
Meine Nextcloud läuft auf Debian, also mit der Bash. Insofern merkwürdig, dass -s sich als Endlosschleife auswirkte. Ich kam auch mit keiner Tastenkombi mehr da raus und musste den Rechner rebooten…
Aber: Ende gut, alles gut mit ohne -s ![]()
Danke für die sehr coole Hilfestellung!
Vielen Dank für die perfekte Anleitung. Kann bestätigen, dass der Skript auf All-Inkl und MariaDB perfekt durchgelaufen ist, keine Probleme. ![]()
Perfekt, super. Danke fürs Teilen!