Re: ZFS Snapshots bei laufendem Download

Moin,

zu Beginn: Grundsätzlich erstmal volle Zustimmung zu den Ausführungen
meines Namensvetters. Ein Snapshot ist und bleibt ein Snapshot. Wenn Du
ein Polaroid schiesst kannst Du auch nicht erwarten, daß der fette Typ
mit dem Hund später aus dem Bild ist, bloß weil er in der realität
gerade vorbeiging, während Deine Freundin still posierte ;-)

On Sun, Feb 16, 2014 at 12:27:49PM +0100, Oliver Fromme wrote:
> Das betrifft natürlich auch Datenbanken, wobei das in der
> Praxis aber nicht so viel ausmacht. Bei PostgreSQL etwa ist
> es praktisch unmöglich, die Datenbank bei einem Snapshot so
> kaputtzumachen, dass sie nicht mehr geladen werden kann.
> Mysql ist nicht ganz so robust, hat sich in den letzten
> Jahren aber auch gebessert. Um Datenbanken würde ich mir
> daher eher geringe Sorgen machen.
>
> Darüber hinaus sollte man allerdings im Hinterkopf behalten,
> dass Snapshots nicht das geeignetste Mittel sind, um Backups
> von Datenbanken zu erhalten. In der Regel haben Datenbanken
> einen eigenen Mechanismus für Backups (z.B. SQL-Dumps), und
> diesen sollte man auch nutzen, denn dabei wird natürlich die
> innere Struktur der Datenbank berücksichtigt.

In kleineren Umgebungen, wo man keine Slave-Instanzen hat, aus denen man
beliebig Dumpen kann ohne größere Unterbrechungen zu erzeugen kann es
bei einer MySQL ein geeigneter Weg sein.

Bei einer MySQL würde man ein

FLUSH TABLES WITH READ LOCK;

machen, einen ZFS Snapshot nehmen und danach ein

UNLOCK TABLES;

absetzen. Das ganze Verfahren ist relativ schnell (sprich der LOCK
unterbricht Deine Anwendung bei fast beliebiger Datenbankgröße [gemessen
an der kleinen Umgebung] maximal wenige Sekunden) und das, was hinten an
Dateien rausfällt ist i.d.R. tauglich, um es zum Beispiel einer zeiten
Instanz unterzuschieben und dort Dumps zu fahren oder einfach die
Dateien für eine Desaster-Recovery wegzusichern. Ohne DB Locking könnten
ggf. inkonsistente Daten entstehen.

Der Vorteil so erzeugter Backups gegenüber Datenbank-Dumps (die ich mir
allerdings in ernsthaften Umgebungen über eine Slave-Instanz trotzdem
ziehen würde!) ist, daß sie im Problemfall natürlich sehr, sehr viel
schneller (und einfacher) wiederherzustellen sind (so sie denn
ordnungsgemäß an eine unabhängige Stelle gesichert werden - ein Snapshot
hilft nicht, wenn die Hardware stirbt oder das Filesystem aus anderen
Gründen logisch zerstört ist). Einen Dump einer auch nur 100GB großen
MySQL wieder einzuspielen dauert im Zweifel viele Stunden. Die Daten aus
dem Snapshot an geeigneter Stelle zum EInsatz bringen geht bei guter
Vorbereitung in wenigen Minuten. ZFS Snaphots lassen sich, auch
inkrementell, schnell und einfach über das Netz wegsichern.

Ich z.B. arbeite (nicht im Datenbankumfeld, sondern mit Mails für
mehrere zehntausende Nutzer) mit einem Datenbestand von 6 TB, der einmal
pro Stunde per Snapshot auf eine weitere Maschine übertragen wird, das
sind jeweils ca. 10-12 Minuten Übertragungszeit, da ich in meinem Falle
keine Locks setzen muss um konsistente Daten zu erhalten gibt es keine
Beeinflussung der User. Und ich habe für mehrere Wochen in größber
werdenden Abständen Snapshots, aus denen ich z.B. versehentlich
gelöschte Mails leicht wiederherstellen kann.

- Olli

-- 
| Oliver Brandmueller          http://sysadm.in/         ob@sysadm.in |
|                        Ich bin das Internet. Sowahr ich Gott helfe. |
To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message