[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