configDB - suche Tipp Datenbankumstellung

Begonnen von SusisStrolch, 15 Juli 2017, 12:40:38

Vorheriges Thema - Nächstes Thema

SusisStrolch

Momentan läuft meine configDB gegen MySQL auf meiner Synology.
Da ich die Abhängigkeiten von Software-Updates ausklammern möchte, suche ich nun eine Vorgehensweise
um auf SQLite umzustellen.

Wie ist in diesem Falle die "Best Practice"?
Synology DS1515+, 16GB RAM, 4x 6TB WD-Red
- Docker (FHEM), MariaDB, MariaDB10, Surveillance Station
Gateways: LCG miniCUL433, LCG miniCUL868, AVR-X4000, VU-Solo SE, Kodi
ESP8266: ESPEasy (S0-Counter, Temp/Hum), Sonoff TH, Sonoff 4ch

betateilchen

-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

SusisStrolch

Was sind die Beweggründe?

Meine sind relativ einfach... Beim Update des letzten SQL-Packages war das System 5Std. damit beschäftigt, Kopien meiner diversen Datenbanken anzulegen.
DbLog sollte diese Auszeit mit seinem Caching-Mechanismus schaffen.
Für configDB gibt es keinen Cache, daher die Idee das ganze in eine SQLite zu legen, so dass zumindest die Basisfunktionen von FHEM weiterhin gegeben sind.
Synology DS1515+, 16GB RAM, 4x 6TB WD-Red
- Docker (FHEM), MariaDB, MariaDB10, Surveillance Station
Gateways: LCG miniCUL433, LCG miniCUL868, AVR-X4000, VU-Solo SE, Kodi
ESP8266: ESPEasy (S0-Counter, Temp/Hum), Sonoff TH, Sonoff 4ch

dev0

@SusisStrolch: Benutze die fhem.cfg statt configdb, dann hast Du diese selbstgemachten Probleme nicht. Es gibt mMn wenig Szenarien, in denen configdb Sinn macht.

betateilchen

Sowas kann nur jemand schreiben, der sich noch nie mit den Möglichkeiten, die configDB inzwischen bietet, auseinandergesetzt hat.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

betateilchen

Zitat von: SusisStrolch am 15 Juli 2017, 13:36:53
Was sind die Beweggründe?

Eigentlich egal. Wenn du es unbedingt tun willst...

- erstelle dir mit "configdb filelist" eine Liste aller Dateien, die in der configDB gespeichert sind.
- exportiere alle Dateien mit "configdb fileexport all" ins Dateisystem
- "attr global configfile fhem.cfg" anschliessend ein "save" und ein shutdown.

Nun kannst Du die Datenbank umstellen, danach startest Du FHEM einmal mit "fhem.cfg" und startest die Migration mit "configdb migrate". Danach FHEM wieder mit configDB starten und die evtl. fehlenden Dateien noch importieren.

Fertig.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

SusisStrolch

Zitat@SusisStrolch: Benutze die fhem.cfg statt configdb, dann hast Du diese selbstgemachten Probleme nicht. Es gibt mMn wenig Szenarien, in denen configdb Sinn macht.
Ich muss ganz ehrlich sagen, dass ich bei configdb mehr Vorteile als bei fhem.cfg sehe - alleine die Versionierung finde ich einfach genial.

Zitat- erstelle dir mit "configdb filelist" eine Liste aller Dateien, die in der configDB gespeichert sind.
...
Ok - d.h. das ist der Aufwand wenn ich von MariaDB auf SQLite gehen würde.

Ich nehme an, dass es bei MariaDB -> MariaDB ausreicht, einen mysqldump | mysql Import zu fahren?
Synology DS1515+, 16GB RAM, 4x 6TB WD-Red
- Docker (FHEM), MariaDB, MariaDB10, Surveillance Station
Gateways: LCG miniCUL433, LCG miniCUL868, AVR-X4000, VU-Solo SE, Kodi
ESP8266: ESPEasy (S0-Counter, Temp/Hum), Sonoff TH, Sonoff 4ch

betateilchen

Zitat von: SusisStrolch am 15 Juli 2017, 15:43:19
Ich nehme an, dass es bei MariaDB -> MariaDB ausreicht, einen mysqldump | mysql Import zu fahren?

Kommt drauf an, wie das mit den Binärdateien bei Deinem Dump funktioniert.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

dev0

Zitat von: SusisStrolch am 15 Juli 2017, 15:43:19
Ich muss ganz ehrlich sagen, dass ich bei configdb mehr Vorteile als bei fhem.cfg sehe - alleine die Versionierung finde ich einfach genial.
Versionierung kann man auch anders bewerkstelligen. Einen weiteren Nachteil sehe ich allerdings in der Unberechenbarkeit des Entwicklers, Module nach ./contrib zu verschieben, wenn Kritik mit Bashing verwechselt wird. Wenn man auf Dauer keinen Support benötigt, dann spielt das allerdings keine Rolle.

betateilchen

Nur mal so am Rande (fällt Dir eigentlich auf, wie weit Du schon wieder im offtopic bist?)


  • soviel bashing, dass ich configDB nach ./contrib verschieben würde, schaffst selbst Du nicht
  • die Möglichkeit der Versionierung ist nicht der einzige (und auch für viele Anwender nicht der wichtigste) Grund für den Einsatz von configDB
  • wenn Du am Support für configDB etwas auszusetzen hast, dann bitte sachlich und nicht mit solchen leeren Worthülsen wie hier im Thread
  • von mir wurde noch kein Modul tatsächlich wegen bashing nach ./contrib verschoben
  • auch für Module, die ich nach ./contrib verschoben habe, leiste ich in aller Regel noch Support *

* die vom DWD in den vergangenen Tagen angekündigte nächste große Umstellung in der Grundversorgung von Wetterdaten werde ich in 55_GDS.pm tatsächlich nicht mehr umsetzen.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

Burny4600

Was ist eigentlich der Vorteil von configDB gegenüber der fhem.cfg.
Mfg Chris

Raspberry Pi 2/2+/3/3+/4 / Betriebssystem: Bullseye Lite
Schnittstellen: RFXtrx433E, SIGNALduino, MQTT, nanoCUL, HM-MOD-UART, 1-Wire, LAN, ser2net, FHEM2FEHEM
Devices: S.USV, APC-USV, Fronius Datalogger Web 2, FS20, IT, Resol VBUS & DL2, TEK603, WMR200, YouLess, Homematic, MQTT

betateilchen

#11
Diese Frage ist bereits ca. 728 Mal hier im Forum beantwortet. Einfach mal ein bisschen lesen 😀

Es gibt nicht "den" (im Sinne von: nur einen) Vorteil, man muss das Gesamtkonzept betrachten.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

Burny4600

Sorry das ich fragte, aber ich war nicht auf einen Rätseltripp.
Dann lasse ich es leiber wie es ist.
Mfg Chris

Raspberry Pi 2/2+/3/3+/4 / Betriebssystem: Bullseye Lite
Schnittstellen: RFXtrx433E, SIGNALduino, MQTT, nanoCUL, HM-MOD-UART, 1-Wire, LAN, ser2net, FHEM2FEHEM
Devices: S.USV, APC-USV, Fronius Datalogger Web 2, FS20, IT, Resol VBUS & DL2, TEK603, WMR200, YouLess, Homematic, MQTT

betateilchen

Das hat überhaupt nichts mit Ratespiel zu tun.

Sorry, aber das Thema ist wirklich bis zum Exzess durchdiskutiert und ich habe keine Lust, das für jeden Fragesteller wieder von vorne zu beginnen, nur weil er zu bequem ist, die vorhandene Dokumentation zu lesen.

Eine grobe Orientierung gibt alleine schon die commandref ("help configdb" im Frintend einegeben)
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

Beta-User

Kleiner Erfahrungsbericht in dieser off-Topic-Sache, da ich die Frage nach den Vorteilen irgendwann in der Vergangenheit auch mal gestellt hatte.

Inwieweit man als reiner Anwender die commandref - abgesehen von der Versionierung, die dort gut beschrieben ist - für aufschlußreich halten kann, was die Vorteile angeht, mag jeder für sich selbst beurteilen und welche Stichworte man braucht, um die richtigen Threads zu finden, hat mich irgendwann auch nicht mehr interessiert ::) .

Was mir zu fhem.cfg-Zeiten hin und wieder passiert ist: Meine 1-Wire-DS18B20 waren verschwunden... Ich habe dann regelmäßig das entsprechende include wieder aus dem Backup herstellen dürfen, wenn ich beim Speichern übersehen hatte, dass der Bus ein Problem hat. Ob das mit dem Umstieg auf configDB wirklich technisch zusammenhängt, kann ich als Laie nicht beurteilen, aber jedenfalls ist mir das - oder etwas ähnliches -  nach dem Umstieg nicht mehr passiert.

Echte Nachteile konnte ich bisher nicht feststellen, für Notfälle speichere ich über den attr global-Weg immer mal wieder eine aktuelle fhem.cfg raus und habe so auch den Umzug vom PI auf die Amlogic-Box gemacht. Die DB liegt bei mir nicht auf einem Netzwerkserver, sondern lokal.

Das einzige Mal, bei dem ich den Eindruck hatte, dass ein Modul nicht korrekt mit configDB zusammenarbeitet, war mit hminfo (Abgleich der templisten); näher untersucht habe ich das allerdings bislang nicht, ist allenfalls ein Schönheitsfehlerchen (wenn, dann von hminfo ;) ).

Gruß, Beta-User
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files