Re: [vz-users] Datenbankportierung und neue Struktur
Ich bin nun mit der Brechstange vorgegangen und habe den mysqldump des Produktivsystems einfach über die DB der neuinstallierten Middleware "drübergebügelt". Nun habe ich die neue middleware mit alter DB-Struktur und VZlogger sendet seine Daten an die ausgelagerte middleware. Auch die täglichen inkrementellen Backups mit dbcopy laufen - logischerweise. Ich verstehe den Ansatz des Verzichts auf die fortlaufende ID. Das hätte ich aufgrund der Datenökonomie gerne gehabt. Aber ohne durchgehende Tool-Kette oder Doku/Anleitung ist das für den Laien nicht umsetzbar. Am Ende hängt es hier an der Inkompatibilität von dbcopy und neuer Struktur. Grüße Micha -Ursprüngliche Nachricht- Von: volkszaehler-users [mailto:volkszaehler-users-boun...@demo.volkszaehler.org] Im Auftrag von Jakob Hirsch Gesendet: Donnerstag, 29. Dezember 2022 02:15 An: volkszaehler-users@demo.volkszaehler.org Betreff: Re: [vz-users] Datenbankportierung und neue Struktur On 2022-12-26 11:55, Michael Hartmann wrote: > der Unterschied zwichen pk und copy ist klar. Nur das copy wie von mir und > Sven zuvor beschrieben lediglich die ersten 1000 Datensätze ins Backup > transferiert. Der "Fehler" geschieht bereits beim Sichern, wie aus der Größe > der Sicherungsdatei ersichtlich. Hm, ok, da wird wohl "batch size" nur einmal kopiert, obwohl das eigentlich schon vorgesehen ist, alles komplett zu kopieren. Problem ist m.E. Zeile 169 in CopyCommand.php, da wird auf $keyColumn geprüft (warum auch immer), das bei "copy" natürlich nicht gesetzt ist. Kannst du mal probieren, den Klammerausdruck komplett durch "true" zu ersetzen? (die Bedingung "sizeof($rows)" wird weiter oben schon geprüft...) > Deinem Quote aus dem Code folgend, braucht es eine Anpassung von dbcopy? Ja. Ist sicher kein Hexenwerk, aber auch kein one-liner. Und muß halt auch einigermaßen getestet werden. Wenn man das wirklich braucht, wäre es (zumindest vorübergehend) eine Alternative, das Schema wieder zu erweitern. Für data geht das z.B. so: alter table data add unique key `ch_ts` (`channel_id`,`timestamp`), drop primary key, add column id bigint not null auto_increment primary key first; Naja, kann verstehen, daß sich da nicht einfach jeder rantraut... > Irgendwie ist das ziemlich unglücklich mit der neuen DB-Struktur ohne > fortlaufende ID. Naja, ist m.E. schon besser (habe das auch schon eine Weile vorher so benutzt), der Rest muss dazu aber halt auch passen...
Re: [vz-users] Datenbankportierung und neue Struktur
On 2022-12-26 11:55, Michael Hartmann wrote: der Unterschied zwichen pk und copy ist klar. Nur das copy wie von mir und Sven zuvor beschrieben lediglich die ersten 1000 Datensätze ins Backup transferiert. Der "Fehler" geschieht bereits beim Sichern, wie aus der Größe der Sicherungsdatei ersichtlich. Hm, ok, da wird wohl "batch size" nur einmal kopiert, obwohl das eigentlich schon vorgesehen ist, alles komplett zu kopieren. Problem ist m.E. Zeile 169 in CopyCommand.php, da wird auf $keyColumn geprüft (warum auch immer), das bei "copy" natürlich nicht gesetzt ist. Kannst du mal probieren, den Klammerausdruck komplett durch "true" zu ersetzen? (die Bedingung "sizeof($rows)" wird weiter oben schon geprüft...) Deinem Quote aus dem Code folgend, braucht es eine Anpassung von dbcopy? Ja. Ist sicher kein Hexenwerk, aber auch kein one-liner. Und muß halt auch einigermaßen getestet werden. Wenn man das wirklich braucht, wäre es (zumindest vorübergehend) eine Alternative, das Schema wieder zu erweitern. Für data geht das z.B. so: alter table data add unique key `ch_ts` (`channel_id`,`timestamp`), drop primary key, add column id bigint not null auto_increment primary key first; Naja, kann verstehen, daß sich da nicht einfach jeder rantraut... Irgendwie ist das ziemlich unglücklich mit der neuen DB-Struktur ohne fortlaufende ID. Naja, ist m.E. schon besser (habe das auch schon eine Weile vorher so benutzt), der Rest muss dazu aber halt auch passen...
Re: [vz-users] Datenbankportierung und neue Struktur
Dazu bräuchte ich Unterstützung. Es geht um die Tabellen data, properties, aggregate, : Data alt: +++--+-+-++ | Field | Type | Null | Key | Default | Extra | +++--+-+-++ | id | int(11)| NO | PRI | NULL| auto_increment | | channel_id | int(11)| YES | MUL | NULL|| | timestamp | bigint(20) | NO | | NULL|| | value | double | NO | | NULL|| +++--+-+-++ Data neu: +++--+-+-+---+ | Field | Type | Null | Key | Default | Extra | +++--+-+-+---+ | timestamp | bigint(20) | NO | PRI | NULL| | | channel_id | int(11)| NO | PRI | NULL| | | value | double | NO | | NULL| | +++--+-+-+---+ Properties alt: +---+--+--+-+-++ | Field | Type | Null | Key | Default | Extra | +---+--+--+-+-++ | id| int(11) | NO | PRI | NULL| auto_increment | | entity_id | int(11) | YES | MUL | NULL|| | pkey | varchar(255) | NO | | NULL|| | value | longtext | NO | | NULL|| +---+--+--+-+-++lt: Neu: +---+--+--+-+-+---+ | Field | Type | Null | Key | Default | Extra | +---+--+--+-+-+---+ | pkey | varchar(255) | NO | PRI | NULL| | | entity_id | int(11) | NO | PRI | NULL| | | value | longtext | NO | | NULL| | +---+--+--+-+-+---+ Aggregate alt: ++-+--+-+-++ | Field | Type| Null | Key | Default | Extra | ++-+--+-+-++ | id | int(11) | NO | PRI | NULL| auto_increment | | channel_id | int(11) | YES | MUL | NULL|| | type | smallint(6) | NO | | NULL|| | timestamp | bigint(20) | NO | | NULL|| | value | double | NO | | NULL|| | count | int(11) | NO | | NULL|| ++-+--+-+-++ Neu: ++-+--+-+-+---+ | Field | Type| Null | Key | Default | Extra | ++-+--+-+-+---+ | type | smallint(6) | NO | PRI | NULL| | | timestamp | bigint(20) | NO | PRI | NULL| | | channel_id | int(11) | NO | PRI | NULL| | | value | double | NO | | NULL| | | count | int(11) | NO | | NULL| | ++-+--+-+-+---+ Auch bei den bestehenden Datenfeldern müssen einige Einstellungen zurückgeändert werden. Grüße Micha -Ursprüngliche Nachricht- Von: volkszaehler-users [mailto:volkszaehler-users-boun...@demo.volkszaehler.org] Im Auftrag von Daniel Lauckner Gesendet: Dienstag, 27. Dezember 2022 17:12 An: volkszaehler.org - users Betreff: Re: [vz-users] Datenbankportierung und neue Struktur Hallo, am Dienstag, 27. Dezember 2022 um 16:16 hat Michael Hartmann geschrieben: > Wie bekomme ich die DB einer neuen Middleware-Installation auf die alte > Struktur mit automatisch generierten, fortlaufenden IDs zurück? Wenn die Spalte vorhanden (und korrekt eingerichtet) ist müsste die von der Datenbank gefüllt werden. Es handelt sich nur um eine fortlaufende Nummer. Die muss, meines Wissens, nicht gezielt bedient werden. mfg Daniel
Re: [vz-users] Datenbankportierung und neue Struktur
Hallo, am Dienstag, 27. Dezember 2022 um 16:16 hat Michael Hartmann geschrieben: > Wie bekomme ich die DB einer neuen Middleware-Installation auf die alte > Struktur mit automatisch generierten, fortlaufenden IDs zurück? Wenn die Spalte vorhanden (und korrekt eingerichtet) ist müsste die von der Datenbank gefüllt werden. Es handelt sich nur um eine fortlaufende Nummer. Die muss, meines Wissens, nicht gezielt bedient werden. mfg Daniel
Re: [vz-users] Datenbankportierung und neue Struktur
Da Backups via dbcopy (insbesondere inkrementelle) aufgrund der neuen
DB-Struktur wohl nicht mehr möglich sind, wäre ich an Plan B interessiert:
Wie bekomme ich die DB einer neuen Middleware-Installation auf die alte
Struktur mit automatisch generierten, fortlaufenden IDs zurück?
Grüße
Micha
-Ursprüngliche Nachricht-
Von: volkszaehler-users
[mailto:volkszaehler-users-boun...@demo.volkszaehler.org] Im Auftrag von
Michael Hartmann
Gesendet: Montag, 26. Dezember 2022 11:55
An: 'volkszaehler.org - users'
Betreff: Re: [vz-users] Datenbankportierung und neue Struktur
Hallo Jakob,
der Unterschied zwichen pk und copy ist klar. Nur das copy wie von mir und Sven
zuvor beschrieben lediglich die ersten 1000 Datensätze ins Backup transferiert.
Der "Fehler" geschieht bereits beim Sichern, wie aus der Größe der
Sicherungsdatei ersichtlich.
Msqldump kann man sicherlich machen um einmalig irgendwie Daten zu
transferieren. Nur:
Deinem Quote aus dem Code folgend, braucht es eine Anpassung von dbcopy?
Damit wäre ich nach Umstellung auf die neue DB-Struktur der Möglichkeit eines
täglichen, inkrementellen Backups beraubt. Davon fahre ich zwei. In eine SQlite
DB auf einem Share und in eine parallele SQL-DB die auf meinem NAS liegt.
Irgendwie ist das ziemlich unglücklich mit der neuen DB-Struktur ohne
fortlaufende ID.
Grüße
Micha
-Ursprüngliche Nachricht-
Von: volkszaehler-users
[mailto:volkszaehler-users-boun...@demo.volkszaehler.org] Im Auftrag von Jakob
Hirsch
Gesendet: Montag, 26. Dezember 2022 01:32
An: volkszaehler-users@demo.volkszaehler.org
Betreff: Re: [vz-users] Datenbankportierung und neue Struktur
On 2022-12-24 12:56, Michael Hartmann wrote:
> In CopyCommand.php line 40:
>
> Table data doesn't have a simple primary key
hm...
if (1 !== sizeof($columns)) {
naja, ein zusammengesetzter Key ist halt kein "simple primary key". also
"technically correct" (the best kind of correct!).
dbcopy kennt neben "pk" auch "copy" als Modus, damit wird der pk nicht
benutzt, sondern einfach der komplette Inhalt von A nach B kopiert (und
B vorher gelöscht). pk ist eigentlich nur nützlich, wenn man zwei
Datenbanken synchronisieren möchte, für einen reinen export reicht copy
(ist evt. sogar schneller). Das ist übrigens auch der default, wenn man
keine Sektion "tables" in der dbcopy.json hat...
Einfacher (und wahrscheinlich schneller) dürfte es aber sein, einfach
die Datenbank mit mysqldump in eine Datei zu schreiben und diese auf dem
Zielsystem wieder einzuspielen.
Also so etwa: (ungetestet)
mysqldump --opt --databases vz > vz.sql
Und dann auf dem Zielrechner:
mysql < vz.sql
Re: [vz-users] Datenbankportierung und neue Struktur
Hallo ich sicher die Datenbank mit mysqldump, wobei ich dem dump mit nice -n 19 die niedrigeste Prio zuweise. Damit habe ich keinen Verlust von Messdaten während des Dumps. Gruß Tilman On 26.12.22 12:02, Daniel Lauckner wrote: Hallo, am Montag, 26. Dezember 2022 um 01:32 hat Jakob Hirsch geschrieben: Einfacher (und wahrscheinlich schneller) dürfte es aber sein, einfach die Datenbank mit mysqldump in eine Datei zu schreiben und diese auf dem Zielsystem wieder einzuspielen. Leider verursacht mysqldump auf Systemen mit beschränkter Leistung Probleme. Man kann es auf einem Rpi nicht parallel zum VZ laufen lassen, dann verwirft das System (vermeintlich wegen Überlast) neu eingehende Daten. mfg Daniel
Re: [vz-users] Datenbankportierung und neue Struktur
Hallo, am Montag, 26. Dezember 2022 um 01:32 hat Jakob Hirsch geschrieben: > Einfacher (und wahrscheinlich schneller) dürfte es aber sein, einfach die > Datenbank mit mysqldump in eine Datei zu schreiben und diese auf dem > Zielsystem wieder einzuspielen. Leider verursacht mysqldump auf Systemen mit beschränkter Leistung Probleme. Man kann es auf einem Rpi nicht parallel zum VZ laufen lassen, dann verwirft das System (vermeintlich wegen Überlast) neu eingehende Daten. mfg Daniel
Re: [vz-users] Datenbankportierung und neue Struktur
Hallo Jakob,
der Unterschied zwichen pk und copy ist klar. Nur das copy wie von mir und Sven
zuvor beschrieben lediglich die ersten 1000 Datensätze ins Backup transferiert.
Der "Fehler" geschieht bereits beim Sichern, wie aus der Größe der
Sicherungsdatei ersichtlich.
Msqldump kann man sicherlich machen um einmalig irgendwie Daten zu
transferieren. Nur:
Deinem Quote aus dem Code folgend, braucht es eine Anpassung von dbcopy?
Damit wäre ich nach Umstellung auf die neue DB-Struktur der Möglichkeit eines
täglichen, inkrementellen Backups beraubt. Davon fahre ich zwei. In eine SQlite
DB auf einem Share und in eine parallele SQL-DB die auf meinem NAS liegt.
Irgendwie ist das ziemlich unglücklich mit der neuen DB-Struktur ohne
fortlaufende ID.
Grüße
Micha
-Ursprüngliche Nachricht-
Von: volkszaehler-users
[mailto:volkszaehler-users-boun...@demo.volkszaehler.org] Im Auftrag von Jakob
Hirsch
Gesendet: Montag, 26. Dezember 2022 01:32
An: volkszaehler-users@demo.volkszaehler.org
Betreff: Re: [vz-users] Datenbankportierung und neue Struktur
On 2022-12-24 12:56, Michael Hartmann wrote:
> In CopyCommand.php line 40:
>
> Table data doesn't have a simple primary key
hm...
if (1 !== sizeof($columns)) {
naja, ein zusammengesetzter Key ist halt kein "simple primary key". also
"technically correct" (the best kind of correct!).
dbcopy kennt neben "pk" auch "copy" als Modus, damit wird der pk nicht
benutzt, sondern einfach der komplette Inhalt von A nach B kopiert (und
B vorher gelöscht). pk ist eigentlich nur nützlich, wenn man zwei
Datenbanken synchronisieren möchte, für einen reinen export reicht copy
(ist evt. sogar schneller). Das ist übrigens auch der default, wenn man
keine Sektion "tables" in der dbcopy.json hat...
Einfacher (und wahrscheinlich schneller) dürfte es aber sein, einfach
die Datenbank mit mysqldump in eine Datei zu schreiben und diese auf dem
Zielsystem wieder einzuspielen.
Also so etwa: (ungetestet)
mysqldump --opt --databases vz > vz.sql
Und dann auf dem Zielrechner:
mysql < vz.sql
Re: [vz-users] Datenbankportierung und neue Struktur
On 2022-12-24 12:56, Michael Hartmann wrote:
In CopyCommand.php line 40:
Table data doesn't have a simple primary key
hm...
if (1 !== sizeof($columns)) {
naja, ein zusammengesetzter Key ist halt kein "simple primary key". also
"technically correct" (the best kind of correct!).
dbcopy kennt neben "pk" auch "copy" als Modus, damit wird der pk nicht
benutzt, sondern einfach der komplette Inhalt von A nach B kopiert (und
B vorher gelöscht). pk ist eigentlich nur nützlich, wenn man zwei
Datenbanken synchronisieren möchte, für einen reinen export reicht copy
(ist evt. sogar schneller). Das ist übrigens auch der default, wenn man
keine Sektion "tables" in der dbcopy.json hat...
Einfacher (und wahrscheinlich schneller) dürfte es aber sein, einfach
die Datenbank mit mysqldump in eine Datei zu schreiben und diese auf dem
Zielsystem wieder einzuspielen.
Also so etwa: (ungetestet)
mysqldump --opt --databases vz > vz.sql
Und dann auf dem Zielrechner:
mysql < vz.sql
Re: [vz-users] Datenbankportierung und neue Struktur
Hallo Sven, zur Konvertierung verweise ich auf einen post von jau im PV-Forum: https://www.photovoltaikforum.com/thread/173921-datenbank-portierung/?postID=2624435#post2624435 und meine Ergänzung dazu: https://www.photovoltaikforum.com/thread/173921-datenbank-portierung/?postID=2925923#post2925923 Konkret läuft das dann so: 1. Sicherung (sqldump) der DB als Fallback 2. Ändern der alten DB mit: php /var/www/volkszaehler.org/bin/doctrine orm:schema-tool:update --force 3. Sicherung der DB für Transfer 4. neue DB mit doctrine anlegen php /var/www/volkszaehler.org/bin/doctrine orm:schema-tool:create 5. Sicherung aus 3 auf neuer DB einspielen Das funktioniert eben bis auf das Sichern (3) und Einspielen (5) der Daten in die neue DB (properties, entities werden mit copy korrekt übertragen). Und bei mir ist es genauso wie bei dir, ändere ich den transfer mode für data von pk auf copy bekomme ich nur 1000 Datensätze rüber. Grüße Micha Von: volkszaehler-users [mailto:volkszaehler-users-boun...@demo.volkszaehler.org] Im Auftrag von dies und das Gesendet: Sonntag, 25. Dezember 2022 15:22 An: volkszaehler.org - users Betreff: Re: [vz-users] Datenbankportierung und neue Struktur Hallo Micha, ich habe das gleiche Problem und viel probiert, einen Teil Erfolg hatte ich mit der Änderung in dbcopy.yaml für DATA von pk auf copy. Das Ergebnis war zwar das dbCopy Meldete alle rows übertragen zuhaben beim Nachschauen aber immer nur 1000 Einträge in der neuen Zieldatenbank waren egal ob mysql oder sqlight. Mit meinem Halbwissen bin ich leider nicht weitergekommen. Mich würde interessieren wie du die Konvertierung hinbekommen hast ich habe dazu keine Lösung gefunden. Mfg Sven Am Sa., 24. Dez. 2022 um 13:01 Uhr schrieb Michael Hartmann : Hallo, aktuell läuft eine komplette VZ-Installation auf einem Raspi3 mit µSD. Ich möchte DB, Frontend und Middleware auf einen weiteren Raspi4 mit SSD auslagern. Die DB-Struktur hat sich zwischenzeitig geändert. Die alte, automatisch vergebene fortlaufende ID ist entfallen und der primary key ist nun die Kombination aus channel_id und timestamp. Ich habe als Probelauf die DB auf meinem Test-/Spielsystem auf die neue Struktur konvertiert. Das hat funktioniert. Ich kann auf alle Daten zugreifen und auch über die API manuell Daten schreiben. MariaDB [volkszaehler]> show columns from data; +++--+-+-+---+ | Field | Type | Null | Key | Default | Extra | +++--+-+-+---+ | channel_id | int(11)| NO | PRI | NULL| | | timestamp | bigint(20) | NO | PRI | NULL| | | value | double | NO | | NULL| | +++--+-+-+---+ 3 rows in set (0.028 sec) Nun wollte ich die DB mittel dbcopy in eine SQLite DB sichern um sie auf den Raspi4 einzuspielen. Da meckert dbcopy das es keinen simple primary key in data findet… entities: copying 11 rows (overwrite) [] 100% < 1 sec/< 1 sec 11 rows properties: copying 90 rows (overwrite) [] 100% < 1 sec/< 1 sec 90 rows entities_in_aggregator: copying 0 rows (overwrite) 0 [->--] < 1 sec 6.0 MiB In CopyCommand.php line 40: Table data doesn't have a simple primary key Wie bekomme ich dbcopy erklärt das es nun channel_id und timestamp als primary key verwenden soll? Viele Grüße Micha
Re: [vz-users] Datenbankportierung und neue Struktur
Hallo Micha, ich habe das gleiche Problem und viel probiert, einen Teil Erfolg hatte ich mit der Änderung in dbcopy.yaml für DATA von pk auf copy. Das Ergebnis war zwar das dbCopy Meldete alle rows übertragen zuhaben beim Nachschauen aber immer nur 1000 Einträge in der neuen Zieldatenbank waren egal ob mysql oder sqlight. Mit meinem Halbwissen bin ich leider nicht weitergekommen. Mich würde interessieren wie du die Konvertierung hinbekommen hast ich habe dazu keine Lösung gefunden. Mfg Sven Am Sa., 24. Dez. 2022 um 13:01 Uhr schrieb Michael Hartmann < hartmann-mi...@web.de>: > Hallo, > > > > aktuell läuft eine komplette VZ-Installation auf einem Raspi3 mit µSD. Ich > möchte DB, Frontend und Middleware auf einen weiteren Raspi4 mit SSD > auslagern. > > > > Die DB-Struktur hat sich zwischenzeitig geändert. Die alte, automatisch > vergebene fortlaufende ID ist entfallen und der primary key ist nun die > Kombination aus channel_id und timestamp. > > > > Ich habe als Probelauf die DB auf meinem Test-/Spielsystem auf die neue > Struktur konvertiert. Das hat funktioniert. Ich kann auf alle Daten > zugreifen und auch über die API manuell Daten schreiben. > > > > MariaDB [volkszaehler]> show columns from data; > > +++--+-+-+---+ > > | Field | Type | Null | Key | Default | Extra | > > +++--+-+-+---+ > > | channel_id | int(11)| NO | PRI | NULL| | > > | timestamp | bigint(20) | NO | PRI | NULL| | > > | value | double | NO | | NULL| | > > +++--+-+-+---+ > > 3 rows in set (0.028 sec) > > > > > > Nun wollte ich die DB mittel dbcopy in eine SQLite DB sichern um sie auf > den Raspi4 einzuspielen. Da meckert dbcopy das es keinen simple primary > key in data findet… > > > > entities: copying 11 rows (overwrite) > > [] 100% < 1 sec/< 1 sec 11 rows > > > > properties: copying 90 rows (overwrite) > > [] 100% < 1 sec/< 1 sec 90 rows > > > > entities_in_aggregator: copying 0 rows (overwrite) > > 0 [->--] < 1 sec 6.0 MiB > > > > > > In CopyCommand.php line 40: > > > > Table data doesn't have a simple primary key > > > > > > Wie bekomme ich dbcopy erklärt das es nun channel_id und timestamp als > primary key verwenden soll? > > > > Viele Grüße > > > > Micha >
[vz-users] Datenbankportierung und neue Struktur
Hallo, aktuell läuft eine komplette VZ-Installation auf einem Raspi3 mit µSD. Ich möchte DB, Frontend und Middleware auf einen weiteren Raspi4 mit SSD auslagern. Die DB-Struktur hat sich zwischenzeitig geändert. Die alte, automatisch vergebene fortlaufende ID ist entfallen und der primary key ist nun die Kombination aus channel_id und timestamp. Ich habe als Probelauf die DB auf meinem Test-/Spielsystem auf die neue Struktur konvertiert. Das hat funktioniert. Ich kann auf alle Daten zugreifen und auch über die API manuell Daten schreiben. MariaDB [volkszaehler]> show columns from data; +++--+-+-+---+ | Field | Type | Null | Key | Default | Extra | +++--+-+-+---+ | channel_id | int(11)| NO | PRI | NULL| | | timestamp | bigint(20) | NO | PRI | NULL| | | value | double | NO | | NULL| | +++--+-+-+---+ 3 rows in set (0.028 sec) Nun wollte ich die DB mittel dbcopy in eine SQLite DB sichern um sie auf den Raspi4 einzuspielen. Da meckert dbcopy das es keinen simple primary key in data findet entities: copying 11 rows (overwrite) [] 100% < 1 sec/< 1 sec 11 rows properties: copying 90 rows (overwrite) [] 100% < 1 sec/< 1 sec 90 rows entities_in_aggregator: copying 0 rows (overwrite) 0 [->--] < 1 sec 6.0 MiB In CopyCommand.php line 40: Table data doesn't have a simple primary key Wie bekomme ich dbcopy erklärt das es nun channel_id und timestamp als primary key verwenden soll? Viele Grüße Micha
