[vz-users] Datenbankportierung und neue Struktur

Michael Hartmann hartmann-micha at web.de
Do Dez 29 10:12:18 CET 2022


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-bounces at demo.volkszaehler.org] Im Auftrag von Jakob Hirsch
Gesendet: Donnerstag, 29. Dezember 2022 02:15
An: volkszaehler-users at 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...




Mehr Informationen über die Mailingliste volkszaehler-users