Speicher-Snapshots für die konsistente Sicherung von postgresql - verschiedene Daten- und Protokollvolumes

Wir führen viele Linux-VMs in einer VMware- / Shared-Storage-Umgebung aus, von denen jede ihre eigene Instanz von postgreSQL ausführt (eine Mischung aus 9.0 und 9.3). Derzeit befindet sich die gesamte VM auf einer einzelnen Root-Partition / einem einzelnen Root-Volume. Wir haben große Erfolge (~ 8 Jahre) mit speicherbasierten Snapshots der zugrunde liegenden VMFS-Volumes für den Sicherungs- / Wiederherstellungsprozess (und die Replikation auf unseren DR-Standort) erzielt.

Aufgrund der Architektur unseres Speichers wäre es vorteilhaft, Postgres-WAL-Dateien in ein nicht zwischengespeichertes Volume mit größtenteils Schreibzugriff zu trennen, um weniger Cache-Abwanderung auf der Speicherseite zu erzielen. Mit unserem Speicher (Nimble Storage) können wir beide Volumes einer einzelnen Schutz- / Snapshot-Gruppe zuweisen, aber ich konnte unserem Anbieter nicht entnehmen, dass die Snapshots auf allen Volumes in der Schutzgruppe genau zur gleichen Zeit erstellt werden - Es wird wahrscheinlich, aber es besteht immer die Möglichkeit, dass es Millisekunden auseinander liegt.

Zu diesem Zweck haben wir einige Experimente durchgeführt, während wir mit pg_bench so schnell wie möglich Daten in die Datenbank geschrieben haben. Nach den Experimenten haben wir unsere Snapshot-Volumes wiederhergestellt und die VM + Postgres gestartet

Schnappschuss von Daten- und Protokollvolumes nahezu gleichzeitig - Ergebnis: DB wiederhergestellt
Snapshot-Datenvolumen zuerst, Protokollvolumen ~ 1 Minute später - Ergebnis: DB wiederhergestellt
Snapshot-Protokollvolumen zuerst, Datenvolumen ~ 1 Minute später - Ergebnis: DB wiederhergestellt
Snapshot-Protokollvolumen zuerst, Datenvolumen ~ 3 Minuten später, nachdem ein WAL-Prüfpunkt neue Daten in Datendateien geschrieben hat: Ergebnis: DB wiederhergestellt

Tests scheinen uns also zu sagen, solange beide Snapshots auf Volume-Ebene konsistent sind und relativ nahe beieinander liegen, erhalten Sie eine konsistente Kopie der Datenbank, basierend auf dem Zeitpunkt des WAL / Log-Volume-Snapshots.

Meine Frage: Ist das sicher? Was sind die Eckfälle, die uns bei unseren Tests fehlen, und was könnte schief gehen?

Das Dokument von Postgres zeigt an, dass dies nicht sicher ist, aber Tests scheinen darauf hinzuweisen, dass es ziemlich robust ist: http://www.postgresql.org/docs/9.1/static/backup-file.html

Wenn Ihre Datenbank auf mehrere Dateisysteme verteilt ist, gibt es möglicherweise keine Möglichkeit, genau gleichzeitig eingefrorene Snapshots aller Volumes abzurufen. Wenn sich Ihre Datendateien und Ihr WAL-Protokoll beispielsweise auf unterschiedlichen Datenträgern befinden oder wenn sich Tablespaces auf unterschiedlichen Dateisystemen befinden, kann die Snapshot-Sicherung möglicherweise nicht verwendet werden, da die Snapshots gleichzeitig ausgeführt werden müssen. Lesen Sie die Dokumentation Ihres Dateisystems sorgfältig durch, bevor Sie in solchen Situationen der konsistenten Snapshot-Technik vertrauen.

HINWEIS: Ja, wir kennen andere Optionen, um sicherzustellen, dass sie konsistent sind, z. B. das Versetzen von PostgreSQL in den Hot-Backup-Modus oder die Verwendung der VMware-Integration unseres Speichers, um die VMs selbst in den Ruhezustand zu versetzen. Wir suchen jedoch nach einer Nur-Speicher-Lösung für Geschwindigkeit, Komfort und und keine Auswirkungen auf unsere Kunden.

postgresql storage virtualisation

— Steve R.
quelle

Ein Update - unser Speicheranbieter, Nimble Storage, kam heute zurück und sagte eindeutig, dass Snapshots, die als Teil einer Schutzgruppe aufgenommen wurden, tatsächlich über alle Volumes hinweg konsistent sind / genau zum gleichen Zeitpunkt aufgenommen wurden. Meine Frage ist daher zu diesem Zeitpunkt wirklich umstritten. Ich wäre jedoch immer noch interessiert, wenn jemand Kommentare hat, da Postgres in unseren Tests robust genug erscheint, um nicht gleichzeitig aufgenommene Schnappschüsse zu überleben.

— Steve R.

Was meinen Sie mit "Snapshot-Datenvolumen zuerst, Protokollvolumen ~ 1 Minute später"? Wenn sich sowohl Daten als auch Protokollvolumen in derselben Snapshot-Gruppe befinden, wird dies zur gleichen Zeit ausgeführt. Fügen Sie Daten und Protokollvolumen in eine Snapshot-Gruppe ein und führen Sie den Snapshot aus. Stellen Sie dann die Datenbank aus diesem Snapshot wieder her. Dies ist wie eine Wiederherstellung nach einem Instanzabsturz. Ich habe zuvor EMC Storage Based Backup mit Snapshot-Technologie für Oracle getestet. Es ist sehr zuverlässig.

— Fairybetty

Die von Ihnen zitierte Dokumentation sagt alles, aber ich würde Ihnen keine Vorwürfe machen, wenn Sie versuchen möchten, die Behauptungen des Anbieters in Bezug auf gleichzeitig aufgenommene Schnappschüsse zu überprüfen. Vielleicht könnte eine Möglichkeit, etwas aufzudecken, darin bestehen, das WAL-System genauer zu testen .

Versuchen Sie beispielsweise, zusätzlich zu Ihren pgbench-basierten Tests zufällige Aufrufe hinzuzufügen pg_switch_xlog(), um die Protokollrotation, kürzere und längere Prüfpunktintervalle (Verkürzen und Verlängern checkpoint_timeoutund checkpoint_timeout) zu erzwingen und sogar kleine oder große Wal-Dateigrößen zu verwenden.

Sofern mir nichts fehlt, würde ich Ihre wiederhergestellten DBs für Ihre nicht gleichzeitig aufgenommenen Schnappschüsse möglicherweise auf ein bisschen Glück zurückführen. Stellen Sie sich im letzten Fall vor, Sie hätten Ihren Protokoll-Snapshot erstellt, während der aktuelle xlog-Speicherort beispielsweise war 0/A1C0FFEE. Dann haben Sie 3 Minuten besonders hohe Last auf dem System, was einen vollständigen Zyklus durch die WAL-Dateien bewirkt, und Ihre 0/DEADBEEFDatenbank befindet sich jetzt, wenn der Datenschnappschuss erstellt wird. Wenn Sie versuchen, eine Wiederherstellung durchzuführen, sind die WAL-Dateien, in die zum Zeitpunkt des Daten-Snapshots geschrieben wurde, längst nicht mehr vorhanden, und die Wiederherstellung schlägt fehl.

— atomic77
quelle