Re: Sauvegarde à chaud

From: Guillaume LELARGE <gleu(at)wanadoo(dot)fr>
To: pgsql-fr-generale(at)postgresql(dot)org
Cc: "CHARABOUSKA Christel" <christel(dot)charabouska(at)sesam-vitale(dot)fr>
Subject: Re: Sauvegarde à chaud
Date: 2005-09-16 22:32:21
Message-ID: 200509170032.22379.gleu@wanadoo.fr
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-fr-generale

Bonsoir,

Le Vendredi 16 Septembre 2005 18:48, CHARABOUSKA Christel a écrit :
> J'ai une ne question concernant la mise au point des procédures de
> sauvegarde à chaud. Comment gérer le fait que postgresQL ne constitue pas
> une sauvegarde cohérente ?

À moins que je n'ai loupé quelque chose, PostgreSQL crée une sauvegarde
cohérente. Le dump (pg_dump ou pg_dumpall) se fait à partir d'une version de
la base, version créée au lancement de la commande. Toute transaction
commencée pendant la sauvegarde ne sera pas pris en compte. En ce qui
concerne spécifiquement la sauvegarde à chaud, la reprise se fait jusqu'au
dernier point de vérification. Donc, à la rigueur, si une transaction se fait
sur la fin d'un fichier WAL et le début d'un autre, et que pour la
restauration vous ne possédez que le premier fichier WAL, cette dernière
"moitié" transaction ne sera pas rejouée. Non, je ne vois pas comment vous
pouvez obtenir une sauvegarde non cohérente. Peut-être avez-vous un cas à
nous soumettre ?

> Y a t il une "astuce" pour déterminer le fichier
> WAL en cours de rermplissage?

Pas directement à ma connaissance. Ceci étant dit, vous connaissez les
fichiers WAL archivés. Trouver le fichier WAL non archivé ne devrait pas être
trop difficile.

> N'y at-il pas un risque de ne pas pouvoir
> resconstruire la BD si tous les fichiers archives ne sont pas présents ?

Pas à ma connaissance. En fait, les requêtes sont exécutées jusqu'au dernier
point de vérification. Prenons un premier exemple : j'ai archivé trois
fichiers WAL. La base de données commence à enregistrer une transaction sur
le 4è et finit l'enregistrement des données de cette transaction sur le 5è
fichier WAL. Le 4è étant fini, il est archivé. Arrive un plantage de la
machine avant la fin du 5è fichier WAL (donc avant son archivage). Je
restaure la base avec mon dump et mes quatre fichiers WAL... En fait,
PostgreSQL va récupérer l'intégralité des requêtes des trois premiers
fichiers WAL et une partie du 4è. En fait il va s'arrêter au dernier point de
vérification. Donc, ma dernière transaction ne sera pas prise en compte car
la fin de la transaction s'est fait sur le 5è fichier WAL perdu après le
plantage.

Prenons un autre exemple. J'ai 5 fichiers WAL et je perds le 4è. PostgreSQL va
rejouer les requêtes jusqu'au dernier point de vérification du 3è fichier.

(une petite note pour dire que je simplifie un peu le processus, rien ne dit
que le dernier point de vérification se trouve sur le dernier fichier...)

Comme PostgreSQL ne tient compte que des points de vérification, les bases de
données sont restaurées dans un état cohérent. Attention, cela ne veut pas
dire que vous êtes assuré de récupérer vos données jusqu'à avant le crash
mais au moins vous êtes sûr d'avoir un système cohérent (en terme de respect
des contraintes et des données).

> Extrait de la doc des sauvegardes.
> "Gardez en tête que seuls les fichiers WAL complets sont archivés, donc il
> y aura un délai entre l'exécution de pg_stop_backup et l'archivage de tous
> les fichiers de segment WAL pour rendre la sauvegarde du système de
> fichiers cohérente. "
>

J'ai peut-être mal traduit ce passage. Je vais vérifier cela ce week-end.

--
Guillaume.
<!-- http://abs.traduc.org/
http://lfs.traduc.org/
http://traduc.postgresqlfr.org/ -->

In response to

Browse pgsql-fr-generale by date

  From Date Subject
Next Message david techer 2005-09-18 00:00:54 Documentation PostgreSQL/PostGIS sous Windows - Demande de relecture -
Previous Message CHARABOUSKA Christel 2005-09-16 16:48:22 Sauvegarde à chaud