Re: ZFS Snapshots bei laufendem Download

Hallo,

danke für eure Antworten. Jetzt kann ich das mit den Snapshots besser einordnen.

Viele Grüße
Sascha

On 17.02.2014, at 17:44, Oliver Brandmueller <ob(at)e-Gitt.NET> wrote:

> 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
>

To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message
Received on Tue 18 Feb 2014 - 12:37:33 CET