[sage] Linux LVM2: Rollback von Snapshots möglich?

[Wolfgang Stief]

Hallo Martin!

On Mon, 28 Jul 2008 17:25:18 +0200
"Martin Schröder" <martin at oneiros.de> wrote:

> Am 28. Juli 2008 17:04 schrieb Wolfgang Stief <stief at guug.de>:
> > Mein Szenario ist eine Datenbank (hier konkret Oracle), in der lange
> > Batch-Jobs laufen. Anforderung ist, dass vor bestimmten Batchläufen
> > (die teilweise mehrere Stunden laufen) der Datenbankzustand in
> > irgendeiner Form eingefroren wird. Falls der Batchlauf fehlerhaft
> > ist (gibt Checks am Ende), soll möglichst schnell und möglichst
> > einfach auf den Zustand vor dem Batchlauf zurück gestellt werden
> > können.
> 
> Transaktion in der DB mit Rollback/Commit ist keine Möglichkeit?

Im Prinzp schon, aber: Die DB soll im Fehlerfall SCHNELL auf einen
alten Stand zurück gefahren werden können um den (korrigierten)
Batchlauf erneut starten zu können. Wir arbeiten hier eh schon auf
einer Kopie, weil die Batches in Summe fast 24h laufen. Das
dazugehörige OLTP-System läuft parallel auf einer Kopie, die Änderungen
aus dem OLTP werden nachts in die Batch-DB überführt. Per OLTP ändern
sich täglich je nach Monatstag zwischen 1% und 5% des gesamten
Datenbestandes.

Wenn man sich jetzt mal vorstellt, was in 3h in einer 10TB-Datenbank so
alles passieren kann, was man ggf. komplett zurück rollen müsste, dann
ist das aus Zeitgründen keine wirkliche Option. Je nach Batchlauf haben
wir im Extremfall ein Schreib-Lese-Verhältnis von 90:10, im Schnitt
etwa 50:50.

Im Moment läuft das System auf einem BS2000 mit ISAM-Files. Die sind --
weil stark komprimiert -- deutlich kleiner, als die gleichen Daten in
Oracle sein werden. Und der Großrechner hat natürlich ein etwas
anders I/O-Verhalten, als das ein SLES auf Intel/AMD haben wird :-)
Meine Firma wiederum ist externer Dienstleister und wurde zu einem
Zeitpunkt hinzugezogen, wo die wesentlichen Design-Kriterien schon
beschlossen waren und die Programmierer bereits ersten Alpha-Code
fertig hatten. 

Das BS2000 System kann diese Rollback-Funktion per Snapshots (bzw.
abgehängten Spiegelbeinen) sehr schnell ausführen, was das neue System
auch können soll (gegenüber den Anwendern darf es keine
Verschlechterung des Service geben). Unsere Aufgabe ist im Prinzip nur,
eine Gegenübersstellung auszuarbeiten, welche
Replizierungsmöglichkeiten für welche Zwecke sinnvoll sind und wo
welche Stolperfallen lauern. Die Entscheidung, welche Verfahren in
welchen Bereichen des Projekts eingesetzt werden, liegt nicht bei uns. 


wolfgang

-- 
  Jabber/XMPP: stief at guug.de                http://www.guug.de/
 ---------------------------------------------------------------
  German Unix User Group @ Xing   https://www.xing.de/net/guug/
  Linux-Kongress 2008            http://www.linux-kongress.org/
  Open Solaris Developer Conference    http://www.osdevcon.org/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.guug.de/pipermail/sage/attachments/20080728/38b8c982/attachment-0001.pgp