Ab dem morgigen Update steht der neue Befehl "configdb dump" zur Verfügung, mit dem man den Inhalt der Konfigurationsdatenbank in ein Dump-File (ASCII, gezipped) schreiben kann.
Dabei ist folgendes zu beachten:
- Der Befehl steht (derzeit) nur für sqlite und mysql Anwender zur Verfügung!
- Der Dateiname beinhaltet Angaben zum Zeitpunkt der Ausgabe und sieht so aus: configDB_2016-05-22_18-11-50.dump.gz
- Die Datei wird in das ./log Verzeichnis von fhem geschrieben, dabei wird modpath berücksichtigt.
Nach Eingabe des Befehls sollte man im Frontend folgende Rückmeldung bekommen:
configDB dumped 2660 bytes
from: /opt/fhem/configDB.db
to: ./log/configDB_2016-05-22_18-47-54.dump.gz
Der Befehl "configdb dump" sollte ab dem morgigen Update auch für mysql und postgresql funktionieren.
Wäre schön, wenn entsprechende DB-Anwender das testen könnten und mir Rückmeldung geben.
Ich finde irgendwie keinen Hinweis auf eine funktionierende POSTGRESQL
} elsif ($dbtype eq 'POSTGRESQL') {
return "configdb dump not yet supported for POSTGRESQL!";
Bist noch nicht so weit :)
Zitat von: betateilchen am 28 Mai 2016, 13:26:03
Der Befehl "configdb dump" sollte ab dem morgigen Update
Welchen Teil dieses Satzes verstehst Du nicht?
So ich habe gerade mal mit ner mysql datenbank ein configdb dump gemacht.
mysqldump: Got error: 1044: "Access denied for user 'fhem'@'%' to database 'fhemConfigDB'" when using LOCK TABLES
liegt nicht am Modul. Muss man halt die Rechte der DB für den User anpassen. Nur so zur Info.
GRANT LOCK TABLES ON DBNAME.* TO 'USERNAME';
Das hilft
Zitat von: betateilchen am 28 Mai 2016, 13:57:13
Welchen Teil dieses Satzes verstehst Du nicht?
Den Teil das ich es gerade frisch aus dem SVN gezogen habe. So vor 10 Min. Jetzt denke ich das Du bis morgen den POSTGRESQL Teil noch einbauen wirst.
Grüße
Zitat von: CoolTux am 28 Mai 2016, 14:03:35
So ich habe gerade mal mit ner mysql datenbank ein configdb dump gemacht.
Danke fürs Testen.
Zitat von: CoolTux am 28 Mai 2016, 14:05:10
Den Teil das ich es gerade frisch aus dem SVN gezogen habe.
Tja, ich hatte nirgends geschrieben, das postgresql schon in SVN ist ;)
Und bis zum "morgigen Update" habe ich noch 17,5 Stunden Zeit :P
Hast ja Recht. :) Man muß ja nicht immer alles auf einmal machen. In der Ruhe liegt bekanntlich die Kraft.
Dan noch frohes schaffen.
Grüße
Das mit dem postgresql wird nix bis morgen.
Keine Zeit? Kann man helfen?
Der dump Befehl ist nicht das Problem, den hab ich inzwischen.
Aber es gibt ungelöste grundlegende Probleme beim Einsatz von postgresql mit configDB: https://forum.fhem.de/index.php/topic,50094.0.html
Bin im Urlaub nicht dazugekommen, mich darum zu kümmern und die bereitgestellte Datei, die ich seinerzeit bekommen hatte, ist irgendwo auf meinem Rechner verschwunden.
An das Thema kann ich mich erinnern. Vielleicht ist Matze so nennt und sendet sie Dir noch mal zu.
Servus,
Ich hab deine Nachricht bekommen und werde dir die Datei später nochmal schicken, komme aktuell nicht an den Rechner!
Gruß Matze
Super, danke :)
Ich hab mir jetzt auf meinem Entwicklungssystem tatsächlich einen postgresql Server aufgesetzt und configDB scheint aktuell zu laufen.
Bisher habe ich dazu nur zwei Änderungen eingebaut:
- Datentyp für binäre Daten von blob auf bytea geändert
- die extension uuid-ossp wurde entfernt
Im Moment habe ich noch Probleme mit diversen defines, die plötzlich nicht mehr funktionieren, wenn die Konfiguration aus postgresql kommt.
Bin gespannt, welche Änderungen sonst noch notwendig sind.
Mit dem morgigen update kommen neue Versionen der Dateien ./configDB.pm und ./FHEM/98_configdb.pm
Damit sollten sowohl die Vorschläge aus dem älteren Thread umgesetzt als auch der Befehl "configdb dump" für postgresql verfügbar sein.
Die Dateien sind ab sofort auch in svn verfügbar.
Super. Danke Dir für Deine Arbeit.
Grüße
Ich muss noch prüfen, wie der dump mit Binärdateien umgeht, die eventuell in der configDB gespeichert sind.
Aber für die reinen Konfigurationsdaten sollte es problemlos funktionieren.
Auf der ToDo Liste steht auch noch die Überlegung, auf Wunsch ungezippte dumps zu erzeugen. Muss ich noch drüber nachdenken, ob das wirklich Sinn macht.
Mal was zum Thema Binärdateien.
Ich habe ja die Möglichkeit eine 99_myUtils_blabla.pm in die DB zu laden. Was genau passiert dann? Ist das nur als Backup oder lädt er die Datei dann auch aud der DB? Kann ich dann die original Datei löschen?
Wenn ich dann die Datei wieder bearbeiten möchte, mache ich ein export, bearbeite sie und dann wieder ein import? Habe das Konzept noch nicht so ganz durchschaut.
Danke Dir
Grüße
Zitat von: CoolTux am 30 Mai 2016, 11:22:53
eine 99_myUtils_blabla.pm in die DB zu laden. Was genau passiert dann? Ist das nur als Backup oder lädt er die Datei dann auch aud der DB? Kann ich dann die original Datei löschen?
Die 99_myUtils... wird dann direkt aus der DB geladen. Du SOLLTEST sogar die Originaldatei löschen, weil sonst beide Dateien geladen werden. Also mit "filemove" importieren und nicht mit "fileimport".
Zitat von: CoolTux am 30 Mai 2016, 11:22:53
Wenn ich dann die Datei wieder bearbeiten möchte, mache ich ein export, bearbeite sie und dann wieder ein import?
Viel einfacher: Du bearbeitest die Datei einfach über "Edit files" dann wird sie automatisch aus der Datenbank geladen und nach dem Bearbeiten auch wieder dorthin abgespeichert. Du erkennst das an der Rückmeldung "saved to configdb".
Könnt Dir knuddeln. Lach
Ich danke Dir sehr. Ich denke das ist etwas was ich gut verwenden kann. So schön einfach und funktional.
Grüße
Was hast Du denn anderes erwartet?
Nicht erwartet, nur nicht richtig verstanden. Ich dachte wenn gelöscht dann exportieren, ändern und wieder importieren. Auf die einfache Lösung bin ich erst gar nicht gekommen.
Aber das ist typisch ich, manchmal denke ich zu kompliziert und zäume das Pferd von hinten auf ;D
Frage mich gerade wieso man configDB nicht als FHEM Standard macht. Es macht einiges leichter finde ich.
Zitat von: CoolTux am 30 Mai 2016, 11:57:53
Aber das ist typisch ich, manchmal denke ich zu kompliziert
manchmal? :o
Zitat von: CoolTux am 30 Mai 2016, 12:00:21
Frage mich gerade wieso man configDB nicht als FHEM Standard macht.
Frag doch mal Rudi. Mir glaubt er es ja nicht :)
Schade. Aber wird schon seinen Sinn und Zweck haben wieso es so ist.
Habe gerade auch gelesen das da wohl jemand ein SQL Abfragemodul für DBLog macht. Ob er sich damit einen Gefallen tut, sollte er es veröffentlichen?
Die User werden mehr Wünsche und Fragen haben wie ihm lieb sein kann. Dann lieber sagen die sollen sich phpmyadmin oder wie das heißt installieren.
Aber ich schweife ab.
Grüße
Zitat von: CoolTux am 30 Mai 2016, 12:42:15
Schade. Aber wird schon seinen Sinn und Zweck haben wieso es so ist.
Das Totschlagargument war bisher immer "die benötigten Zusatzmodule und die Fritzkotz-Benuter" wobei man sich von der Plattform ohnehin irgendwann verabschieden sollte. Ausserdem ist sqlite auf jeder Fritzkotz (https://forum.fhem.de/index.php/topic,20117.msg144303.html#msg144303) von Haus aus vorhanden :D
Es gab vor über zwei Jahren schonmal eine Diskussion zu dem Thema: https://forum.fhem.de/index.php/topic,21081.0.html
habe mal durchgelesen. Interessanterweise hate fheinz damals den selben Gedanken wie ich was den Umgang mit import und export und den Dateien angeht. Lach.
bei mir kommt bei dump folgende Ausgabe :-(
configDB dumped 0 bytes
aber FHEM läuft super gut mit der configDB.
Die Datei wird auch entsprechend angelegt - sollte also auch kein Rechtsproblem sein.
sehe gerade im Log...
mysqldump: Got error: 1045: Access denied for user 'fhem'@'localhost' (using password: YES) when trying to connect
meine DB liegt aber nicht auf dem localhost :-)
das ist der Schnipsel aus der .conf OHNE Passwort
connection => "mysql:database=fhem;host=mymac.heibox.intern;port=3306",
user => "fhem",
dann war wohl der dump Befehl für die mysql Datenbank doch nicht so einfach wie vermutet. Vermutlich muss der hostname noch als Parameter mit übergeben werden ...
Die gleichbedeutende Fehlermeldung gabs hier im Thread schonmal: https://forum.fhem.de/index.php/topic,53689.msg455421.html#msg455421
$ret = qx(mysqldump --user=$dbuser --password=$dbpass --host=host_name -Q $dbname > $target);
So sollte es gehen. Aber die Hostvariable muss noch korrekt eingesetzt und vorallem ermittlet werden.
Kann bitte ein mysql Benutzer testen, der nicht localhost als Server nutzt, ob die angehängte Version den Dump korrekt ausführt?
Na dann am besten Wuppi98.
Habe leider gerade keine externe DB zur Hand.
Zitat von: betateilchen am 30 Mai 2016, 15:32:50
Kann bitte ein mysql Benutzer testen, der nicht localhost als Server nutzt, ob die angehängte Version den Dump korrekt ausführt?
System startet ordentlich
configdb dump gibt folgendes
configdb dump not supported for !
Bitte jetzt nochmal testen.
Eigentlich muss ich den hostname auch noch bei postgresql einbauen *grübel*
so,
jetzt läuft es :-)
ABER
es sichert natürlich die ganze DB ... da logge ich auch rein :-) (* Eventuell den mysqldump in den Hintergrund ampersanden, oder nur die Configtabelle sichern? *)
Du hast nicht wirklich für DBLog und DBConfig das selbe Datenbankschema genommen?! Das ist ja böse.
Es wird die komplette Datenbank gesichert, die in configDB.conf angegeben ist. Und daran werde ich nichts ändern.
Folgende Änderungen habe ich jetzt noch eingebaut:
- 'configdb dump unzipped' liefert unkomprimierte Dateien
- hostname und port werden jetzt auch für postgresql ausgewertet
- die ausgeführten shell-Befehle werden im Loglevel 4 geloggt
Ab sofort in svn verfügbar.
Zitat von: CoolTux am 30 Mai 2016, 19:47:25
Du hast nicht wirklich für DBLog und DBConfig das selbe Datenbankschema genommen?! Das ist ja böse.
warum ist das böse?
Eine FHEM Instanz eine Datenbank
aber ich glaube ich werde das dann auch entsprechend ändern (müssen)
Oder es doch über ein Schell-Script lösen. Sicher bei mir jede DB in eine eigene Datei ...
Zitat von: Wernieman am 30 Mai 2016, 21:22:44
Sicher bei mir jede DB in eine eigene Datei ...
Hä? Genau das tun wir hier doch auch?
Wenn man natürlich die Tabellen von configDB und DbLog in EINE Datenbank packt (was wohl der Ausnahmefall sein dürfte) kommt es zu der Situation, über die hier gerade diskutiert wird.
O.K. .. sorry, aber ich habe mir Dein DB-Backup nicht nachgesehen, da es bei mir schon länger läuft ...
Hallo zusammen,
bei dem Befehl config dump ist mir ein Fehler bei dem MySQL Adapter aufgefallen, aus
my $dumpcmd = "mysqldump --user=$dbuser --password=$dbpass --host=$dbhostname --port=$dbport -Q $dbname $gzip > $target";
sollte man machen:
my $dumpcmd = "mysqldump --user='$dbuser' --password='$dbpass' --host='$dbhostname' --port=$dbport -Q $dbname $gzip > $target";
Durch die Anführungszeichen kommt es zu keinem Problem mit Sondernzeichen. Die sind zumindest bei mir im Password drinnen und führten zu einer leeren Sicherung.
Gibt es denn die Möglichkeit den Dump an einem anderen Ort zu sichern? Modpath möchte ich ungern anpassen, nur um das Backup an einem anderen Ort speichern zu können. Sonst baue ich mir ein Shell-Skript, welches täglich die Dumps wegsichert.
Derzeit nicht, aber ich kann mal drüber nachdenken.
Danke!
DBRep hat auch noch eine schöne Option mit maximaler Anzahl von Backups :) aber beides nur wenn du Zeit und Lust hast.
Zitat von: Hauswart am 01 Dezember 2017, 11:40:33
Gibt es denn die Möglichkeit den Dump an einem anderen Ort zu sichern?
Ab dem morgigen Update.
configdb attr dumpPath /tmp
und schon wandern die dumps nach /tmp/ anstatt nach ./log/ (Das Verzeichnis ist natürlich frei wählbar, /tmp war nur ein Beispiel)
Zitat von: Hauswart am 02 Dezember 2017, 13:53:04
Option mit maximaler Anzahl von Backups
Was meinst Du damit?
Super danke. Ich meinte folgendes:
dumpFilesKeep - Es wird die angegeben Anzahl Dumpfiles im Dumpdir gelassen (default: 3). Sind mehr (ältere) Dumpfiles vorhanden, werden diese gelöscht nachdem ein neuer Dump erfolgreich erstellt wurde. Das globale Attribut "archivesort" wird berücksichtigt.
Gesendet von iPhone mit Tapatalk
Zitat von: Hauswart am 03 Dezember 2017, 16:03:39
Sind mehr (ältere) Dumpfiles vorhanden, werden diese gelöscht
Das lässt sich out-of-the-box per logrotate auf Betriebssystemebene einrichten.
Deshalb will, muss und werde ich das nicht nachbauen.
Hi zusammen,
wie sieht es denn mit der Möglichkeit aus, in einen anderen Pfad zu dumpen? Und evtl auch ein überschreiben nach einer bestimmten Anzahl von Tagen oder ähnliches?
@Hauswart: Hast du das sonst in deinem Skript so angewendet und könntest dieses bereitstellen?
Danke & Gruß,
Tobi
Zitat von: onkel-tobi am 12 Oktober 2019, 11:13:47
Hi zusammen,
wie sieht es denn mit der Möglichkeit aus, in einen anderen Pfad zu dumpen? Und evtl auch ein überschreiben nach einer bestimmten Anzahl von Tagen oder ähnliches?
@Hauswart: Hast du das sonst in deinem Skript so angewendet und könntest dieses bereitstellen?
Danke & Gruß,
Tobi
Zitat von: betateilchen am 02 Dezember 2017, 20:51:21
Ab dem morgigen Update.
configdb attr dumpPath /tmp
und schon wandern die dumps nach /tmp/ anstatt nach ./log/ (Das Verzeichnis ist natürlich frei wählbar, /tmp war nur ein Beispiel)
Um alte Dumps weg zu sichern und später zu löschen nimmt man logrotate
Hm,
ich scheine das mobil irgendwie überlesen zu haben, auch das mit dem logrotate...
Sorry dafür.
Danke & Gruß,
Tobi
Gesendet von iPhone mit Tapatalk
Ich mache ein dump über configdb dump unzipped.
Wenn ich mir die Datei nun ansehe, ist sie quasi leer:
-- MySQL dump 10.13 Distrib 8.0.20, for Linux (x86_64)
--
-- Host: 192.168.178.15 Database: fhem
-- ------------------------------------------------------
-- Server version 5.5.5-10.4.12-MariaDB-1:10.4.12+maria~bionic
/*!40101 SET @OLD_CHARACTER_SET_CLIENT=@@CHARACTER_SET_CLIENT */;
/*!40101 SET @OLD_CHARACTER_SET_RESULTS=@@CHARACTER_SET_RESULTS */;
/*!40101 SET @OLD_COLLATION_CONNECTION=@@COLLATION_CONNECTION */;
/*!50503 SET NAMES utf8mb4 */;
/*!40103 SET @OLD_TIME_ZONE=@@TIME_ZONE */;
/*!40103 SET TIME_ZONE='+00:00' */;
/*!40014 SET @OLD_UNIQUE_CHECKS=@@UNIQUE_CHECKS, UNIQUE_CHECKS=0 */;
/*!40014 SET @OLD_FOREIGN_KEY_CHECKS=@@FOREIGN_KEY_CHECKS, FOREIGN_KEY_CHECKS=0 */;
/*!40101 SET @OLD_SQL_MODE=@@SQL_MODE, SQL_MODE='NO_AUTO_VALUE_ON_ZERO' */;
/*!40111 SET @OLD_SQL_NOTES=@@SQL_NOTES, SQL_NOTES=0 */;
--
-- Table structure for table `fhemversions`
--
DROP TABLE IF EXISTS `fhemversions`;
/*!40101 SET @saved_cs_client = @@character_set_client */;
/*!50503 SET character_set_client = utf8mb4 */;
CREATE TABLE `fhemversions` (
`VERSION` int(11) DEFAULT NULL,
`VERSIONUUID` char(50) COLLATE utf8_bin DEFAULT NULL
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_bin;
/*!40101 SET character_set_client = @saved_cs_client */;
--
-- Dumping data for table `fhemversions`
--
LOCK TABLES `fhemversions` WRITE;
/*!40000 ALTER TABLE `fhemversions` DISABLE KEYS */;
INSERT INTO `fhemversions` VALUES (9,'c16989116e4470e1a3b8c13d5420ac04'),(8,'5eb3ffb63617b22a142358c4475aedb8'),(7,'b3d540b7ae31b27b81c0cb1492f5eea9'),(6,'dada12d1890aafa778d0e620164fe6ee'),(5,'a82eb2e20b5d5beda95404eb01926545'),(4,'81b861b5c1a2b2f340bdc8dab5efed58'),(3,'e2844e480caf7c4f43a8910e6ad23519'),(2,'a42740a8b0ef0b1f0915ed4b620724ea'),(1,'788e47f53e3de55013c9a9358d520a27'),(0,'677fdaffde49befb35c68b91c33d7a23');
/*!40000 ALTER TABLE `fhemversions` ENABLE KEYS */;
UNLOCK TABLES;
Die DB hat 6 Tabellen
Zitat von: TWART016 am 28 Juni 2020, 01:14:38
Die DB hat 6 Tabellen
Keine Ahnung was Du da zusammenfrickelst, die configDB benutzt jedenfalls nur 4 Tabellen.
Zitat von: betateilchen am 28 Juni 2020, 11:17:01
Keine Ahnung was Du da zusammenfrickelst, die configDB benutzt jedenfalls nur 4 Tabellen.
Da sind noch 2 Tabellen von DBLog dabei. Ob die nun im dump enthalten sind ist mir erstmal egal.
Sollten nicht die 4 Tabellen von configDB enthalten sein?
Edit: Diese Tabellen habe ich:
mysql> show tables;
+-----------------+
| Tables_in_fhem |
+-----------------+
| current |
| fhemb64filesave |
| fhemconfig |
| fhemstate |
| fhemversions |
| history |
+-----------------+
6 rows in set (0.01 sec)
Hier ein paar Auszüge aus fhemconfig:
mysql> select * from fhemconfig;
+----------+---------------------+------------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------+----------------------------------+
| COMMAND | DEVICE | P1 | P2 | VERSION | VERSIONUUID |
+----------+---------------------+------------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------+----------------------------------+
| #created | by | cfgDB_Init | NULL | 0 | c16989116e4470e1a3b8c13d5420ac04 |
| attr | global | logdir | ./log | 1 | c16989116e4470e1a3b8c13d5420ac04 |
| attr | global | logfile | %L/fhem-%Y-%m-%d.log | 2 | c16989116e4470e1a3b8c13d5420ac04 |
| attr | global | modpath | . | 3 | c16989116e4470e1a3b8c13d5420ac04 |
| attr | global | userattr | devStateIcon devStateStyle icon sortby webCmd | 4 | c16989116e4470e1a3b8c13d5420ac04 |
| attr | global | verbose | 3 | 5 | c16989116e4470e1a3b8c13d5420ac04 |
| define | telnetPort | telnet | 7072 global | 6 | c16989116e4470e1a3b8c13d5420ac04 |
| define | web | FHEMWEB | 8083 global | 7 | c16989116e4470e1a3b8c13d5420ac04 |
| attr | web | allowfrom | .* | 8 | c16989116e4470e1a3b8c13d5420ac04 |
| define | Logfile | FileLog | %L/fhem-%Y-%m-%d.log FakeLog | 9 | c16989116e4470e1a3b8c13d5420ac04 |
| attr | global | userattr | cmdIcon devStateIcon devStateIcon:textField-long devStateStyle icon sortby webCmd webCmdLabel:textField-long widgetOverride | 0 | 5eb3ffb63617b22a142358c4475aedb8 |
| attr | global | logdir | ./log | 1 | 5eb3ffb63617b22a142358c4475aedb8 |
| attr | global | logfile | %L/fhem-%Y-%m-%d.log | 2 | 5eb3ffb63617b22a142358c4475aedb8 |
Das heißt, Du hast sowohl die Tabellen von DbLog als auch die Tabellen von configDB in einer einzigen Datenbank?
Das ist ein Vorgehen, von dem regelmäßig abgeraten wird. Warum? Erlebst Du gerade...
Zitat von: betateilchen am 28 Juni 2020, 16:33:42
Das heißt, Du hast sowohl die Tabellen von DbLog als auch die Tabellen von configDB in einer einzigen Datenbank?
Das ist ein Vorgehen, von dem regelmäßig abgeraten wird. Warum? Erlebst Du gerade...
Hatte ich ja. Habe jetzt eine neue Datenbank nur für die config angelegt. Es sind jetzt nur die 4 Tabellen, trotzdem ist der dump quasi leer:
-- MySQL dump 10.13 Distrib 8.0.20, for Linux (x86_64)
--
-- Host: 192.168.178.15 Database: fhem-config
-- ------------------------------------------------------
-- Server version 5.5.5-10.4.12-MariaDB-1:10.4.12+maria~bionic
/*!40101 SET @OLD_CHARACTER_SET_CLIENT=@@CHARACTER_SET_CLIENT */;
/*!40101 SET @OLD_CHARACTER_SET_RESULTS=@@CHARACTER_SET_RESULTS */;
/*!40101 SET @OLD_COLLATION_CONNECTION=@@COLLATION_CONNECTION */;
/*!50503 SET NAMES utf8mb4 */;
/*!40103 SET @OLD_TIME_ZONE=@@TIME_ZONE */;
/*!40103 SET TIME_ZONE='+00:00' */;
/*!40014 SET @OLD_UNIQUE_CHECKS=@@UNIQUE_CHECKS, UNIQUE_CHECKS=0 */;
/*!40014 SET @OLD_FOREIGN_KEY_CHECKS=@@FOREIGN_KEY_CHECKS, FOREIGN_KEY_CHECKS=0 */;
/*!40101 SET @OLD_SQL_MODE=@@SQL_MODE, SQL_MODE='NO_AUTO_VALUE_ON_ZERO' */;
/*!40111 SET @OLD_SQL_NOTES=@@SQL_NOTES, SQL_NOTES=0 */;
--
-- Table structure for table `fhemversions`
--
DROP TABLE IF EXISTS `fhemversions`;
/*!40101 SET @saved_cs_client = @@character_set_client */;
/*!50503 SET character_set_client = utf8mb4 */;
CREATE TABLE `fhemversions` (
`VERSION` int(11) DEFAULT NULL,
`VERSIONUUID` char(50) COLLATE utf8_bin DEFAULT NULL
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_bin;
/*!40101 SET character_set_client = @saved_cs_client */;
--
-- Dumping data for table `fhemversions`
--
LOCK TABLES `fhemversions` WRITE;
/*!40000 ALTER TABLE `fhemversions` DISABLE KEYS */;
INSERT INTO `fhemversions` VALUES (2,'0387423d62b9581dc868891d99cf5a56'),(1,'334ff02cc718bd67740d9eef6c1ccbff'),(0,'8d76880488f552aaf801b0b1458a8d04');
/*!40000 ALTER TABLE `fhemversions` ENABLE KEYS */;
UNLOCK TABLES;
Muss noch etwas beachtet werden, wenn der DB Host auf einem anderen Server läuft?
Ich konnte es nun herausfinden. Der Server hat mit diesem Befehl das gleiche Ergebnis erhalten:
mysqldump -h 192.168.178.15 -P 33061 --user=fhemuser --password=fhempassword -Q fhem-config > /home/tim/dump.sql
Als Output ist das erschienen
mysqldump: [Warning] Using a password on the command line interface can be insecure.
mysqldump: Couldn't execute 'SELECT COLUMN_NAME, JSON_EXTRACT(HISTOGRAM, '$."number-of-buckets-specified"') FROM information_schema.COLUMN_STATISTICS WHERE SCHEMA_NAME = 'fhem-config' AND TABLE_NAME = 'fhemb64filesave';': Unknown table 'COLUMN_STATISTICS' in information_schema (1109)
Mit diesem Zusatz --column-statistics=0 sind nun die Daten in dem dump
mysqldump -h 192.168.178.15 -P 33061 --user=fhemuser --password=fhempassword --column-statistics=0 -Q fhem-config > /home/tim/dump.sql
Output ist nun nur noch das Warning.
Gefunden habe ich es hier:
https://serverfault.com/questions/912162/mysqldump-throws-unknown-table-column-statistics-in-information-schema-1109
Gibt es die Möglichkeit es in das Modul mit einzubauen?
Du kannst das auch in deiner my.cnf Datei standardmässig deaktivieren:
[mysqldump]
column-statistics=0
Zitat von: amenomade am 29 Juni 2020, 02:06:32
Du kannst das auch in deiner my.cnf Datei standardmässig deaktivieren:
[mysqldump]
column-statistics=0
Du meinst das ist die /etc/mysql/my.cnf auf dem DB Server eintragen?
Das habe ich gemacht, erhalte jedoch das gleiche Ergebnis.
Ich weiss nicht genau, wie Du dein MySQL konfiguriert hast, aber eher auf dem Client Server, der mysqldump startet, und diese Option braucht. In dem Fall der Fhem Server.
Im Home-Verzeichnis von FHEM
Zitat von: Wernieman am 29 Juni 2020, 17:13:35
Im Home-Verzeichnis von FHEM
Dann aber mit einem Punkt vor dem Dateiname:
.my.cnfDas wäre wenn man das User-spezifisch will, und zwar nur für den User "fhem".
/etc/my.cnf bzw /etc/mysql/my.cnf geht aber auch. Dann System weit.
Doku:
ZitatTable 4.2 Option Files Read on Unix and Unix-Like Systems
File Name Purpose
--------------------------------------------------------
/etc/my.cnf Global options
/etc/mysql/my.cnf Global options
SYSCONFDIR/my.cnf Global options
defaults-extra-file The file specified with --defaults-extra-file, if any
~/.my.cnf User-specific options
~/.mylogin.cnf User-specific login path options (clients only)
configdb attr mysqldump --column-statistics=0
Ab dem morgigen Update.
Ich hatte folgendes in die Datei hinzugefügt /etc/mysql/my.cnf
[mysqldump]
column-statistics=0
Hat super funktioniert.
Zitat von: betateilchen am 29 Juni 2020, 18:47:10
configdb attr mysqldump --column-statistics=0
Ab dem morgigen Update.
Vielen Dank. Werde ich testen.
Man könnte den dump natürlich auch einfach per cronjob auf Betriebssystemebene ausführen, dann kann man Parameter angeben, soviele man will.
Zitat von: betateilchen am 29 Juni 2020, 19:04:07
Man könnte den dump natürlich auch einfach per cronjob auf Betriebssystemebene ausführen, dann kann man Parameter angeben, soviele man will.
Habe das jetzt so ein einem at gelöst
{system ('sudo mysqldump -h 192.168.178.15 -P 33061 --user=fhemuser --password=fhempassword --column-statistics=0 -Q fhem-config > /backup/dump_`date +"%Y-%m-%d_%H-%M-%S"`.sql')}Muss das Zielverzeichnis zwingend chmod 777 haben?
?? Das hat aber wenig Sinn, über ein at mit einem Systembefehl, das Dump zu machen, wenn es das Kommando in Fhem gibt!
- Entweder machst Du es auf Fhem-Ebene, dann ein at mit configdb dump (betateilchen hat dir sogar das configdb attr für zusätzliche mysqldump Parameter entwickelt)
- Oder Du machst es auf System-Ebene, dann ein cronjob in deiner crontab, wie er geschrieben hat
Aber dein jetziges Konstrukt... :o :o ???
Zu deine Frage:
ZitatMuss das Zielverzeichnis zwingend chmod 777 haben?
Nein, da Du sudo benutzt. Aber damit dein Konstrukt funktionieren kann, muss der fhem User sudoer sein (und bitte nicht mit ALL=(ALL) NOPASSWD:ALL ), und vermutlich noch ein shell haben.
Meine Empfehlung, wenn Du nicht wirklich davon weisst: keep it simple. Nach einem update ab 8 Uhr heute:
configdb attr mysqldump --column-statistics=0
define <name> at <timespec> configdb dumpund Schluß.
PS: falls Du doch weiter aussehalb Fhem dein Backup der DB machen willst und Hilfe brauchst, dann vielleicht in einem anderen Thread, da es gar nichts mehr mit configb dump zu tun hat.
Zitat von: amenomade am 30 Juni 2020, 02:31:33
Das hat aber wenig Sinn, über ein at mit einem Systembefehl, das Dump zu machen, wenn es das Kommando in Fhem gibt!
Naja, der Befehlt "configdb dump" macht auch nix anderes, als einen Befehl zusammenzubauen und an das Betriebssystem zu übergeben. Insofern ist es egal.
Damit wir uns hier nun nicht weiter verzetteln, mache ich den Thread vorläufig mal zu.