2 Jahre rückwirkend Backup (MySQL)

[XspYroX]

Hi

Ich stehe vor folgende, Szenario:

Wir haben eine MySQL DB, in der eine Tabelle mit ca. 1500 einträgen ist.

Diese Einträge werden minütlich aktualisiert, allerdings NUR aktualisiert. Es kommen also selten neue Einträge mehr dazu.

Von dieser Tabelle muss nun täglich oder stündlich eine art Snapshot erstellt werden und diese Snapshots müssen 2 Jahre Rückwirkend aufbewahrt werden.

Habe mal hochgerechnet und bei stündlichen snapshots wären 2 jahre ca. 2,9 GB groß... also in Serversprache "winzig".

1. Die Daten sollen so in Dateien auf der Festplatte liegen, dass man sie leicht sichern kann (robocopy o.ä.)

2. Ich möchte mit php skripten die daten der letzten x wochen/monate aus diesem backup auswerten können, ohne sie erst entpacken zu müssen ö.ä.

Was würdet ihr da vorschlagen? Bin mir z.b. noch unsicher ob ich mysql events zum backupen nehmen soll oder externe chronjobs.

bin mir auch über das exportierte format unsicher...

Freue mich über Vorschläge zur Umsetzung

Viele Grüße ^^

[MartinSt]

Wenn entsprechend konfiguriert, dann erstellt MySQL sowieso Binary Logs zu allen ändernden Aktionen.

MySQL :: MySQL 5.1 Referenzhandbuch :: 5.12.3 Die binäre Update-Logdatei

Diese kann man mit MySQL-Bordmitteln in Textfiles umwandeln und anhand der Zeitstempel gezielt auswerten.

Gruß Martin

[lilith2k3]

Ich weiß nicht, inwiefern das für Dein Szenario praktikabel ist, aber ich würde es fauler angehen:

Ich würde entweder einen Datenbanktrigger anlegen, der bei jedem UPDATE ein Insert in einer anderen Tabelle macht (die dann eine Column Timestamp enthält) oder applikationsseitig die Daten in eine zweite DB sichern.

Dann hast Du nicht nur einen Snapshot, sondern zeichnest alle Änderungen auf.

Vorallem ist es quatsch, die Daten aus einer Datenbank zu extrahieren, in einem Textfile abzulegen, wenn man mit den Daten später noch was Gescheites anfangen will - also das, wofür Datenbanken gemacht worden sind.

Ich möchte mit php skripten die daten der letzten x wochen/monate aus diesem backup auswerten

Äh - ja.

Je nachdem, was Du vorhast, wäre ein Blick auf Elasticsearch.org Open Source Distributed Real Time Search & Analytics | Elasticsearch oder Apache Lucene - Apache Solr sinnvoll.

[_XspYroX_]

Datenbanktrigger möchte/kann ich nicht benutzen, da die Daten wirklich nur täglich/stündlich exportiert/gesichert werden sollen.

Die daten in der tabelle aktualisieren sich alle paar minuten. Dadurch würde das datenvolumen im schlimmstenfall 60x so groß werden und das wollen wir dann doch nicht.

Jetzt wo ich so darüber nachdenke.... vielleicht lasse ich die snapshots doch einfavh in eine DB exportieren....hmmm.... Allerdings wird ein such-query auf eine 2,9 gb tabelle vermutlich extrem lange dauern, oder? :/

oder ich erstelle jeweils für einen monat eine tabelle....

[MartinSt]

Von was reden wir hier eigentlich, tägliche oder stündliche Snapshots?

Warum überhaupt? was soll dann damit passieren?

[lilith2k3]

Die daten in der tabelle aktualisieren sich alle paar minuten. Dadurch würde das datenvolumen im schlimmstenfall 60x so groß werden und das wollen wir dann doch nicht.

Warum? Fehlt es an Festplatten?

Jetzt wo ich so darüber nachdenke.... vielleicht lasse ich die snapshots doch einfavh in eine DB exportieren.

Ja. Das ist in jedem Falle eine kluge Idee.

Allerdings wird ein such-query auf eine 2,9 gb tabelle vermutlich extrem lange dauern, oder? :/

Das kommt drauf an. Es gibt ja Mittel und Wege ... Denormalisierung wie man die Daten ablegt. Oben habe ich auch die ein oder andere Möglichkeit genannt ...

[XspYroX]

Von was reden wir hier eigentlich, tägliche oder stündliche Snapshots?

Warum überhaupt? was soll dann damit passieren?

- Es sollte keinen Unterschied machen, in welchem Interval ich snapshots machen möchte. Sagen wir einfach alle X Sekunden/Minuten/Stunden/Tage/Wochen/Monate/Jahre

- Warum ich die Snapshots machen möchte? Weil es die Situation in der Firma erfordert.

- Was dann damit passieren soll? Die Frage verstehe ich nicht. Die Daten sollen gesichert/exportiert werden. Auf diese Sicherungsdaten soll, zwecks Analysen, zugegriffen werden können.

@lilith2k3:

Es fehlt nicht an Festplatten, allerdings wirkt sich der Faktor 60 auch auf andere Dinge aus, z.B. die Dauer für ein komplettes Backup der Daten über's Internet.

Mein aktueller Gedankengang ist, dass ich vorerst mit einem Chronjob in einem Interval die Daten der originaltabelle in eine Montagstabelle schreiben lasse, z.b. "t_2014_09". Dadurch wird die einzelne Tabelle an sich relativ klein gehalten und ich kann den Interval sogar nach belieben ändern. Ob ich nun täglich sichere (30 datensätze in der tabelle) oder stündlich (30 x 24 datensätze in der tabelle) ist dann egal.

Denormalisierung gucke ich mir aber an, danek für den Tipp

Bearbeitet 28. September 2014 von XspYroX

[pr0gg3r]

Der Ansatz ist doch komplett falsch. Man möchte Daten erheben und ständig auf diese Zugreifen können. Ein Backup ist nicht zur Archivierung in dem Sinne gedacht, dass man darauf zugreifen kann, falls man Informationen herauslesen möchte, sondern, um Falle eines Notfalles(!) Daten wiederherstellen zu können, falls die Originaldaten korrumpiert sind. Demnach halte ich es für falsch, Daten zu erheben, diese zu backupen, die Daten zu überschreiben und dann ständig Backups wiederhestellen / einsehen zu müssen. Anstelle dessen, würde ich jedem Eintrag einen Timestamp geben und die Daten nicht aktualisieren, sondern ständig neue Datensätze erheben. Und nein, einer Datenbank auf ner gescheiten Infrastruktur, evtl. mit Clustering etc. machen ein paar Millionen+ Datensätze nicht aus. Davon aber trotzdem immer ein Backup machen (das eine hat mit dem anderen nichts zu tun).

[lilith2k3]

@pr0gg3r

Es ist ja nicht so, als hätte man ihm die Alternativen nicht aufgezeigt *g*

[XspYroX]

@pr0gg3r

Es ist ja nicht so, als hätte man ihm die Alternativen nicht aufgezeigt *g*

Das Problem ist nur, dass insbesondere du, lilith2k3, nicht die Randbedingungen in meinem Szenario beachtest

Dass ich bei jedem Update in der Tabelle etwas triggern kann, ist mit bekannt und in anderen Bereichen wird diese Methode auch eingesetzt.

Allerdings ist dies in meinem Szenario nicht gewünscht. Den Grund dafür kann/darf ich dir leider nicht genauer sagen und, wie bereits erwähnt, sollte ich mein Szenario nicht rechtfertigen müssen.

Auch der Vorschlag, der weiter oben fiel, ich könne ja die Logs ansehen und auswerten ist nicht das, was bei uns praktisch umsetzbar ist bzw. den gewünschten Effekt erzielt.

Ich danke jedem hier für seine Antworten und das einbringen neuer Ideen, denn genau das hatte ich mir erhofft.

Ich kann aber, lieber lilith2k3, unser Szenario nicht umbiegen, damit z.B. das Update-Triggern benutzt werden kann. Leider.

Den letzten Kommentar hättest du dir auch eher sparen könne, da er nur eine private Kommunikation zwischen dir und pr0gg3r darstellt, ja sogar leicht überheblich über mich herzieht.

Mit deinen 38 Jahren und 1.280 Beiträgen hätte ich das eigentlich nicht erwartet

@pr0gg3r: "Der Ansatz ist doch komplett falsch" -> stimme ich dir teilweise vor, allerdings wird der Ansatz von anderer Stelle vorgegeben und ist leider indiskutabel. Daher müssen wir (erstmal) mit diesem Ansatz vorlieb nehmen.

Vielen Dank also nochmal an euch alle

Viele Grüße

XspYroX

[Heikooo]

Wenn die Methode wie du an die Sache herangehen "darfst" sowieso eingegrenzt ist verstehe ich nicht ganz wieso du überhaupt gefragt hast und dann die Antworten mit "nee darf ich nicht" nieder machst...

Wenn du eh nur die eine Methode verwenden kannst dann nimm sie und viel spass beim debuggen wenn du auf die ersten Probleme stößt.

Auch wenn dir jemand etwas vorgibt darfst du ihm sagen das es schlecht durchdacht ist es bessere Methoden gibt die performanter sind und sich "Best Practice" nennen.

PS: Und ja, ich bin nur 27 und habe nur seeeehr wenig Posts.... Na und?

[lilith2k3]

Allerdings ist dies in meinem Szenario nicht gewünscht. Den Grund dafür kann/darf ich dir leider nicht genauer sagen und, wie bereits erwähnt, sollte ich mein Szenario nicht rechtfertigen müssen.

Ich denke, wenn der Ansatz schlecht ist, sollte man das auch so sagen dürfen.

Dass Dir die Hände gebunden sind, macht a) den Ansatz nicht schöner und ist das nicht unser Problem.

Wenn Du keine besseren Ansätze einbringen darfst ist das traurig.

Nachwievor bleibt zumindest der Hinweis, von Snapshots in Textform Abstand zu nehmen. Und wenn Du den umsetzten darfst, hast Du schon profitiert.

Mit deinen 38 Jahren und 1.280 Beiträgen hätte ich das eigentlich nicht erwartet

Netter Versuch ...

[pr0gg3r]

@pr0gg3r: "Der Ansatz ist doch komplett falsch" -> stimme ich dir teilweise vor, allerdings wird der Ansatz von anderer Stelle vorgegeben und ist leider indiskutabel. Daher müssen wir (erstmal) mit diesem Ansatz vorlieb nehmen.

Das kenne ich leider auch zu gut von meinem ehemaligen Arbeitgeber... Manchmal bekommt man Aufgaben zu lösen, die man viel besser erledigen könnte, aber durch unsinnige Vorgaben wird man derart eingeschränkt, dass die Lösungen weder professionell noch praktikabel sind. Naja, was will man machen (außer kündigen, ich bin inzwischen nicht mehr dort )

Ich habe hier die Stichworte MySQL und PHP herausgelesen, da würde ich dir einfach mal MySQLDumper - Sichern von MySQL-Datenbanken (z.B. Foren, Gästebücher und Onlineshops) empfehlen und das über einen Cronjob laufen lassen und fertig ist deine Sicherung. Wie man dann bei Bedarf auf die Daten zugreifen soll, musst du dir halt noch überlegen.

[RipperFox]

Auch wenn der Thread schon älter ist:

Das Problem ist nur, dass insbesondere du, lilith2k3, nicht die Randbedingungen in meinem Szenario beachtest

Dass ich bei jedem Update in der Tabelle etwas triggern kann, ist mit bekannt und in anderen Bereichen wird diese Methode auch eingesetzt.

Auf die Idee, dass Du statt eines Triggers einfach alle Stunde/etc. ein Statement absetzt (via Cron/SQL Server Agent Job/whatever), welches dir die 1500 Eintrage als einen Snapshop mit Timestamp in eine (1) Tabelle prügelt kommst du dann nicht?

Man kommst so mit max. zwei (2!) Tabellen aus - die Idee, dynamische Tabellen anzulegen ist sehr sehr sehr schlechter Stil und in 99,9% nicht das, was man will. (man Relationale Datenbank)

Allerdings wird ein such-query auf eine 2,9 gb tabelle vermutlich extrem lange dauern, oder? :/

Mit Indizes sicher wesentlich schneller als das Durchsuchen von 2,9 GB Sicherung (Textdateien?) im Dateisystem, oder?

Grüße

Sascha