Snapshot di archiviazione per un backup coerente di postgresql - diversi volumi di dati e log

Stiamo eseguendo molte VM Linux in un ambiente vmware / storage condiviso, ognuna con la propria istanza di postgreSQL (un mix di 9.0 e 9.3). Attualmente, l'intera VM si trova su una singola partizione / volume root e abbiamo avuto un grande successo (~ 8 anni) utilizzando snapshot basati su archiviazione dei volumi VMFS sottostanti per il processo di backup / ripristino (e replica sul nostro sito DR).

A causa dell'architettura del nostro archivio, sarebbe vantaggioso separare i file WAL di Postgres in un volume non memorizzato nella cache, per lo più in scrittura, per darci una minore quantità di cache sul lato dell'archiviazione. Con il nostro spazio di archiviazione (Nimble Storage), possiamo assegnare entrambi i volumi a un singolo gruppo di protezione / istantanea, ma non sono stato in grado di ottenere dal nostro fornitore che le istantanee avverranno ESATTAMENTE contemporaneamente su tutti i volumi del gruppo di protezione - probabilmente lo farà, ma c'è sempre quella possibilità che i suoi millisecondi di distanza.

A tal fine, abbiamo eseguito alcuni esperimenti, tutti durante la scrittura dei dati nel DB il più rapidamente possibile utilizzando pg_bench. Dopo gli esperimenti, abbiamo ripristinato i volumi delle nostre istantanee e avviato VM + postgres

• Istantanea di volumi di dati e di log vicini contemporaneamente - risultato: DB ripristinato
• Prima il volume dei dati dell'istantanea, il volume del registro ~ 1 minuto dopo - risultato: DB ripristinato
• Prima il volume del registro snapshot, il volume dei dati ~ 1 minuto dopo - risultato: DB ripristinato
• Prima il volume del registro snapshot, il volume dei dati ~ 3 minuti dopo, dopo che un checkpoint WAL ha scritto nuovi dati nei file di dati: risultato: DB ripristinato

Quindi i test sembrano dirci finché entrambe le istantanee sono coerenti a livello di volume e relativamente vicine tra loro, si ottiene una copia coerente del DB, in base al tempo dell'istantanea del volume WAL / Log.

La mia domanda: è sicuro? Quali sono i casi angolari che ci mancano nei nostri test e cosa potrebbe andare storto?

Il documento di Postgres indica che ciò non è sicuro, ma i test sembrano indicare che è piuttosto robusto: http://www.postgresql.org/docs/9.1/static/backup-file.html

Se il database è distribuito su più file system, potrebbe non esserci alcun modo per ottenere istantanee congelate esattamente simultanee di tutti i volumi. Ad esempio, se i file di dati e il registro WAL si trovano su dischi diversi o se i tablespace si trovano su file system diversi, potrebbe non essere possibile utilizzare il backup dell'istantanea poiché le istantanee devono essere simultanee. Leggi attentamente la documentazione del tuo file system prima di affidarti alla tecnica dell'istantanea coerente in tali situazioni.

NOTA: Sì, conosciamo altre opzioni per assicurarci che siano coerenti, come mettere PostgreSQL in modalità di backup a caldo o utilizzare l'integrazione VMware del nostro archivio per mettere in pausa le macchine virtuali stesse, ma stiamo cercando una soluzione di solo archiviazione per velocità, praticità, e zero impatto per i nostri clienti.

La documentazione che hai citato dice tutto, ma non ti biasimerei se vuoi provare a verificare i reclami del venditore in merito alle istantanee prese allo stesso tempo. Forse un modo per scoprire qualcosa potrebbe essere quello di sottoporre a stress test il sistema WAL in modo più specifico.

ad es. Oltre ai test basati su pgbench, prova ad aggiungere chiamate casuali pg_switch_xlog()per forzare la rotazione del registro, intervalli di checkpoint più brevi e più lunghi (accorciamento e allungamento checkpoint_timeoute checkpoint_timeout) e persino utilizzando file di dimensioni wal piccoli o grandi.

A meno che non manchi qualcosa, poiché le tue istantanee non sono state scattate contemporaneamente, attribuirò forse i tuoi DB recuperati a un po 'di tempismo fortunato. In quest'ultimo caso, immaginate avete preso l'istantanea di registro mentre l'attuale posizione xlog era, diciamo, 0/A1C0FFEE. Quindi hai 3 minuti di carico particolarmente pesante sul sistema, che provoca un ciclo completo attraverso i file WAL, e il tuo DB è ora 0/DEADBEEFquando viene acquisita l'istantanea dei dati. Quando si tenta di ripristinare, i file WAL in fase di scrittura al momento dell'istantanea dei dati scompaiono da tempo e il ripristino non riuscirà.