Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)

[DS_Starter]

Hallo zusammen,

ich muß mich auch mal präzisieren .... ich verwende  ebenfalls MariaDB in der Version 5.5.47. Dies ist das DB-System welches derzeit auf Synology DSM als Paket ausgeliefert wird.

@Joe:

Ist das "lenth" hier eventuell ein Vertipper und sollte length heißen?

Richtig. Korrigiere ich.

könnte man das (irgendwann mal) noch erweitern um Parameter wie "delete-readings, all " oder eben eine separierte Liste an Readings, die mich interessieren?

Das kannst du jetzt schon eingrenzen. Dafür gibt es je nach get-Befehl ein Attribut showStatus, showVariables, showSvrInfo, showTableInfo.
Wenn du also nach dem "get ... tableinfo" nur Informationen über history sehen möchtest, setzt du in dem DbRep-Device:

Code Auswählen Erweitern


attr <DbRep-Dev> showTableInfo  %history%  (oder nur history)


Dann werden nur Infos zu dieser Tabelle generiert. Das ist dann schon sehr übersichtlich.

Und wenn du NUR die Info für "INFO_history.data_index_length_MB" sehen möchtest könntest du das Attribut suppressReading  verwenden:

Code Auswählen Erweitern


attr <DbRep-Dev> suppressReading  ^(?!.*INFO_history.data_index_length_MB).*$


siehe auch: http://fhem.de/commandref_DE.html#DbRepattr

@Frickler

Angenommen das Problem des "Konfigurationszerschiessen" beim FHEM Update lässt sich lösen.... was wäre performancetechnisch optimaler? 2 DBs mit jeweils einem deleteOldDays oder 1 DB mit 1 einem deleteOldDay und 15 delEntries?

Ergänzend zu Joes Ausführungen würde ich diese Frage konkret so beantworten, dass ich unter Performanceaspekten zu 1 DB und der enstprechenden Anzahl DbRep's mit delEntries raten würde.
Mein Hauptargument wäre, dass DbLog nach wie vor blockierend arbeitet, also bei allen Lese- oder auch Schreibaktivitäten dein FHEM enstprechend lange/kurz anhält bis die Aktion abgeschlossen ist.
Die Löschaktivitäten von den DbRep-Devices stören deine FHEM-Schleife nicht, brauchen natürlich auch CPU-Power, das ist klar. Aber die Löschläufe mußt du ja nicht alle zur gleichen Zeit einplanen. MySQL/MariaDB kann aber gut mit gleichzeitigen Lese- bzw. Löschzugriffen umgehen, kein Problem.

[JoeALLb]

Wollte noch einen Workaround kurz mit euch teilen:
Vor größeren Löschaktionen mache ich folgendes:

0. Erzeuge eine leere History-Tabelle
1. Ich benenne die aktuelle histopry-tabelle um und platziere eine neue, leere Tabelle dort. Dies funktioniert ohne Unterbrechung.
2. Ich lösche die Einträge in der Umbenannten Tabelle: FHEM kann somit völlig ungestört weiterarbeiten.
3. Ich benenne die Tabellen zurück um:
4. Ich kopiere die neuen Werte aus der "Temporären leeren History-Tabelle" wiede rzurück in die Haupttabelle
5. Ich lösche die Einträge de rtemporären History-Tabelle.

Die SQL Codes dazu lauten:

Code Auswählen Erweitern


create table history3 like history;
rename table history to history2; rename history3 to history;
[...] Bereinige die history-tabelle, die nun history2 heißt. zB delete from history2 where reading="XY";
rename history to history3; rename history2 to history;
insert into history select * from history3;
drop table history;


[DerFrickler]

Hallo zusammen,

die meisten der Anmerkungen von Euch (die ich verstanden habe) habe ich umgesetzt. Vielen Dank dafür! Mal sehen wie die DB in ein paar Tagen aussieht und was es noch so zu optimieren gibt.

die Version 4.8.4 sollte die Fehlermeldung

Code Auswählen Erweitern

DBD::mysql::st execute failed: Expression #2 of SELECT list is not in GROUP BY clause and contains nonaggregated column 'information_schema.tables.TABLE_SCHEMA' which is not functionally dependent on columns in GROUP BY clause; this is incompatible with sql_mode=only_full_group_by at ./FHEM/93_DbRep.pm line 3161.

eliminieren.

leider immer noch

Code Auswählen Erweitern

DBD::mysql::st execute failed: Expression #2 of SELECT list is not in GROUP BY clause and contains nonaggregated column 'information_schema.tables.TABLE_SCHEMA' which is not functionally dependent on columns in GROUP BY clause; this is incompatible with sql_mode=only_full_group_by at ./FHEM/93_DbRep.pm line 3190.


Jetzt halt in Zeile 3190

Gruß!

[DS_Starter]

leider immer noch

Neuer Versuch mit der Version 4.8.5.  Leider kann ich es bei mir nicht testen.
MariaDB bringt mit der bisherigen Abfrage keinen Fehler.
So wie ich im Netz gelesen habe, hat man mit MySQL 5.7 einen schon länger existierenden Industriestandard umgesetzt.

Man kann auch im Server Profil eine Anpassung vornehmen um diesen Fehler generell zu vermeiden. Hier ein Auszug aus https://blog.gabriela.io/2016/03/03/group-by-are-you-sure-you-know-it/

Change permanently

If you want to disable it permanently, add/edit the following in your my.cnf file:

sql_mode = "STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION"

For this change a service restart is required:
$ mysql service restart

Aber versuche es erst einmal mit der neuen Version.

Grüße
Heiko

[DerFrickler]

Hallo,

auch mit der 4.8.5 tritt der Fehler auf:

Code Auswählen Erweitern

DBD::mysql::st execute failed: Expression #2 of SELECT list is not in GROUP BY clause and contains nonaggregated column 'information_schema.tables.TABLE_SCHEMA' which is not functionally dependent on columns in GROUP BY clause; this is incompatible with sql_mode=only_full_group_by at ./FHEM/93_DbRep.pm line 3193.


Demnach gibt es halt die Optionen
1. Den SQL Mode umsetzen

Code Auswählen Erweitern

sql_mode = "STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION"

2. Migration nach MariaDB... das sollte laut ubuntuusers.de wie folgt möglich sein:

MySQL Deinstallieren:

Code Auswählen Erweitern

sudo apt-get purge mysql-server mysql-common mysql*
## Aufräumen:
sudo apt-get autoclean; sudo apt-get clean; sudo apt-get autoremove;
## Prüfen auf sql Reste:
dpkg -l | grep -i -e "sql\|maria"

MariaDB Installieren:

Code Auswählen Erweitern

sudo apt-get install mariadb-server

Insbesondere bei der Migration auf MariaDB... gibt es da noch mehr zu beachten? Welche der 2 Varianten ist mit mehr Risiken behaftet?

Gruß!

[DS_Starter]

Ich würde erstmal nur den SQL_Mode setzen in der my.cnf.
Das ist schnell gemacht.

Ich habe evtl. noch eine Idee den SQL-Mode in der Datenbanksession über das DBI-Interface im Modul zu setzen.
Das muß ich aber erst (morgen) im Modul einbauen. Dann testen wir erneut.

Versuche zunächst den Workaround über die my.cnf damit du vorankommst.

Grüße
Heiko

[DerFrickler]

Ich würde erstmal nur den SQL_Mode setzen in der my.cnf.
Das ist schnell gemacht.

über ein set global oder direkt editieren?

[DS_Starter]

my.cnf editieren und mysql restarten wie ich es in dem Ausschnitt weiter oben gefunden hatte.
Das halte ich für eine gute Methode die Änderung permanent zu machen.
Die ursprüngliche Zeile natürlich nur auskommentieren damit man sie wieder aktivieren kann bei Bedarf.
Kann man jederzeit wieder umeditieren wenn ich das Modul angepasst habe und es klappt.

[DS_Starter]

Guten Morgen,

in der V 4.8.6 wird ONLY_FULL_GROUP_BY temporär für die Dauer der Session durch das Modul gehändelt.

@Frickler bitte testen ob das nun zieht. Falls du die my.cnf schon geändert hast bitte wieder in der ursprünglichen Zustand bringen, mysql restarten und dann testen.

Grüße
Heiko

[DerFrickler]

Guten Morgen,

mit der 4.8.6 funktioniert es!

Gruß!
Karsten

[DS_Starter]

Danke Karsten !

Dann checke ich es auch ein.

Grüße
Heiko

[DerFrickler]

jetzt konnte ich aber folgendes beobachten....

das Reading INFO_history.data_index_length_MB schreibe ich auch in die DB. Kann es sein dass ein tableInfo die DB eine Zeit lang blockiert?

Im Logfile kann ich dann folgendes erkennen (unmittelbar nach dem get DbRep.Info tableinfo):

2016.12.17 14:30:24 2: DbLog: Failed to insert new readings into database: DBD::mysql::st execute failed: Data too long for column 'READING' at row 1 at ./FHEM/93_DbLog.pm line 613.

2016.12.17 14:30:24 3: Connecting to database mysql:database=fhem;host=127.0.0.1;port=3306 with user fhem
2016.12.17 14:30:24 3: Connection to db mysql:database=fhem;host=127.0.0.1;port=3306 established for pid 4279
2016.12.17 14:30:24 3: Connection to db mysql:database=fhem;host=127.0.0.1;port=3306 established

[DS_Starter]

Kann es sein dass ein tableInfo die DB eine Zeit lang blockiert?

Nein.

DbLog: Failed to insert new readings into database: DBD::mysql::st execute failed: Data too long for column 'READING' at row 1 at ./FHEM/93_DbLog.pm line 613.

Das Reading "INFO_history.data_index_length_MB" ist 33 Zeichen lang.
Die ALTE Feldlänge von DbLOg war 32 ! Zeichen. Im neueren DbLog-Releases ist die Feldlänge auf 64 angepasst.

Hast du deine Tabellen history / current mit diesen Statements angelegt ? (aus ../contrib/dblog/db_create_mysql.sql):

Code Auswählen Erweitern


CREATE DATABASE `fhem` DEFAULT CHARACTER SET utf8 COLLATE utf8_bin;
CREATE USER 'fhemuser'@'%' IDENTIFIED BY 'fhempassword';
CREATE TABLE `fhem`.`history` (TIMESTAMP TIMESTAMP, DEVICE varchar(64), TYPE varchar(64), EVENT varchar(512), READING varchar(64), VALUE varchar(128), UNIT varchar(32));
CREATE TABLE `fhem`.`current` (TIMESTAMP TIMESTAMP, DEVICE varchar(64), TYPE varchar(64), EVENT varchar(512), READING varchar(64), VALUE varchar(128), UNIT varchar(32));
GRANT SELECT, INSERT, DELETE, UPDATE ON `fhem`.* TO 'fhemuser'@'%';
CREATE INDEX Search_Idx ON `fhem`.`history` (DEVICE, READING, TIMESTAMP);


Wenn nicht kannst du die Feldlänge nachträglich z.B. ändern mit:

Code Auswählen Erweitern


ALTER TABLE `history` CHANGE `READING` `READING` VARCHAR(64) CHARACTER SET utf8 COLLATE utf8_bin NULL DEFAULT NULL;


Für die anderen Felder DEVICE; TYPE usw. gilt ähnliches.

[DerFrickler]

und da dachte ich doch dass die alle schon angepasst waren... wie man sich irren kann. Jetzt sollte aber alles soweit korrekt sein.

Danke!
Karsten

[DS_Starter]

Prima 

Andre Baustelle .. bin gerade dabei die Log-Funktion von DbLog  auf non-blocking umzustellen. Läuft schon richtig gut.
Zu gegebener Zeit mache ich eine Diskussionsthread auf um dort dem DbLog-Maintainer und interessierten Testern das geänderte Modul bereitzustellen.

Ich mache euch darauf aufmerksam wenn es soweit ist.

Grüße
Heiko