MariaDB 10 lässt sich nicht mehr starten und Backup funktioniert nicht

[Raychan]

Guten Morgen,

ich habe ein Probleme und komme nicht weiter.

Ich habe die DS916+ mit aktuellster version.

Dadrauf ist ein Webserver, MariaDB10 und phpmyadmin.

Nach dem heutigen Update habe ich heute morgen bemerkt das der MariaDB10 nicht mehr startet. "Paket kann nicht ausgeführt werden".
Ich habe versucht über Hyperbackup MariaDB10 wiederherzustellen aber das Backup lässt sich nicht raufspielen.

Auch kein erfolg von löschen und neuinstallieren der MariaDB10 (mit und ohne DB).

Festplatten habe ich auch durchchecken lassen und die SMART werte sind alle gut.

Ich brauch Hilfe und komme nicht weiter. :'(

 

[Puppetmaster]

Nach welchem Update?

 

[Raychan]

Nach dem neuen DSM Update. (DSM 6.2.1-23824)

 

[Puppetmaster]

Vielleicht kannst du das auch genau benennen?

DSM 6.2.1-23824 wäre jetzt das letzte mir bekannte, ist aber nicht wirklich neu...

 

[Raychan]

Ja genau von der letzten Version davor DSM 6.2....... auf DSM 6.2.1-23824

 

[Puppetmaster]

Ok, sehe da nämlich, dass es anscheinend auch bei anderen Probleme mit Paketen gibt. z.B. hier.

 

[Raychan]

Komme ich irgendwie zurück auf eine ältere Version?

Ich habe mit HyperBack eigentlich das gesamte DS916+ auf eine DS414j gesichert.

 

[Puppetmaster]

Ich würde mich da zunächst an Synology wenden und ein Ticket aufmachen. Evtl. sind solche Probleme ja bereits bekannt.

PS: ein Update der MariaDB wird dir aber im Paketzentrum nicht angeboten?

 

[Raychan]

Ich habe die Lösung gefunden:

Ich habe die Datei my.cnf im Pfad
.../var/packages/MariaDB10/etc
gesichert und danach gelöscht

nun startet MariaDB10 wieder. Jetzt muss ich nur noch hoffen das das HyperBackup meine Datenbank wiederherstellt.

Ich muss sagen bin aktuell sehr entäuscht von HyperBackup. Gibt es ein andere Backup App die wirklich eine Sicherung und wiederherstellung des DSM System mit Apps ermöglicht???

 

[Frogman]

Nein, als altem Hasen sollte Dir das allerdings bereits bekannt sein.

 

[the_baker]

Das ist ja spannend. Genau am 9.10. ging auch bei mir die MariaBD kaputt. Bemerkt habe ich es erst eben. Neustart geht nicht, Backup meckert seit dem 9.10., dass die DB nicht zu backupen ging.


.../var/packages/MariaDB10/etc ist bei mir quasi leer, bis auf .mariadb.conf

Nach dem Erfahrungsbericht hier frage ich mich nun, ob das so eine gute Idee ist, es einfach damit zu versuchen die DB aus dem Backup zu ziehen...?

Update:
Ok. ich habs versucht: Operation fehlgeschlagen. Also auch ich kann das Backup nicht einspielen.

Und nun?

 

[the_baker]

Update:

Frage: Wenn ich Wordpress piwik und MariaDB deinstalliere (so es überhaupt geht), und wenn ich dabei die Daten jeweils nicht lösche, übernimmt dann eine re-installation die vorhandenen Daten?
Wenn ich das mit piwik ausprobiere kam beim Versich piwik wieder zu installieren der Fehler, dass die Maria DB zuerst laufen müsse.

/var/log/ sagt beim Versuch die DB zu starten:

2018-10-19T19:05:26+02:00 ds root: MariaDB: UpgradeDatabase: Failed to enter single user mode
2018-10-19T19:05:26+02:00 ds synopkgctl: resource_api.cpp:231 Release webapi-desc for MariaDB10 when 0x0008 (done)
2018-10-19T19:05:26+02:00 ds synopkgctl: resource_api.cpp:231 Release webapi-desc for MariaDB10 when 0x0008 (done)
2018-10-19T19:05:26+02:00 ds synopkgctl: SYSTEM:	Last message 'resource_api.cpp:231' repeated 1 times, suppressed by syslog-ng on ds
2018-10-19T19:05:26+02:00 ds [53872.778017] init: pkgctl-MariaDB10 pre-start process (31941) terminated with status 1
2018-10-19T19:05:26+02:00 ds synoscgi_SYNO.Core.Package.Control_1_start[31324]: servicecfg_internal_lib.c:187 Failed to start job [pkgctl-MariaDB10][0xD900 manager.cpp:204]
2018-10-19T19:05:27+02:00 ds synopkgctl: resource_api.cpp:231 Release webapi-desc for MariaDB10 when 0x0000 (done)
2018-10-19T19:05:27+02:00 ds synopkgctl: resource_api.cpp:231 Release webapi-desc for MariaDB10 when 0x0000 (done)
2018-10-19T19:05:28+02:00 ds synopkgctl: SYSTEM:	Last message 'resource_api.cpp:231' repeated 1 times, suppressed by syslog-ng on ds
2018-10-19T19:05:28+02:00 ds synoscgi_SYNO.Core.Package.Control_1_start[31324]: service_initjob_action.c:27 InitJobStart failed, [0xD900 manager.cpp:204]
2018-10-19T19:05:28+02:00 ds synoscgi_SYNO.Core.Package.Control_1_start[31324]: pkgstartstop.cpp:367 Failed to start pkgctl-MariaDB10 (err=-1) [0xD900 manager.cpp:204]
2018-10-19T19:05:28+02:00 ds synoscgi_SYNO.Core.Package.Control_1_start[31324]: resource_api.cpp:231 Release syslog-config for MariaDB10 when 0x0010 (done)
2018-10-19T19:05:28+02:00 ds synoscgi_SYNO.Core.Package.Control_1_start[31324]: resource_api.cpp:231 Release indexdb for MariaDB10 when 0x0010 (done)

Es gibt wohl Leute, die warten seit 10 Tagen vergeblich auf Antwort vom Support. Das sorgt für Frust.

Jemand hat das Problem "gelöst", indem er manuell downgegradet hat. Dadurch hat er sich aber andere Probleme eingefangen. Andere haben wohl die ganze Diskstation platt gemacht und neu aufgesetzt.

Ideen?

Wie kann man die wichtigste Daten auf eine zweite, kleine Diskstation spiegeln um von dort aus wiederherzustellen? So ein Mist, vermaledeiter.

 

[the_baker]

Kleines Update: Status beim Synology-Support:

Ihr Problem wurde an unsere Ingenieure zur weiteren Analyse weitergeleitet.
Ich werde dich informieren, sobald ich Neuigkeiten erhalte.

 

[blinddark]

Das Problem ist nur entstanden, wenn man in der my.cnf zu viele änderungen drin standen. Ich vermute, dass einige Pfade oder Einstellungen mit dem Letzten MariaDB 10 Update nicht mehr gültig sind. Ich habe meine auch gelöscht und nur die Änderungen rein geschrieben, die ich wirklich benötige. Zuvor hatte ich nur eine Config von Synology kopiert und meine Einstellungen abgeändert wie z. B. den Port von 3307 auf 3306 geändert, damit ich allem Ärger aus dem Weg gehe. Quelle zur Änderung von MariaDB-Settings:
https://www.synology.com/de-de/know...ariaDB_settings_be_customized_on_Synology_NAS

Welche Einstellung da den Start blockiert hat, habe ich aber noch nicht geprüft. Eventuell wird es am Wochenende was.

 

[the_baker]

Ich habe da gar nichts geändert. Es hat von selber aufgehört zu funktionieren. Das Einzige, was ich im Anschluss gemacht habe, war den Tipp umzusetzen, die my.cnf zu löschen. MariaDB hat dann selbst eine neue angelegt.

Der Snyology-Techniker hat es immerhin geschafft, dass man die MariaDB nochmals neu updaten konnte. Das hat das Problem aber auch nicht behoben.

 

[lanadm]

Ich hatte auch das Problem, dass MariaDB10 nicht mehr starten wollte nach dem Update von DSM.
In /var/packages/MariaDB10/target/mysql/ds.err wurde geloggt:

2018-10-10 21:06:10 0 [ERROR] mysqld: Event Scheduler: An error occurred when initializing system tables. Disabling the Event Scheduler.
2018-10-10 21:06:10 6 [ERROR] InnoDB: Column last_update in table `mysql`.`innodb_table_stats` is INT UNSIGNED NOT NULL but should be BINARY(4)
NOT NULL (type mismatch).
2018-10-10 21:06:10 6 [ERROR] InnoDB: Fetch of persistent statistics requested for table `mysql`.`gtid_slave_pos` but the required system tables
 mysql.innodb_table_stats and mysql.innodb_index_stats are not present or have unexpected structure. Using transient stats instead.

Die hier beschriebene Reparatur der Datenbank hat bei mir das Problem beseitigt: https://serverfault.com/questions/100685/cannot-proceed-because-system-tables-used-by-event-scheduler-were-found-damaged/224487#224487

 

[Herbert_Testmann]

Hallo

bei mir lässt sich MariaDB10 auch nicht mehr starten.
- Löschen der Datei my.cfg hat nicht geholfen.
- die Reparatur mit mysqlcheck bekomme ich nicht hin. Ich habe zwar den Pfad zu der Datei gefunden, aber das Kommando wird nicht ausgeführt

admin@DS114maddy:/volume1/@appstore/MariaDB10/usr/local/mariadb10/bin$ ls

aria_chk        myisam_ftdump               mysqld                mysql_plugin         resolve_stack_dump
aria_dump_log   myisamlog                   mysqld_multi          mysql_setpermission  wsrep_sst_common
aria_ftdump     myisampack                  mysqld_safe           mysqlshow            wsrep_sst_mariabackup
aria_pack       my_print_defaults           mysqld_safe_helper    mysqlslap            wsrep_sst_mysqldump
aria_read_log   mysql                       mysqldump             mysqltest            wsrep_sst_rsync
innochecksum    mysqlaccess                 mysqldumpslow         mysql_tzinfo_to_sql  wsrep_sst_xtrabackup
mariabackup     mysqladmin                  mysql_find_rows       mysql_upgrade        wsrep_sst_xtrabackup-v2
mariadb_config  mysqlbinlog                 mysql_fix_extensions  mysql_waitpid
mbstream        mysqlcheck                  mysqlhotcopy          perror
msql2mysql      mysql_client_test           mysqlimport           replace
myisamchk       mysql_convert_table_format  mysql_install_db      resolveip

admin@DS114maddy:/volume1/@appstore/MariaDB10/usr/local/mariadb10/bin$ mysqlcheck -u root -p --all-databases --check-upgrade --autorepair
-sh: mysqlcheck: command not found

hat jemand eine Idee wie ich mysqlcheck aufrufen muss?

PS MariaDB deinstallieren und unterVerwendung dervorhandenen DB neu installieren ht auch nicht geholfen. Das Paket startet nicht .

 

[Lux007]

Hallo!
Am besten den vollen Pfad verwenden:

/usr/local/mariadb10/bin/mysqlcheck -u root -p --all-databases --check-upgrade

Die Option --autorepair wird bei mir nicht unterstützt...

Gruß
Lux007

 

[lanadm]

Man muss als Benutzer root arbeiten, nicht als admin.
Also zuerst sudo -i.

Dann in das Verzeichnis wechseln mit
cd /volume1/@appstore/MariaDB10/usr/local/mariadb10/bin

Jetzt kann der Befehl abgesetzt werden:
./mysqlcheck -u root -p --all-databases --check-upgrade --auto-repair

mysqlcheck fragt dann nach dem Passwort des Datenbankbenutzers root. Danach geht die Prüfung los.

 

[Herbert_Testmann]

ok, danke.

Ich habe in der Zwischenzeit leider zu viel selbst probiert und die DB ist unwiederbringlich weg.
Kein Backup - selbst Schuld.