Hi,
Heute Mittag hatten wir Stromausfall.
Dannach kam der mySQL nicht mehr hoch.
Durch [mysqld]innodb_force_recovery = 4 in der my.ini war er wieder gestartet, hat aber 100% CPU Last. Dies auch über Stunden hinweg.
LogDB in fhem (unter Raspbian) meldet mir
DBD::mysql::st execute_array failed: Table 'history' is read only [err was 1036 now 2000000000]
Gibt es hier ein "best practice" um den mySQL wieder zum Leben zu erwecken?
ein "check" unter dem mySQL Admin hat ihn wieder crashen lassen.
zur Not habe ich ein Backup von ca 03:00 heute Nacht.
Es gibt bestimmt verschiedene Wege.
Aber ich würde in dieser Situation den Restore wählen.
Zunächst LogDB auf asynchron setzen, falls noch nicht passiert und dann "reopen = 86400". Damit ist die DB für einen Tag weg vom FHEM, die Events laufen in der Zeit im Speicher auf (vorausgesetzt du hast genügend).
Dann den Restore durchführen. Kommt jetzt darauf an wie er erstellt wurde.
Wenn fertig -> set ... reopen.
Wenn alles sauber läuft werden die Events nachgefahren und alles ist wieder schick.
Grüße,
Heiko
Zitat von: DS_Starter am 17 Oktober 2019, 20:49:17
Es gibt bestimmt verschiedene Wege.
Aber ich würde in dieser Situation den Restore wählen.
Zunächst LogDB auf asynchron setzen, falls noch nicht passiert und dann "reopen = 86400". Damit ist die DB für einen Tag weg vom FHEM, die Events laufen in der Zeit im Speicher auf (vorausgesetzt du hast genügend).
Dann den Restore durchführen. Kommt jetzt darauf an wie er erstellt wurde.
Wenn fertig -> set ... reopen.
Wenn alles sauber läuft werden die Events nachgefahren und alles ist wieder schick.
danke Heiko,
async stehen alle Instanzen. den Reopen 86400 setzt ich gleich mal ab.
Die Backups mache ich aus FHEM heraus mit
set logdb_DbRep dumpMySQL serverSideDie DB ist ja jetzt readonly. Wie bekomme ich denn da das Backup am besten rein?
bekomm ich das auch im mySQL Admin unter Windows hin?
Habe selbst nichts gefunden um den readonly zu entfernen.
Es ist ja "nur" die Tabelle history readonly. Sollte ein einfaches Restore
set logdb_DbRep restoreMySQL
funktionieren. Auswahl des Files über die Dropdown.
Bevor du restorest könntest du noch ein
mysql> REPAIR TABLE history;
auf Betriebssystemebene oder deinem SQL-Client probieren. REPAIR habe ich leider noch nicht im DbRep drin. -> nehme ich auf die ToDo.
Habe nochwas gefunden. Wenn nach dem REPAIR noch writeonly kommt, kannst auch noch die permissions der files checken
If you're still getting "read only" messages, check the file permissions in /var/lib/mysql/dbname/tbl_name (assuming your database is in /var/lib/mysql).
# ls -alh /var/lib/mysql/dbname/
total 209M
drwx------ 2 mysql mysql 16K Jul 20 10:42 .
drwxr-xr-x 187 mysql mysql 4.0K Jul 11 12:22 ..
-rw-r--r-- 1 root root 1.0K Jun 28 06:14 tbl_name.MYI
-rw-r--r-- 1 root root 8.4K Jun 28 06:14 tbl_name.frm
The files should be owned by "mysql" with the group "mysql", if your MySQL is running as the mysql user. Stop the MySQL daemon, change the ownership and restart your MySQL.
# /etc/init.d/mysqld stop
Stopping MySQL: [ OK ]
# chown mysql.mysql /var/lib/mysql/dbname/*
# /etc/init.d/mysqld start
Starting MySQL: [ OK ]
Ach Unsinn ... du bist doch auf Windows :o
"The storage engine for this table doesn't support repair"
"errortext DBD::mysql::st execute failed: Table 'history' is read only at ./FHEM/93_DbRep.pm line 7845"
muss erst den readonly raus bekommen. wo kann der denn versteckt sein?
ohne innodb_force_recovery = 4 fährt der mySQL auch gar nicht hoch.
Geht denn ein
mysql -u root --password
use <deine DB>
mysql> DROP TABLE history;
Zitat von: DS_Starter am 17 Oktober 2019, 21:24:24
Geht denn ein
mysql -u root --password
use <deine DB>
mysql> DROP TABLE history;
nein. :(
mysql> use fhem;
Database changed
mysql> DROP TABLE history;
ERROR 1036 (HY000): Table 'tablespace_files' is read only
mysql>
Das readonly ist drin, weil das recovery noch läuft.
Geh erstmal ins Bett und warte bis morgen, das recovery kann durchaus sehr lang dauern.
Wieviele Daten sind denn drin? (wie groß ist das dumpfile?)
Eine Info würde mich noch interessieren. Was sagt denn ein:
set logdb_DbRep sqlCmd SELECT @@global.read_only;
Zitat von: bartman121 am 17 Oktober 2019, 21:29:57
Das readonly ist drin, weil das recovery noch läuft.
Geh erstmal ins Bett und warte bis morgen, das recovery kann durchaus sehr lang dauern.
Wieviele Daten sind denn drin? (wie groß ist das dumpfile?)
das dumpfile hat 1,87GB.
sehe ich das irgendwo dass der recovery läuft?
Alles was ich sehe ist die CPU Last.
Zitatsehe ich das irgendwo dass der recovery läuft?
Möglicherweise im DbRep mit
get ... procinfo
Zitat von: Frank_Huber am 17 Oktober 2019, 21:35:51
das dumpfile hat 1,87GB.
sehe ich das irgendwo dass der recovery läuft?
Alles was ich sehe ist die CPU Last.
Die knapp 2GB werden sicher viele Stunden recovery verursachen.
Keine Ahnung ob man das recovery irgendwo sieht... Guck dich im mysql admin ein bissl um. Ich denke aber das Problem löst sich von selbst, wenn das recovery durch ist.
BTW... Du solltest dein logging einschränken, so viele Daten braucht man doch nicht wirklich.
Zitat von: DS_Starter am 17 Oktober 2019, 21:34:50
Eine Info würde mich noch interessieren. Was sagt denn ein:
set logdb_DbRep sqlCmd SELECT @@global.read_only;
sqlCmd SELECT @@global.read_only 2019-10-17 21:38:28
sqlResultNumRows 1 2019-10-17 21:38:28
Wo sehe ich denn das Ergebnis?mysql> SELECT @@global.read_only;
+--------------------+
| @@global.read_only |
+--------------------+
| 0 |
+--------------------+
1 row in set (0.00 sec)
mysql>
Zitat von: DS_Starter am 17 Oktober 2019, 21:38:05
Möglicherweise im DbRep mit
get ... procinfo
ID USER HOST DB CMD TIME_Sec STATE INFO PROGRESS
4 event_scheduler localhost Daemon 356 Waiting on empty queue 18 fhemuser FHEM-PI-KG:54648 fhem Sleep 73
22 fhemuser FHEM-PI-KG:54710 fhem Query 0 starting show full processlist
sqlResultNumRows 1
ist das Ergebnis. Dort steht im Normalfall 0.
EDIT bei mir:
2019-10-17 21:47:26 SqlResultRow_1 0
Zitat von: bartman121 am 17 Oktober 2019, 21:38:40
Die knapp 2GB werden sicher viele Stunden recovery verursachen.
Keine Ahnung ob man das recovery irgendwo sieht... Guck dich im mysql admin ein bissl um. Ich denke aber das Problem löst sich von selbst, wenn das recovery durch ist.
BTW... Du solltest dein logging einschränken, so viele Daten braucht man doch nicht wirklich.
Danke, dann lass ich das mal rennen und schau was passiert.
Ja, das bereinigen der Historie steht noch auf der Liste.
Hab erst "vor kurzem" alles auf einen zentralen mySQL umgezogen und noch nicht die ganze to do abgearbeitet.
sind aktuell so um die 22Mio Einträge.
Hab das noch nicht angegangen weil die DB auch stabil und gut funktioniert. selbst der dump ist in unter 2 min durch. Aber ja, das muss jetzt dann wohl sein.
Ja dann schau mal. :)
Schau aber auch mal ins errorlog rein. Sollte das
/var/log/mysql/error.log
sein.
Ich habe jetzt nochmal in Ruhe gesucht.
Der Read-only mode kommt m.M. nach allein durch dein Setzen von innodb_force_recovery = 4
Zitat
...
As a safety measure, InnoDB prevents INSERT , UPDATE , or DELETE operations when innodb_force_recovery is greater than 0. An innodb_force_recovery setting of 4 or greater places InnoDB in read-only mode.
..
A value of 4 or greater is considered dangerous because data files can be permanently corrupted.
...
Vermutlich wirst du nicht drumherum kommen die DB aus dem Backup neu aufzubauen. Sollte die Situation nicht besser werden, versuche mit innodb_force_recovery < 4 zu starten und die Datenbank zu löschen. Danach kann man sie wieder neu erzeugen und aus dem Backup die history wieder herstellen.
Na mal schauen ....
Zitat von: DS_Starter am 17 Oktober 2019, 22:13:24
Schau aber auch mal ins errorlog rein. Sollte das
/var/log/mysql/error.log
sein.
In Windows ist es:
C:\ProgramData\MySQL\MySQL Server 8.0\Data\SERVERNAME.err
Die letzten Zeilen hab ich mal als txt angehängt. für den Coder Tag ist es zu viel.
Interessant ist:
2019-10-17T22:01:39.541798Z 40 [ERROR] [MY-011906] [InnoDB] Database page corruption on disk or a failed file read of page [page id: space=73, page number=199556]. You may have to recover from a backup.
...
...
InnoDB: End of page dump
InnoDB: Page may be an index page where index id is 247Ist hier womöglich "nur" der Index futsch?
Aber auch den kann ich ja nicht löschen im readonly.
CPU ist übrigens noch an Anschlag.
mit recover 2 kam der server nicht hoch, daher bin ich dann auf 4 und er startete.
Ich geb ihm jetzt mal noch bis Mittag, dannach werd ich schauen dass ich die DB irgendwie vom Restore bekomme.
Danke & Grüße
Frank
Morgen Frank,
ich gehe davon aus dass eine dauerhafte Schädigung vorliegt. Da würde ich auch nicht lange rummmachen, die DB löschen, eine neu anlegen, die Tabellen mit dem Script neu erzeugen und die history aus dem Backup herstellen.
Du musst vorher die Tabellen anlegen !
Das serverside backup erzeugt die Tabellenstruktur nicht selbst.
Grüße,
Heiko
Danke Heiko,
Denke auch dass da nix zu retten ist.
--> mySQL stoppen,
--> Dateien löschen
--> recovery Zeile wieder auskommentieren
--> mySQL starten
--> Datenbank und Tabellen anlegen
--> restore aus FHEM anstossen
wäre das der richtige Weg?
Ja, sollte so klappen. Aber lies vorher nochmal im Netz ob ein einfaches löschen der Dateien korrekt ist. So einen drastischen Fall hatte ich auch noch nicht. Bin jetzt erstmal paar stunden nicht da ... :(
Vllt kannst du mit innodb_force_recovery = 3 starten. Dann wäre die tab nicht read only und du könntest mit drop etc. Arbeiten.
So,
mit Rescovery=3 ist er immer nach paar Sekunden gecrasht.
Nach einigen Versuchen hab ich es aber geschafft zwischen start und crash die Tabelle zu droppen.
Neu angelegt der Tabelle und des Index anhand der Zeilen aus dem Contrib.
Jetzt läuft der Restore.
Hab vor dem Restore noch nen dump gemacht.
Mal schauen ob ich da noch ein paar Zeilen retten kann.
kurz zum restore, überschreibt der "alles" oder fügt er hinzu?
Dieser Restoretyp aus dem serverside Backup fügt hinzu, wobei Duplikate vermieden werden sofern ein primary Key gesetzt ist. Bei dir war die Tabelle jetzt leer, also nicht so relevant.
Was macht dein cache vom DbLog ? Im Reading cacheUsage dürften schon allerhand drinstehen. Setz dir dort auch noch das Attr bulkInsert 1. Das ist für die Performance wenn nachher die ganzen Events in die DB sollen.
BTW... wenn du in einem ANDEREN DbRep Device ein get ... procinfo ausführst, solltest du den restore und den Fortschritt sehen.
Die gecachten Ereignisse sind sauber übertragen worden. Das waren je nach Instanz glaub zwischen 1000 und 8000.
Der Restore lief auch sauber durch.
Dann kuck icjh jetzt mal nach dem primary key, falls der da ist kann ich ja den dump vor dem drop restoren,
dadurch müssten ja alle Einträge von gestern nach dem nächtlichen backup bis zum crash nachgezogen werden.
Das mit dem procinfo während dem restore schau ich mir an, das klingt interessant. ;)
Die indexe zeigt dir dbrep mit set ... index list_all an.
wenn der PK nicht da ist, wäre es auch nicht dramatisch. dbrep mit delDoublets bereinigt das wieder. Dauert halt alles etwas.
Aber jetzt vllt. zuerst einen neuen Dump ziehen ;)
Zitat von: DS_Starter am 18 Oktober 2019, 12:39:57
Aber jetzt vllt. zuerst einen neuen Dump ziehen ;)
Das war das erste nach dem Restore. :-)
den PK anlegen hat er mir schon verweigert wegen der doubletten.
Werd also erstmal den DelDoubl laufen lassen.
Ich sehe du kommst klar 8)
Nur mal für mich aus Interesse ... das war ja nun doch eine besondere Situation. Wie hat sich FHEM verhalten , lief alles normal weiter wie es sein soll ?
schön wäre es gewesen. ;o)
set logdb_DbRep delDoublets delete
ergibt:
DBD::mysql::st execute failed: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'ASC HAVING count(*) > 1' at line 1 at ./FHEM/93_DbRep.pm line 5043.
Zitat von: DS_Starter am 18 Oktober 2019, 13:05:57
Ich sehe du kommst klar 8)
Nur mal für mich aus Interesse ... das war ja nun doch eine besondere Situation. Wie hat sich FHEM verhalten , lief alles normal weiter wie es sein soll ?
FHEM lief soweit, ausser Ich hab nen Raum aufgerufen mit Plots. Dann hing FHEM so ne halbe bis dreiviertel Stunde komplett. War also blockiert.
Gibts nicht, da muss ich etwas tun und dbrep patchen, ging doch bisher :o. Ich korrigiere das.
Dann bereinigen wir die Doubletten etwas später.
Hast du plotfork 1 im Fhemweb gesetzt ? Dann sollte es nämlich auch bei den Plots keine Blockierungszustände geben.
plotfork muss ich schauen. kanns sein dass der nicht gesetzt ist.
Brauchst Du noch irgendwelche Versionen von mir wegen dem delDoubl?
EDIT:
plotfork war auf "2", hatte wohl früher mal eine andere Bedeutung. Wird gleich überall auf "1" umgestellt.
Hab auch grad noch "nebenher" entdeckt dass ich noch nen Fehler im exclude/include einiger Geräte hatte.
über Jahre von 2 HM Strommesssteckdosen das "energyKWh" Reading geloggt. und das kam paarmal die Minute.
Bin mal gespannt wieviele Einträge der SELECT findet. *lach*
Meine Versionen:
93_DbLog.pm 20114 2019-09-06 11:21:03Z DS_Starter --> 93_DbLog.pm:v4.7.0-s20114/2019-09-06
93_DbRep.pm 20263 2019-09-27 20:37:25Z DS_Starter --> 93_DbRep.pm:v8.27.2-s20263/2019-09-27
Habe delDoubl gerade bei mir ausgeführt. Läuft ohne Fehler DbRep version 8.28.1
DbRep solltest du updaten.
Zitat von: DS_Starter am 18 Oktober 2019, 13:43:24
DbRep solltest du updaten.
Nach Update und restart das selbe:
DBD::mysql::st execute failed: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'ASC HAVING count(*) > 1' at line 1 at ./FHEM/93_DbRep.pm line 5054.
Das wundert mich allerdings weil bei mir mit MariaDB ist es ok.
Mach mir mal ein verbose 4 von dem Befehl und ich schaue mir das heute Abend an. Finde ich etwas komisch.
Version ist jetzt auch gleiche wie meine ?
ja, 8.28.1.
2019.10.18 13:58:19 3: DbRep logdb_DbRep - execute command before delDoublets: 'set logdb reopen 3600'
2019.10.18 13:58:19 2: DbLog logdb: Connection closed until 14:58:19 (3600 seconds).
2019.10.18 13:58:19 4: DbLog logdb -> ################################################################
2019.10.18 13:58:19 4: DbLog logdb -> ### start of new Logcycle ###
2019.10.18 13:58:19 4: DbLog logdb -> ################################################################
2019.10.18 13:58:19 4: DbLog logdb -> number of events received: 1 for device: logdb
2019.10.18 13:58:19 4: DbLog logdb -> check Device: logdb , Event: state: closed until 14:58:19 (3600 seconds)
2019.10.18 13:58:19 4: DbLog logdb -> ################################################################
2019.10.18 13:58:19 4: DbLog logdb -> ### start of new Logcycle ###
2019.10.18 13:58:19 4: DbLog logdb -> ################################################################
2019.10.18 13:58:19 4: DbLog logdb -> number of events received: 1 for device: logdb_DbRep
2019.10.18 13:58:19 4: DbLog logdb -> check Device: logdb_DbRep , Event: state: running
2019.10.18 13:58:19 4: DbRep logdb_DbRep - -------- New selection ---------
2019.10.18 13:58:19 4: DbRep logdb_DbRep - Command: delDoublets adviceDelete
2019.10.18 13:58:19 4: DbRep logdb_DbRep - Timestamp begin human readable: 2016-10-16 12:57:19
2019.10.18 13:58:19 4: DbRep logdb_DbRep - Timestamp end human readable: 2019-10-18 13:58:19
2019.10.18 13:58:19 4: DbRep logdb_DbRep - Aggregation: day
2019.10.18 13:58:19 4: DbRep logdb_DbRep - SQL execute: SELECT TIMESTAMP,DEVICE,READING,VALUE,count(*) FROM history where TIMESTAMP >= '2016-10-16 12:57:19' AND TIMESTAMP < '2016-10-17' GROUP BY TIMESTAMP, DEVICE, READING, VALUE ASC HAVING count(*) > 1;
2019.10.18 13:58:19 2: DbRep logdb_DbRep - DBD::mysql::st execute failed: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'ASC HAVING count(*) > 1' at line 1 at ./FHEM/93_DbRep.pm line 5054.
2019.10.18 13:58:19 4: DbLog logdb -> ################################################################
2019.10.18 13:58:19 4: DbLog logdb -> ### start of new Logcycle ###
2019.10.18 13:58:19 4: DbLog logdb -> ################################################################
2019.10.18 13:58:19 4: DbLog logdb -> number of events received: 1 for device: logdb_DbRep
2019.10.18 13:58:19 4: DbLog logdb -> check Device: logdb_DbRep , Event: errortext: DBD::mysql::st execute failed: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'ASC HAVING count(*) > 1' at line 1 at ./FHEM/93_DbRep.pm line 5054.
2019.10.18 13:58:19 4: DbLog logdb -> ################################################################
2019.10.18 13:58:19 4: DbLog logdb -> ### start of new Logcycle ###
2019.10.18 13:58:19 4: DbLog logdb -> ################################################################
2019.10.18 13:58:19 4: DbLog logdb -> number of events received: 1 for device: logdb_DbRep
2019.10.18 13:58:19 4: DbLog logdb -> check Device: logdb_DbRep , Event: state: error
Die Zeiteigrenzung sieht etwas merkwürdig aus. Wie stehen denn deine Attribute im DbRep ?
Zitat von: DS_Starter am 18 Oktober 2019, 14:08:06
Die Zeiteigrenzung sieht etwas merkwürdig aus. Wie stehen denn deine Attribute im DbRep ?
Das dürfte der erste Tag der DB sein. von daher denke ich passt das.
Attribute:
defmod logdb_DbRep DbRep logdb
attr logdb_DbRep DbLogExclude .*
attr logdb_DbRep allowDeletion 1
attr logdb_DbRep executeAfterProc set logdb reopen
attr logdb_DbRep executeBeforeProc set logdb reopen 3600
attr logdb_DbRep group MySQL
attr logdb_DbRep room SYSTEM
attr logdb_DbRep verbose 4
Ja das passt, ich habe mich verwirren lassen. Hier zum Vergleich bei mir
2019.10.18 14:19:58.293 4: DbRep Rep.LogDB.All - SQL execute: SELECT TIMESTAMP,DEVICE,READING,VALUE,count(*) FROM history where TIMESTAMP >= '2019-10-16 14:19:57' AND TIMESTAMP < '2019-10-17' GROUP BY TIMESTAMP, DEVICE, READING, VALUE ASC HAVING count(*) > 1;
2019.10.18 14:19:58.699 4: DbRep Rep.LogDB.All - SQL execute: SELECT TIMESTAMP,DEVICE,READING,VALUE,count(*) FROM history where TIMESTAMP >= '2019-10-17' AND TIMESTAMP < '2019-10-18' GROUP BY TIMESTAMP, DEVICE, READING, VALUE ASC HAVING count(*) > 1;
Das läuft und ich sehe keine Unterschied in der Syntax. Gib mir mal noch deine Mysql version. Irgendwas muss ja sein.
Zitat von: DS_Starter am 18 Oktober 2019, 14:24:07
Gib mir mal noch deine Mysql version. Irgendwas muss ja sein.
8.0.14 spuckt er mir aus. (MySQL Community Server - GPL)
Ok, müssen wir mal forschen ob diese Version nicht mit ASC HAVING. arbeiten kann.
Melde mich wieder dazu.
eine erste Google Suche führt mich hierzu:
https://stackoverflow.com/questions/55395456/syntax-error-with-asc-desc-with-mysql-8-0
ZitatYou should read dev.mysql.com/doc/refman/8.0/en/... sepecifically - Incompatible change: As of MySQL 8.0.13, the deprecated ASC or DESC qualifiers for GROUP BY clauses have been removed. Queries that previously relied on GROUP BY sorting may produce results that differ from previous MySQL versions. To produce a given sort order, provide an ORDER BY clause
Na das ist es doch schon, danke dir ! Jetzt muss ich es heute Abend nur so umbauen dass es auch für MariaDB etc. noch passt.
Aber das sollte zu schaffen sein. :)
Ich werde es dann gerne für mySQL testen. ;)
Hallo Frank,
habe bereits angepasst und eine Version ins contrib geladen. Kannst du downloaden im FHEMWEB mit (inkl. "")
"wget -qO ./FHEM/93_DbRep.pm https://svn.fhem.de/fhem/trunk/fhem/contrib/DS_Starter/93_DbRep.pm"
Bei mir habe ich es mit MariaDB, SQLite und Postgre getestet. Fehlt nur dein MySQL. ;)
Grüße,
Heiko
Zitat von: DS_Starter am 18 Oktober 2019, 16:14:48
Hallo Frank,
habe bereits angepasst und eine Version ins contrib geladen. Kannst du downloaden im FHEMWEB mit (inkl. "")
"wget -qO ./FHEM/93_DbRep.pm https://svn.fhem.de/fhem/trunk/fhem/contrib/DS_Starter/93_DbRep.pm"
Bei mir habe ich es mit MariaDB, SQLite und Postgre getestet. Fehlt nur dein MySQL. ;)
Grüße,
Heiko
state running 2019-10-18 16:52:30über "get procinfo" kann ich auch anhand des TIMESTAMP sehen wie weit er ist. :-)
EDIT:
lief durch, aber wie interpretiere ich jetzt das Ergebnis?
In den Readings sind einige aufgelistet, hier finde ich aber keine Doubletten.
Oder wird nur der jeweils erste Eintrag angezeigt?EDIT2:
OK, eine SQL query hat es bestätigt, es wird der erste Eintrag angezeigt.
Sieht doch gut aus. Syntax passt jetzt demnach. Na dann lass es mal drüber laufen...
Die Idee mit get procinfo ist auch gut :)
Erster Durchlauf war erfolgreich.
PK anlegen hat aber nochmal Doubletten angemeckert.
Jetzt läuft er gerade nochmal.
EDIT:
lässt sich der "VALUE" ausklammern?
mysql> ALTER TABLE `history` ADD PRIMARY KEY(TIMESTAMP, DEVICE, READING);
ERROR 1062 (23000): Duplicate entry '2017-10-29 02:02:11-DG_Ost_Temp-temperature' for key 'PRIMARY'
mysql>
mysql>
mysql> select * from HISTORY where TIMESTAMP = "2017-10-29 02:02:11";
+---------------------+-------------+---------+----------------------+-------------+---------+------+
| TIMESTAMP | DEVICE | TYPE | EVENT | READING | VALUE | UNIT |
+---------------------+-------------+---------+----------------------+-------------+---------+------+
| 2017-10-29 02:02:11 | DG_Ost_Temp | OWTHERM | temperature: 21.6875 | temperature | 21.6875 | °C |
| 2017-10-29 02:02:11 | DG_Ost_Temp | OWTHERM | temperature: 21.5625 | temperature | 21.5625 | °C |
+---------------------+-------------+---------+----------------------+-------------+---------+------+
2 rows in set (0.00 sec)
mysql>
Oder ich mach das mal mit dem query manuell in der SQL Konsole.
SELECT TIMESTAMP,DEVICE,READING,count(*) FROM history GROUP BY TIMESTAMP, DEVICE, READING HAVING count(*) > 1 ORDER BY TIMESTAMP ASC;
läuft gerade. liefert 2498 Datensätze.
Ist die PK-Definition richtig ? Weil ich würde sagen diese beiden Datensätze sind keine Doublette -> der Wert ist unterschiedlich.
Bei einer echten Doublette ist Timestamp, Reading, Device und Wert identisch.
Wie wolltest du den PK denn anlegen ?
EDIT2: die Definition des PK ist richtig, aber wir kommen mit dem Doublettenbereinigen nicht zum Ziel weil ich die Datensätze nicht lösche wenn die VALUEs unterschiedlich sind.
Über timestamp reading und device.
So hab ich eine Empfehlung von dir im forum gefunden. [emoji6]
Kann ich nachher ab PC posten.
Ein Wert pro Sekunde reicht aber auch aus. Und feiner sind die timestamps ja eh nicht.
Btw, nach den freezes die wir heute morgen beredet hatten kamen viele Werte mit gleichem timestamp.
Wie läuft der del double denn dann weiter?
Kann ja auch "manuell" bereinigen, aber nicht 2k5 Einträge einzeln...
EDIT:
https://forum.fhem.de/index.php/topic,92762.msg853201.html#msg853201
Hier hatte ich es rausgeholt:
für history:
ALTER TABLE `history` ADD PRIMARY KEY(TIMESTAMP, DEVICE, READING);
Ja, hatte mich schon verbessert ... bin auch schon betriebsblind.
Weißt du, jetzt haben wir uns das Leben bisschen schwer gemacht. Als die history leer war hätten wir einfach nur den PK vor dem ersten Import anlegen müssen. Dann hätte die DB alles allein gemacht.
Wenn das jetzt zu aufwändig wird, mache einfach folgendes:
- DbLog schließen -> reopen 86400
- Dump ziehen
- history Inhalt löschen - delete from history;
- den PK anlegen wie du es gemacht hast
- restore wie gehabt
Damit ist das Doublets Problem erledigt.
Zitat von: DS_Starter am 18 Oktober 2019, 19:59:31
Ja, hatte mich schon verbessert ... bin auch schon betriebsblind.
Weißt du, jetzt haben wir uns das Leben bisschen schwer gemacht. Als die history leer war hätten wir einfach nur den PK vor dem ersten Import anlegen müssen. Dann hätte die DB alles allein gemacht.
Wenn das jetzt zu aufwändig wird, mache einfach folgendes:
- DbLog schließen -> reopen 86400
- Dump ziehen
- history Inhalt löschen - delete from history;
- den PK anlegen wie du es gemacht hast
- restore wie gehabt
Damit ist das Doublets Problem erledigt.
bäääääm, das ist die Lösung. :-)
Nur muss ich den reopen 86400 mehrfach machen. 1 x pro Instanz. :)
und los gehts.
Edit1
Ohje, der delete from history; läuft ewig. Ein drop und neu anlegen wär schneller gewesen. [emoji6]
Abwarten... - - > 42min zum löschen.
ZitatOhje, der delete from history; läuft ewig.
Ach, ein truncate table history hätte es wohl zügig erledigt. :(
Drop n create. [emoji12]
Aber hinterher is man immer schlauer. [emoji6]
Hat ja funktioniert. Restore läuft.
Gesendet von meinem S60 mit Tapatalk
ZitatDrop n create.
PK auch nicht vergessen ? ;D
Uuuups. [emoji23][emoji23][emoji23][emoji23][emoji23]
Nee, is drin.
Gesendet von meinem S60 mit Tapatalk
Die neue DbRep Version habe ich eingecheckt und ist morgen früh im Update.
Durch dieses Aktion konnten wir gleich die Kompatibilität zur MySQL 8.13.0 und höher herstellen. ;)
LG,
Heiko
@Frank ... DANKE ! :) :)
Bis morgen ...
Zitat von: DS_Starter am 18 Oktober 2019, 23:14:01
@Frank ... DANKE ! :) :)
Bis morgen ...
Der Dank ist auf meiner Seite. [emoji6]
System läuft wieder und hat lediglich einen dreiviertel Tag Daten verloren.
Das sind aber nur Temperatur und Feuchte Daten.
Alle Verbrauchswerte sind da. [emoji1303]
Als Nebeneffekt noch die Datenbank optimiert und die Todo um zwei Punkte erweitert.
-Zyklisches Bereinigen
-anbinden der USV an FHEM.
Gesendet von meinem S60 mit Tapatalk
Gut gemacht ... Top ! 8)
schönes WE,
LG,
Heiko