nicht angemeldet
Komplizierte DB-Datensicherung Server - Server
Hallo,
Problem: Datensicherung dauert zu lange, 55 sec für zehn Sätze aus ca. 30.000. Es geht um die Verbesserung des Konzepts.
Für ein Projekt habe ich einen Hauptserver im Web (mehrere Mandanten in der DB) und einen Ersatzserver im lokalen Netz. Da der Ersatzserver aus dem Web nicht erreichbar ist, müssen die Daten bei Bedarf vom Hauptserver "gezogen" werden, also manuell gesteuert.
Das Projekt ist mandantenfähig. Das heisst, die Daten eines bestimmten Mandanten werden vom Haupt- zum Ersatzserver übertragen, nicht die Daten anderer Mandanten.
Das Sicherungs-Programm läuft auf dem Ersatzserver und stellt die eigenen DB-Tabellen und die des Hauptservers gegenüber. Gezeigt wird jeweils der Tabellenname, die Anzahl der Datensätze dieses Mandanten und das größte last_modified (Datum/Uhrzeit) zu Mandant/Tabelle.
Bei Klick auf einen Tabellennamen wird vom Hauptserver eine CSV-Datei angefordert, als Parameter das größte Datum (nicht Uhrzeit) last_modified zu Mandant/Tabelle mitgegeben.
HAUPTSERVER:
Sämtliche 30.000 Datensätze zu Mandant/Tabelle werden gelesen, aufsteigend nach ID.
Ist last_modified kleiner als der Parameter, ist nichts zu ändern. Aber die ID wird übermittelt und besagt: Satz besteht.
Ist last_modified größer oder gleich dem Parameter werden die Feldinhalte übermittelt.
ERSATZSERVER:
Dummerweise müssen alle 30.000 IDs in der Tabelle gelesen werden und einzeln mit den hereingekommenen IDs verglichen werden.
Wenn "eigene" ID fehlt, wird der Satz neu angelegt.
Wenn "eigene" ID vorhanden, wird der Satz geändert,
Wenn "eigene" ID, aber ohne "Partner" vom Hauptserver, wird Satz gelöscht.
Für eine "handvoll" zu ändernder oder zu löschender Datensätze müssen auf dem Hauptserver UND nochmal auf dem Ersatzserver 30.000 Datensätze einzeln durchgehechelt werden.
Bei Neuauflage so eines Projekts würde ich gelöschte Datensätze mit einer Lösch-Kennung versehen, aber stehen lassen. Dann können sie gezielt übermittelt werden.
Irgend eine Idee zur Verschnellerung des Sende- und Empfangsprogramms?
Gruß Linuchs
-
Hello,
ich wiederhole mich hier zum xten Mal.
Während einer Datensicherung müssen die Tabellen gegen Veränderung gesperrt werden!
Besser ist es, das Login zu disablen, die Buffers zu flushen, den Server kurz herunterzufahren und dann die gesamten Tabellen in ein Sicherungsverzeichnis zu kopieren.Danach kann Server schon wieder hochgefahren werden.
Der gesamte Vorgang dauert bei üblichen Datenmengen für kleine Pages (also nicht Google) i.d.R. nur wenige Sekunden.
Das Sicherungs-Directory kannst Du anschließend mit targz verpacken und dann in aller Seelenruhe auf den anderen Server transportieren. Dort spielst Du es ins Datenverzeichnis win und startest dort den Datenbankserver.
Danach sollten alle Daten im Backup verfügbar sein.
Gleiche Grundeinstellungen beider Server sind selbstverständlich vorausgesetzt.
Das Ganze nennt sich "Vollsicherung" :-)
Bei verteilten Datenbanken, und dazu gehören dann z.B. auch assoziierte Directories mit Bildern oder sonstigen nicht in der DB gespeicherten Daten, muss man das Konzept selbstverständlich entsprechend erweitern. Du beginnst also deine Datensicherungsplanung mit einem Datenplan!
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
-
Hallo Tom,
Während einer Datensicherung müssen die Tabellen gegen Veränderung gesperrt werden!
Ist bei meinem Konzept nicht notwendig (denke ich). Falls während der laufenden Sicherung ein Datensatz verändert wird, werden schlimmstenfalls die alten Werte übermittelt.
Aber das sieht man ja sofort in der anschließenden Gegenüberstellung: Die letzten last_modified sind nicht identisch, der Hauptserver hat eine neuere.
Besser ist es, ...
Das Sicherungs-Directory kannst Du anschließend mit targz verpacken und dann in aller Seelenruhe auf den anderen Server transportieren. Dort spielst Du es ins Datenverzeichnis win und startest dort den Datenbankserver.
Danach sollten alle Daten im Backup verfügbar sein.
Böse Falle: Mandant A hat dann auf seinem Rechner alle Daten der anderen Mandanten.
Wäre im aktuellen Projekt nicht schlimm, da sind die "Mandanten" verschiedene Großveranstaltungen derselben Firma, aber das Konzept der Mandantenfähigkeit wäre gestorben.
Linuchs
-
Das Sicherungs-Directory kannst Du anschließend mit targz verpacken und dann in aller Seelenruhe auf den anderen Server transportieren. Dort spielst Du es ins Datenverzeichnis win und startest dort den Datenbankserver.
Ja, ICH. Die Datensicherung soll aber ein berechtigter Anwender beim Kunden per Browser machen, der hat keinen Zugang zu den Innereien der Server.
Ist auch in meinem Sinne, so habe ich Verantwortung delegiert ...
-
Hello,
Böse Falle: Mandant A hat dann auf seinem Rechner alle Daten der anderen Mandanten.
Nee! DU hast alle Datgen auf dem Backup-System.
Die kannst Du dann in Ruhe, ohne lästige gleichzeitioge Änderungen durch Mandanten, auseinanderpruzzeln.
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
-
Hallo,
Böse Falle: Mandant A hat dann auf seinem Rechner alle Daten der anderen Mandanten.
Nee! DU hast alle Datgen auf dem Backup-System.
Die kannst Du dann in Ruhe, ohne lästige gleichzeitioge Änderungen durch Mandanten, auseinanderpruzzeln.
Dann habe ich mich missverständlich ausgedrückt. Nicht ICH habe das Backup-System, sondern mein Kunde. Mit anderen Worten: Kunde kann Backup machen per Browser. Ohne mich.
Linuchs
-
-
-
-
Guten Tag.
Für eine "handvoll" zu ändernder oder zu löschender Datensätze müssen auf dem Hauptserver UND nochmal auf dem Ersatzserver 30.000 Datensätze einzeln durchgehechelt werden.
Bei Neuauflage so eines Projekts würde ich gelöschte Datensätze mit einer Lösch-Kennung versehen, aber stehen lassen. Dann können sie gezielt übermittelt werden.
Was spricht dagegen, dieses nachträglich einzufügen? Es wäre die weitaus sauberste Lösung (abgesehen von der Komplettkopie).
Dein Problem sind die gelöschten Datensätze. Etwas, das nicht da ist, kann man auch nicht zu einem Vergleich heranziehen. Willst du nicht jeden Datensatz einzeln auf Existenz prüfen bzw. alternativ ohne Prüfung einfach die komplette (Mandanten-) Datenbank kopieren, wirst du um eine Markierung oder Aufzeichnung gelöschter Datensätze nicht herumkommen.
Als Abkürzung sehe ich nur, auf der Kopie nach Neuanlage und Änderung die Anzahl der nicht geänderten, alten Datensätze zu zählen. Ist diese Anzahl gleich jener auf dem Original, wurden keine weiteren Datensätze gelöscht und du kannst den aufwändigen Einzelvergleich aller IDs weglassen.
Davon abgesehen gehe ich mal davon aus, dass du bereits deine ID-Prüfungen so weit en bloc ausführst, wie es die Datenbank zulässt, d.h. nicht für jeden der 30.000 Datensätze ein einzelnes select, sondern eine Gruppe à la "select count(*) from bla where id in (1,2,3,4)". Kommt hier genau die Anzahl raus, die an IDs angegeben wurde, ist dieser Block unverändert. Machst du das zum Beispiel mit je Tausend IDs, hättest du im günstigsten Fall von nur einer Löschung nur noch 1029 select-Abfragen statt 30.000.
-
Bei Neuauflage so eines Projekts würde ich gelöschte Datensätze mit einer Lösch-Kennung versehen, aber stehen lassen. Dann können sie gezielt übermittelt werden.
Was spricht dagegen, dieses nachträglich einzufügen? Es wäre die weitaus sauberste Lösung (abgesehen von der Komplettkopie).
Dann müsste JEDE sql-Abfrage die gelöschten Datensätze ausschließen, sonst wären sie ja dabei. Bei so etwa 40 - 50 Programmen mit einer unbekannten Zahl von einfachen und komplizierten sql-Abfragen mit JOIN ein riskantes Manöver.
Da ist die laaaaange Datensicherung das kleinere Problem.
Als Abkürzung sehe ich nur, auf der Kopie nach Neuanlage und Änderung die Anzahl der nicht geänderten, alten Datensätze zu zählen. Ist diese Anzahl gleich jener auf dem Original, wurden keine weiteren Datensätze gelöscht und du kannst den aufwändigen Einzelvergleich aller IDs weglassen.
Muss ich drüber nachdenken, habe ich auf Anhieb nicht verstanden.
Linuchs
-