Kein Zugriff mehr auf MariaDB 10

Hinweis: Nach dem 31.12.2025 ist eine Registrierung nicht mehr möglich, nutze die verbleibenden Tage!

    Nach einem Firmwareupdate kann ich mich nicht mehr mit MariaDB 10 verbinden.

    Die GUI sagt:

    Code
    "Fehler beim Laden von Daten!"

    Laut ps -aefl |grep mysql, laufen aber diverse mysqld-Prozesse. Wenn ich mir das anschaue, dann finde ich aber einige Ungereimtheiten:
    - bei einem Prozess steht explizit --port=3310... ich hatte mysql immer auf 3306 laufen...?!?

    - es gibt verschiedene Angaben für --datadir... keine davon zeigt auf das Verzeichnis, wo meine mysql-Daten liegen...?!?


    Wie bekomme ich mysql wieder zum Laufen?
    Vielen Dank.

    Hallo,


    mal 1-x Neustarts des NAS versuchen. :/

    Hinweis:

    Zitat von volvo

    Nach einem Firmwareupdate .....

    ist keine gute Info. Wichtig immer NAS, QTS-Version, APP-Version.

    Neustart habe ich heute schon diverse Male vergebens probiert.
    NAS: TS977XU-RP
    Firmware: QTS 5.2.6.3195
    MariaDB 10: 1.2.1.31

    Da wäre jetzt ein Kenner der MariaDB gefragt. Evtl. lhsei :/ Sonst könntest Du ein Downgrad auf QTS 5.2.5.xx versuchen. :/ Backups sind hoffentlich vorhanden.

    Guten Morgen,


    ja, das gesamte DB-Datenverzeichnis ist kopiert...
    Die Frage, die sich mir stellt:
    - warum habe ich 2 mysqld-Prozesse? qcoolie und mariadb

    - warum mariadb jetzt auf Port 3310? und mit anderem --datadir...?

    Hallo,


    dann wollen wir doch mal schauen, ob wir es wieder zum Laufen bekommen.

    1. Gibt es einen aktuellen Datenbankdump als Backup? Ein kopiertes Datenverzeichnis ist leider KEIN Backup - es hilft nur ein richtiger Dump per mysqldump, wobei immer die mysql-Datenbank und dann die eigentliche Datenbank benötigt wird.

    2. Wurde das Datenverzeichnis der MariaDB10 verschoben, oder das originale Verzeichnis genutzt?

    3. Was passiert, wenn die MariaDB10 manuell beendet und gestartet wird mit diesen Befehlen? Welche Bildschirmausgaben kommen?

    Code
    cd /share/CACHEDEV1_DATA/.qpkg/MariaDB10/etc/init.d
./mariadb10.sh stop
./mariadb10.sh start

    Was Du nach dem Beenden und VOR dem erneuten Start der MariaDB10 versuchen kannst, ist dieser Befehl:

    Code
    /share/CACHEDEV1_DATA/.qpkg/MariaDB10/bin/mysqld --tc-heuristic-recover=ROLLBACK --basedir /share/CACHEDEV1_DATA/.qpkg/MariaDB10/ --datadir /share/CACHEDEV1_DATA/.mariadb10/data --user=root

    Einmal editiert, zuletzt von lhsei ()

    Danke 1

    Hallo,

    nein, ein Dump liegt leider nicht vor - die ganze Aktion war nicht geplant... - ich habe tatsächlich nur das Verzeichnis kopiert. ./mariadb10.sh start liefert:

    Code
    [/share/CACHEDEV1_DATA/.qpkg/MariaDB10/etc/init.d] # ./mariadb10.sh start
Starting MariaDB10 services:
tmpdir = /share/CACHEDEV1_DATA/.mariadb10/tmp
Starting mariadb-sever services:
MariaDB10 db is not alive.

    Also nochmal gestoppt und den weiteren Befehl probiert. Ausgabe sieht wie folgt aus:

    Super! Die Reparatur hat geklappt - es wurde eine unvollständige Transaktion rückgängig gemacht (Rollback).

    Nun einfach die MariaDB normal starten und es sollte wieder alles laufen.

    Das Problem mit den unvollständigen Transaktionen tritt auf, wenn das NAS bei der Verarbeitung von SQL-Befehlen abstürzt/stromlos wird, oder aber die Transaktion so umfangreich ist, dass sie beim Herunterfahren/Neustart in den KILL-Befehl läuft.

    Und ich kann Dir nur ans Herz legen, regelmäßg mittels Cronjob einen Datenbankdump Deiner Datenbank und der MYSQL-Datenbank anzulegen und diesen extern wegzusichern. Dann bist Du auf der sicheren Seite.

    Hm, das ist einfacher als gesagt - die DB startet nicht…😳

    Mir war ehrlich gesagt nicht bewusst, dass das Kopieren des Datenverzeichnisses nicht ausreicht. Da das ja auch mit —datadir explizit angegeben wird…

    Ok, wieder etwas gelernt

    Was wird bei folgendem Befehl angezeigt:

    /share/CACHEDEV1_DATA/.qpkg/MariaDB10/bin/mysqld --basedir /share/CACHEDEV1_DATA/.qpkg/MariaDB10/ --datadir /share/CACHEDEV1_DATA/.mariadb10/data --user=root

    Anbei der Output:

    Die Replikation gibt's nicht mehr, insofern wäre das kein Problem.

    Ich kann wieder auf die DB zugreifen! VIELEN DANK!!! Jetzt bleibt nur die Frage, ob das auch nach einem Reboot gewährleistet ist?!? Allerdings bin ich gerade auf Dienstreise und werde das erst testen, wenn ich wieder zu Hause bin.

    Hallo,


    das freut mich, dass die Datenbank wieder läuft! Die Änderung ist rebootsicher, da der zugrundeliegende Fehler (unvollständige Transaktionen) in der Datenbank behoben wurden.


    Wichtig wäre aber wirklich, dass Du VOR dem Neustart einen Datenbankdump per mysqldump schreiben lässt. Und zwar wie beschrieben nicht nur von der eigentlichen Datenbank, sondern auch von der Systemdaten mysql. Die Befehlsstruktur dazu lautet:


    Code
    /share/CACHEDEV1_DATA/.qpkg/MariaDB10/bin/mysqldump -h localhost -u root -pPASSWORT DATENBANK > /share/Public/DATENBANK.sql

    Erläuterung:

    PASSWORT ist das root-Passwort der MariaDB

    DATENBANK ist der Name der zu sichernden Datenbank. Bitte unbedingt auch die Datenbank mysql mit sichern!

    Den Speicherpfad kannst Du natürlich selbst festlegen, ich habe ihn jetzt mal exemplarisch in das überall vorhandene Public-Share gelegt.

    Mit diesem Befehl wird ein bereits vorhandener Dump überschrieben - also unbedingt die Dump-Dateien regelmäßig extern wegsichern!


    Ich empfehle immer, den Dump per Cronjob durchführen zu lassen, wie das geht, hatte ich vor längerer Zeit in diesem Beitrag beschrieben:

    Thema
    mysqldump per Cronjob bringt Fehler
    Hallo,
    ich versuche gerade nach der Anleitung https://www.synology-wiki.de/i…k_%C3%BCber_einen_cronjob einen Cronjob einzurichten. Bei mir ist QMariadB installiert: Versuche ich manuell einen dump zu erzeugen kommt folgende Fehlermeldung. Damit kann ich gar nichts anfangen:
    (Quelltext, 4 Zeilen)

    Passwort ist richtig damit komme ich in die Mysql Datenbank. Kann es sein, dass es was mit der 2 Faktor Authentifizierung zu tun hat?
    2. Frage: Kann ich qmariadb.err ohne Gefahr löschen. Diese ist…
    Milchmann


    Viele Grüße!