mysql/MariaDB läuft nach FW-Update auf 4.3.3 nicht mehr

    Moin Leute,
    nach dem FW Update auf 4.3.3.0154 lief bei meiner HS251 die Datenbank nicht mehr - und damit auch WordPress, Owncloud etc... nicht mehr (Datenbankfehler). Den SQL-Server MariaDBüber die Konfig-Seite zu deaktivieren / aktivieren brachte eine Veränderung.


    Nach Neustart der mysql lief alles wieder:

    Code
    [~] # /etc/init.d/mysqld.sh restartTry to shutting down MySQL ERROR! MySQL manager or server PID file could not be found!170501 00:41:03 mysqld_safe Logging to '/usr/local/mysql/var/N4.err'.170501 00:41:03 mysqld_safe Starting mysqld daemon with databases from /usr/local/mysql/var..... SUCCESS!


    Heute hatte ich unerwartet denselben Effekt - Datenbankfehler. Also sozusagen am helligten Tage, ohne mein bewusstes Zutun.
    Erneut musste ich den mayql Server neu starten. Bislang lief zumindest der mysqld durch ... :cursing:


    MariaDB stoppen / starten: keine Veränderung. Mysqld neustarten - Erfolg.


    Dabei fällt mir auf, dass es offenbar kein PID gab / so verstehe ich jedenfalls die Fehlermeldung.
    Wenn mysql einfach "gestorben" wäre, hätte der Deamon vermutlch nicht hinter sich aufgeräumt und das PID-file gelöscht.
    Oder verstehe den Eintrag "MySQL manager or server PID file could not be found" falsch?



    Weitere Fragen dazu:
    Sollte mysql nicht durch MariaDB (bei mir aktuell 5.5.44.002) ersetzt sein? ?(?(?( Muss überhauprt ein mysqld laufen?
    Oder ist MariaDB eine Erweiterung des Mysql Deamons????


    Jedwede Idee willkommen -


    Mit Gruß aus Gö Ralph

    Hallo,


    ich habe auch das Problem, dass der daemon (mysqld) nicht automatisch gestartet wird.


    Sogar mit einem eigenen Bash-Skript per autostart lässt er sich nicht dazu bewegen,
    auf der Konsole jedoch lässt er sich problemlos starten.


    QMariaDB legt ein pid-file an u. mysqld sollte, wenn er läuft, auch ein pid-file angelegt haben
    ( wenn ich es richtig in Erinnerung habe, NAS ist z.Zt. nicht aktiv ).


    Ein Ticket habe ich bereits erstellt, der QNAP-Techniker gab sich viel Mühe, konnte allerdings
    den Fehler nicht finden. Er wollte nun die Entwicklungabteilung einschalten.


    Wäre nett, wenn du auch eine Meldung an QNAP senden würdest, um der ganzen Sache mehr
    Nachdruck zu verleihen.


    Gruß


    Salegy

    [x] done


    Mag mal Jemand checken welche MariaDB Version bei ihr/ihm läuft?
    Konfigseite - Anwendungen SQL Server - da müsste das stehen.
    Mich wundert, dass bei mir QMariaDB steht (das klingt für mich nach einem Überbleibsel der MariaDB als APP -
    das gabe es mal kurzzeitig ... oder ist das bei euch auch so?
    Mit Gruß aus Gö - Ralph







    Mal sehen, was daraus wird ... und noch ein Gruß von


    Ralph


    Immerhin scheinen wir nicht ganz alleine zu sein:
    siehe engl. Forum. Gruß aus Gö - R

    Einmal editiert, zuletzt von schwerdt ()

    Hi,


    bei mir läuft Server version: 5.5.51-MariaDB - MariaDB Server.
    Die Anzeige unter Anwendungen - SQL war bei mir falsch, wurde beim update auf
    4.3.3.0154 nicht geändert (habe dann die qpkg.conf berichtigt).


    Diese QNAP-Konstruktion ist schon speziell (jedenfalls für mich als Laien):


    QMariaDB - mariadb.pid



    mysqld - qmysql.pid



    Mal schaun, wann sich Taiwan meldet.


    Grüße an alle 4.3.3.0154 - "Geschädigten"

    OK, das ist offenbar auch bei mir so:
    Wenn ich in die Log-Datei beim Starten des mysqld reinschaue
    , dann sehe ich auch

    Code
    tail -25 /usr/local/mysql/var/N4.err | grep Maria

    Dann sehe ich unter anderem:

    Code
    /usr/local/mysql/bin/mysqld (mysqld 5.5.51-MariaDB) starting as process...

    Demnach läuft die MariaDB, wenn ich den mysqld starte - also scheint das "alte" mysql nicht mehr parallel zu laufen.
    Alos ist die Versions-Anzeige auf der Konfig-Seite offenbar falsch.
    Es erscheint allerdings auch:

    Code
    170502 0:19:22 Percona XtraDB (http://www.percona.com) 5.5.49-MariaDB-38.0 started; log sequence number 56089072
Version: '5.5.51-MariaDB' socket: '/tmp/mysql.sock' port: 3306 MariaDB Server

    Ganz schönes Kuddelmuddel - auf auf Support und Entwickler - entwirrt das Knäul ... ;-)Danke für den Hinweis.
    Mit Gruß aus Gö - Ralph

    Ich habe jetzt manuell den Zeitpunkt ab Systemstart bestimmt, zu dem der daemon gestartet werden kann. Vorher reagiert das System nicht auf den Startbefehl, log sagt:


    Code
    /usr/local/mysql/bin/mysqld_safe: line 182: /usr/local/mysql/bin/mysqld: No such file or directory


    Danach ein kleines Bash-Script zum Starten et voilà, das kleine Problem ist gelöst.

    Hi!
    Demnach ist das ein Timing Problem? Danke für die Antwort!
    Natürlich lässt sich ein bash-script per cronjob einbauen, aber will ich das?
    Dann müsste ich das ja auch selbst supporten ...
    Ich habe dieses Thema auch erst auf gemacht nachdem der mysqld im
    laufenden Betrieb abgeschmiert ist. :thumbdown:
    Da normalerweise mein NAS bis zum Firmwareupdate durch läuft
    (deshalb habe ich ja das leiseste & stromsparendste NAS genommen ...),
    hätte mich das ja gar nicht sooo sehr gestört und bis zum nächsten FW Update die Füsse still gehalten.
    :|
    Nun hat der mysqld aber aus "heiterem Himmel" angehalten. :cursing: Weder in der LOG-Datei kann ich
    etwas finden, noch wäre das NAS neu gestartet (uptime dagt es liefe bereits seit 6 Tagen). ?(
    Mysql ist ja nun nicht eine sooo exotische Applikation für ein NAS; das mit
    Webserver, Datenbank und php wirbt ... und Owncloud, WordPress, pydio/Ajaxplorer etc anbietet ...
    (Im Vergleich dazu habe ich es in meiner Firma in 17 Jahren nur 1 mal erlebt, dass der
    mysqld nicht verfügbar war ... (Linux Server mit typ. Uptimes zwischen 50 und 500Tagen)).
    Und auch seit ich meiner ersten QNAP 109-er, hatte ich bislang erst einmal Probleme
    mit mysql (und auch mit anderen Applikationen), weil /tmp voll gelaufen war - also auch nachvollziehbar.


    Da soll QNAP mal schön selber, warum mysql nicht startet / abschmiert. Es scheint ja auch häufiger aufzutreten.


    BTW:
    Bislang fragte der Support nach, ob ich die FW downgraden könne um nachzuvollziehen,
    ob sich das System weiter so verhält. Ich habe geantwortet, dass ich vorher keine Probleme hatte.

    Die Ursache des Fehlers auf meinem NAS war, dass QMariaDB vor langer Zeit über das App-Center
    installiert wurde (Danke an user Trexx im int. Forum).


    1. SQL-Server deaktivieren in Systemsteuerung - Anwendungen - SQL-Server
    2. QMariaDB in App-Center löschen
    3. Reboot
    4. SQL-Server reaktivieren in Systemsteuerung - Anwendungen - SQL-Server


    Vorsichtshalber ein Backup der MySQL-Daten bereithalten.

    OK, habe Schritt 3 und 4 versehentlich vertauscht - tut auch!!!
    TNX1E6 !!!!
    Der QNAP Support hat das nicht (so schnell) raus bekommen, aber mich auf die neue Firmware:
    4.3.3.0174 aufmerksam gemacht, die das Problem lösen sollte .... aber keine Veränderung gebracht hat.
    Das Deinstallieren der QMariaDB hat's gebracht und ich musste auch meine Datenbanken nicht neu installieren
    (zumindest laufen mind. 3 der Tabellen, die anderen noch nicht getestet).


    Herzliche Grüße aus Gö - Ralph

    @Salegy
    Seit 10 Tagen habe ich beim Support ein unbearbeitetes Ticket :(( und dein Workaround hat mein SQL wieder zum Leben erweckt ;))


    Punkt 1 bis 3 war bei mir ausreichend.


    Vielen Dank für die Info!