Hintergrund:
Ich möchte alle meine Edomi Archivdaten nach InfluxDB migrieren. Bei dieser Migration möchte ich die Daten auch gleichzeitig "optimieren", also entsprechende InfluxDB Tags verwenden. (Ein 1:1 export von Edomi zu InfluxDB hilft mir dabei nicht.)
Problem:
Ich möchte in einem ersten Schritt ALLE meine jemals mit Edomi in Archive gespeicherten Daten exportieren/aufbereiten. Eine eigentliche Analyse/Bereinigung wäre dann mit InfluxDB geplant, da dort die Performance natürlich wesentlich besser für solche Tasks ist.
Aufgrund der Performance-Probleme habe ich vor 1-2 Jahren meine Edomi-Archive auf max. 3 Jahre begrenzt. Somit fehlen mir natürlich einige ältere Daten, die aber in älteren Edomi-Backups noch vorliegen sollten.
Ich spreche übrigens aktuell von 17 Mio. Datensätzen, was eine solche Migration (z.B. via CSV) schnell an ihre Grenzen bringt. (Aber das ist jetzt das kleinere Problem.)
Lösungsansatz:
Ich muss zuerst die Archivdaten aus früheren Edomi-Backups exportieren. Natürlich kommt es dabei zu zeitlichen Überschneidungen, was aber mittels dem Timestamp kein Problem sein sollte. Duplikate würde einfach ignoriert bzw. mit dem gleichen Inhalt überschrieben.
Ich könnte jetzt die älteren Edomi-Backups in einer VM importieren und dann dort ein SQLDUMP oder ein CSV-Export erstellen.
Meine Idee ist aber eher, die gewünschten MySQL-Tabellen direkt vom Edomi-Backup (was ja ein ZIP-File ist) rauszukopieren, ohne das komplette Edomi-Backup zu importieren.
Es handelt sich dabei um die folgenden 6 Dateien (im \var\lib\mysql\edomiLive\ Verzeichnis):
MySQL_Edomi_Archivtabellen.png
.frm ist die Tabellenstruktur, .MYD die eigentlichen Daten und .MYI der Index (den man im Notfall via Repair neu erzeugen könnte).
Ich habe im Internet gelesen, dass es technisch möglich ist, diese 3 Dateien (pro Tabelle) einfach in eine neue MySQL Datenbank zu kopieren und MySQL würde dann damit arbeiten können. So könnte ich recht schnell meine Backup Archivdaten importieren und dann z.B. als CSV exportieren. (Den CSV-Export würde ich dann wohl gestaffelt machen, damit die Anzahl Datensätze im normalen Bereich bleiben.)
Ich habe aber auch gelesen, dass dies nur funktioniert, wenn man die gleiche MySQL Version verwendet, mit der diese Dateien erzeugt wurden. (Ob dies jetzt bei diesen Tabellen auch eine Rolle spielt, kann ich nicht beurteilen.)
Da MySQL ja mit Edomi zusammen installiert wird, wollte ich mal wissen, welche MySQL-Versionen Edomi seit 2016 (oder wann es erstmals rauskam) verwendet. Aktuell ist es ja glaub MariaDB. Ich gehe mal davon aus, dass Christian über die 4-5 Jahre nicht viele MySQL Versionen verwendet hat und sich damit dieses Problem am Ende als gar kein Problem darstellen wird.
Natürlich kann ichs einfach mal probieren und sehe ja dann schnell, ob ältere .frm/.MYD Files in einer aktuellen MariaDB sauber funktionieren. (Es dient ja nur als Zwischenschritt für die Migration.)
Aber vielleicht weiss ja trotzdem jemand, wann Christian in Edomi die MySQL-Version jeweils angepasst hat. Kann mich nicht erinnern, dass dies in den Release-Notes drinstand.
Ich möchte alle meine Edomi Archivdaten nach InfluxDB migrieren. Bei dieser Migration möchte ich die Daten auch gleichzeitig "optimieren", also entsprechende InfluxDB Tags verwenden. (Ein 1:1 export von Edomi zu InfluxDB hilft mir dabei nicht.)
Problem:
Ich möchte in einem ersten Schritt ALLE meine jemals mit Edomi in Archive gespeicherten Daten exportieren/aufbereiten. Eine eigentliche Analyse/Bereinigung wäre dann mit InfluxDB geplant, da dort die Performance natürlich wesentlich besser für solche Tasks ist.
Aufgrund der Performance-Probleme habe ich vor 1-2 Jahren meine Edomi-Archive auf max. 3 Jahre begrenzt. Somit fehlen mir natürlich einige ältere Daten, die aber in älteren Edomi-Backups noch vorliegen sollten.
Ich spreche übrigens aktuell von 17 Mio. Datensätzen, was eine solche Migration (z.B. via CSV) schnell an ihre Grenzen bringt. (Aber das ist jetzt das kleinere Problem.)
Lösungsansatz:
Ich muss zuerst die Archivdaten aus früheren Edomi-Backups exportieren. Natürlich kommt es dabei zu zeitlichen Überschneidungen, was aber mittels dem Timestamp kein Problem sein sollte. Duplikate würde einfach ignoriert bzw. mit dem gleichen Inhalt überschrieben.
Ich könnte jetzt die älteren Edomi-Backups in einer VM importieren und dann dort ein SQLDUMP oder ein CSV-Export erstellen.
Meine Idee ist aber eher, die gewünschten MySQL-Tabellen direkt vom Edomi-Backup (was ja ein ZIP-File ist) rauszukopieren, ohne das komplette Edomi-Backup zu importieren.
Es handelt sich dabei um die folgenden 6 Dateien (im \var\lib\mysql\edomiLive\ Verzeichnis):
MySQL_Edomi_Archivtabellen.png
.frm ist die Tabellenstruktur, .MYD die eigentlichen Daten und .MYI der Index (den man im Notfall via Repair neu erzeugen könnte).
Ich habe im Internet gelesen, dass es technisch möglich ist, diese 3 Dateien (pro Tabelle) einfach in eine neue MySQL Datenbank zu kopieren und MySQL würde dann damit arbeiten können. So könnte ich recht schnell meine Backup Archivdaten importieren und dann z.B. als CSV exportieren. (Den CSV-Export würde ich dann wohl gestaffelt machen, damit die Anzahl Datensätze im normalen Bereich bleiben.)
Ich habe aber auch gelesen, dass dies nur funktioniert, wenn man die gleiche MySQL Version verwendet, mit der diese Dateien erzeugt wurden. (Ob dies jetzt bei diesen Tabellen auch eine Rolle spielt, kann ich nicht beurteilen.)
Da MySQL ja mit Edomi zusammen installiert wird, wollte ich mal wissen, welche MySQL-Versionen Edomi seit 2016 (oder wann es erstmals rauskam) verwendet. Aktuell ist es ja glaub MariaDB. Ich gehe mal davon aus, dass Christian über die 4-5 Jahre nicht viele MySQL Versionen verwendet hat und sich damit dieses Problem am Ende als gar kein Problem darstellen wird.
Natürlich kann ichs einfach mal probieren und sehe ja dann schnell, ob ältere .frm/.MYD Files in einer aktuellen MariaDB sauber funktionieren. (Es dient ja nur als Zwischenschritt für die Migration.)
Aber vielleicht weiss ja trotzdem jemand, wann Christian in Edomi die MySQL-Version jeweils angepasst hat. Kann mich nicht erinnern, dass dies in den Release-Notes drinstand.