NEWS
[gelöst] BackitUp - SQL Sicherung schlägt seit Längerem fehl
-
@metaxa
Das hast Du auch mal probiert?
@codierknecht Ja gelesen, aber dieses File gibt es bei mir nicht:

-
@metaxa sagte in BackitUp - SQL Sicherung schlägt seit Längerem fehl:
"sudo apt install mariadb-client" ist und war installiert.
Und bist Du gaaanz sicher, dass wirklich der
mariadb-clientinstalliert ist, und nicht dermysql-client? Beide installieren ja mysqldump, aber in unterschiedlichen Ausprägungen. -
@metaxa sagte in BackitUp - SQL Sicherung schlägt seit Längerem fehl:
"sudo apt install mariadb-client" ist und war installiert.
Und bist Du gaaanz sicher, dass wirklich der
mariadb-clientinstalliert ist, und nicht dermysql-client? Beide installieren ja mysqldump, aber in unterschiedlichen Ausprägungen.@marc-berg Ja.

-
@marc-berg Ja.

@metaxa sagte in BackitUp - SQL Sicherung schlägt seit Längerem fehl:
Ja.
Dann würde mir nur noch einfallen, dass es eine alte Verson ist, die die Option "column-statistics" nicht kennt.
mysqldump --versionsagt was?
-
@marc-berg Ja.

-
Und nochwas, dein Bild:

Zeigt aus meiner Sicht, dass es eine mysqldump in
/bingibt, du rufst aber die in/usr/binauf. Zwei Versionen?Edit: wohl doch eher ein Link.
@marc-berg sagte in BackitUp - SQL Sicherung schlägt seit Längerem fehl:
sagt was?
andreas@iOProduktiv:~$ mysqldump --version mysqldump Ver 10.19 Distrib 10.11.6-MariaDB, for debian-linux-gnu (x86_64)@marc-berg sagte in BackitUp - SQL Sicherung schlägt seit Längerem fehl:
Edit: wohl doch eher ein Link.
Yep
-
@marc-berg sagte in BackitUp - SQL Sicherung schlägt seit Längerem fehl:
sagt was?
andreas@iOProduktiv:~$ mysqldump --version mysqldump Ver 10.19 Distrib 10.11.6-MariaDB, for debian-linux-gnu (x86_64)@marc-berg sagte in BackitUp - SQL Sicherung schlägt seit Längerem fehl:
Edit: wohl doch eher ein Link.
Yep

MariaDB 5 ist jetzt auch schon mindestens vier Jahre alt. Vielleicht gibt es Inkompatibilitäten mit dem Client. Ist aber jetzt reines Raten.
EDIT: das würde erklären, dass es "irgendwann" nicht mehr funktionierte. Mit einem Updates des Clients.
-

MariaDB 5 ist jetzt auch schon mindestens vier Jahre alt. Vielleicht gibt es Inkompatibilitäten mit dem Client. Ist aber jetzt reines Raten.
EDIT: das würde erklären, dass es "irgendwann" nicht mehr funktionierte. Mit einem Updates des Clients.
@marc-berg Ich fürchte, du liegst richtig. Habe gerade angefangen von 5 auf 10 upzugraden.
Mal schauen wie weit ich komme

-
@marc-berg Ich fürchte, du liegst richtig. Habe gerade angefangen von 5 auf 10 upzugraden.
Mal schauen wie weit ich komme

@metaxa sagte in BackitUp - SQL Sicherung schlägt seit Längerem fehl:
Habe gerade angefangen von 5 auf 10 upzugraden.
Große Sprünge tun meist besonders weh. Viel Erfolg!
-
@marc-berg Ich fürchte, du liegst richtig. Habe gerade angefangen von 5 auf 10 upzugraden.
Mal schauen wie weit ich komme

Dann schau dir den Rest vom System auch an. Vermutlich ist das ähnlich alt und daher ein guter Kandidat für weiteren Ärger aus der Ecke 'versumpftes System'...
-
Dann schau dir den Rest vom System auch an. Vermutlich ist das ähnlich alt und daher ein guter Kandidat für weiteren Ärger aus der Ecke 'versumpftes System'...
@thomas-braun sagte in BackitUp - SQL Sicherung schlägt seit Längerem fehl:
Dann schau dir den Rest vom System auch an. Vermutlich ist das ähnlich alt und daher ein guter Kandidat für weiteren Ärger aus der Ecke 'versumpftes System'...
Naja, Maria ist ein anderes System, nämlich eine Syno
-
Dann schau dir den Rest vom System auch an. Vermutlich ist das ähnlich alt und daher ein guter Kandidat für weiteren Ärger aus der Ecke 'versumpftes System'...
@thomas-braun sagte in BackitUp - SQL Sicherung schlägt seit Längerem fehl:
aus der Ecke 'versumpftes System'...
Melde gehorsamst:
- iO auf einer Debian12 VM, topaktuell und gepflegt
- Syno kratzt am EOL
@homoran sagte in BackitUp - SQL Sicherung schlägt seit Längerem fehl:
Naja, Maria ist ein anderes System, nämlich eine Syno
Danke!

-
@thomas-braun sagte in BackitUp - SQL Sicherung schlägt seit Längerem fehl:
aus der Ecke 'versumpftes System'...
Melde gehorsamst:
- iO auf einer Debian12 VM, topaktuell und gepflegt
- Syno kratzt am EOL
@homoran sagte in BackitUp - SQL Sicherung schlägt seit Längerem fehl:
Naja, Maria ist ein anderes System, nämlich eine Syno
Danke!

Hatte nicht gesehen, das die DB auf einem anderen System als der DB-Client läuft.
Aber man siehr hier auch wieder gut, warum es keine gute Idee ist die Code-Basis auseinander driften zu lassen. Das eine Paket verlangt nach einem anderen Paket in einer bestimmten Mindest-Version.
-
Hatte nicht gesehen, das die DB auf einem anderen System als der DB-Client läuft.
Aber man siehr hier auch wieder gut, warum es keine gute Idee ist die Code-Basis auseinander driften zu lassen. Das eine Paket verlangt nach einem anderen Paket in einer bestimmten Mindest-Version.
@Marc-Berg neues Problem:

Hat jemand eine Idee?
-
@Marc-Berg neues Problem:

Hat jemand eine Idee?
@ all
Da sind noch mehrere Probleme, beginnend damit, dass eine Tabelle viel zu groß zum exportiern und damit auch viel zu groß (>2GB) um sie in MaraDB10 zu importieren.Jetzt bin ich grad dabei herauszufinden wie ich uralte DS lösche und danach hoffentlich die DB schrumpfen kann.
-
@Marc-Berg neues Problem:

Hat jemand eine Idee?
@metaxa sagte in BackitUp - SQL Sicherung schlägt seit Längerem fehl:
Hat jemand eine Idee?
Du musst Netzwerkverbindungen von außen zulassen.
https://mariadb.com/kb/en/configuring-mariadb-for-remote-client-access/
-
@ all
Da sind noch mehrere Probleme, beginnend damit, dass eine Tabelle viel zu groß zum exportiern und damit auch viel zu groß (>2GB) um sie in MaraDB10 zu importieren.Jetzt bin ich grad dabei herauszufinden wie ich uralte DS lösche und danach hoffentlich die DB schrumpfen kann.
@ all
Jetzt nach etlichen Tagen und viel, sehr viel, sehr sehr viel, Geduld kann ich den Erfolg sehen.
Lösung, wie auch von @Thomas-Braun vorgeschlagen, Umstellung auf Maria DB10.
Was brauchts:
Geduld
Geduld
Geduld
sämtliche Versuche über die Oberfläche von "phpMyAdmin" auf meiner Syno ließen mich scheitern, da hier immer eine max. DB Größe von 1.024MiB importiert werden kann. Die Stückelung in Blöcke (Anzahl DS) scheiterte mehrfach, bis hin zu Verlust von hinterlegten Primaryschlüsseln, also unbrauchbar. Auch das Zusammenführen einzelner Tabellen ist absolut fehleranfällig.phpMyAdmin für WIN war nach Tagen meine Lösung
- 20 Std. Export der größten Tabelle
- 16 Std. Import aller Tabellen
Danach der Reihe nach sämtliche SQL Einstellungen von SQL.0 auf SQL.1 umstellen, auch das dauert Stunden bei einer größeren Anzahl an DP. Wobei hierbei kann man auch gleich wunderbar Korrekturen der Häufigkeit von Archivierungsdaten vornehmen. Danach sämtliche Graphen umstellen, also alles was auf SQL.0 verweist.
Mein Backup funktionert wieder!

Hey! Du scheinst an dieser Unterhaltung interessiert zu sein, hast aber noch kein Konto.
Hast du es satt, bei jedem Besuch durch die gleichen Beiträge zu scrollen? Wenn du dich für ein Konto anmeldest, kommst du immer genau dorthin zurück, wo du zuvor warst, und kannst dich über neue Antworten benachrichtigen lassen (entweder per E-Mail oder Push-Benachrichtigung). Du kannst auch Lesezeichen speichern und Beiträge positiv bewerten, um anderen Community-Mitgliedern deine Wertschätzung zu zeigen.
Mit deinem Input könnte dieser Beitrag noch besser werden 💗
Registrieren Anmelden