Forums PostgreSQL.fr

jp

Membre

Conseils et avis: Politique de sauvegarde et restauration.

Bonjour à tous,
Je possede en production 1 cluster linux (HB -drbd) de 2 serveurs. Celui ci heberge 4 cluster postgresql.
Chaque noeud du cluster linux est actif et possede un cluster postgres 8.3 et un cluster postgres 8.4.
Pour plus de lisibilité je les nomerais pgprod1, pgprod2, pgprod3 et pgprod4.
Sur le premier noeud de mon cluster linux se trouve pgprod1 et pgprod3.
Sur pgprod3 il y a 7 BD dont 2 de plus de 150 Go repartie dans 3 tablespace.
Un tablespace postgres correspond à un logical volume sur le serveur.
Les deux plus grosse base ont un tablespace à elles.
Les sauvegardes sont effectués de 2 façons: un pg_dump et un tar des fichiers des bases ( associé au fonction pg_start_backup et pg_stop_backup).
Il va sans dire que les archives logs sont parametrés.
voici pour la config.
La problemeatique:
Lors de la restauration total d'une base de 150 Go, celle ci se passe tres bien mais elle dure 5 heures (pg_restore).
Pour reduire le temps je desactive les archiveslogs et l'autovacuum le temps de la restauration. Mais cette operation m'oblige à redemarrer pgprod3 ce qui cause de l'indisponibilité pour mes autres bases.
Autre problematique durant le tar je verouille l'acces aux bases (ALTER ROLE user NOLOGIN) pour etre sur que la base ne sera pas modifier durant la sauvegarde. Ce qui cause aussi une indisponibilité la nuit.

Questions:
Les fichiers de bases etant dans un logical volume, un snapshot lvm pourrait il remplacer le NOLOGIN ?
Lors d'une restauration puis je restaurer uniquement les fichiers de base d'un tablespace (celui de la base concernée) et rejouer les archiveslogs (meme si ceux ci sont commun à toutes les bases ? ce n'est pas une vraie question car selon la doc ce n'est pas possible, je souhaite seulement votre avis.
Pensez vous que pour les grosses bases (>100 Go) l'utilisation d'un cluster postgresql dédié soit LA solution ?
Pensez vous que je devrais penser à migrer vers la version 9 de postgres et utiliser la replication ? (active/standby).
Pensez vous que je devrais revoir ma politique de sauvegarde/restauration ? Utiliser un autre outil ? je pense particulierement au projet pg-rman.

Je suppose que plusieurs personnes sur ce forum utilisent des bases plus grosses que les miennes. Comment faites vous pour sauvegarder/restaurer ? avez vous des contraintes de temps de restauration et si oui comment optimisez vous vos sauvegardes/restauration.

Désolé pour la longueur du post, j'ai essayé de faire le plus clair et concis possible.
Merci pour vos réponses, avis et conseils.

Jean-Philippe

Marc Cousin

Membre

Re : Conseils et avis: Politique de sauvegarde et restauration.

- Les fichiers de bases etant dans un logical volume, un snapshot lvm pourrait il remplacer le NOLOGIN ?
Non: les fichiers des tablespaces sont dépendants du catalogue système. On ne peut pas restaurer des fichiers de données d'un tablespace sans restaurer l'ensemble de la base.

- Lors d'une restauration puis je restaurer uniquement les fichiers de base d'un tablespace (celui de la base concernée) et rejouer les archiveslogs (meme si ceux ci sont commun à toutes les bases ? ce n'est pas une vraie question car selon la doc ce n'est pas possible, je souhaite seulement votre avis.
Non

- Pensez vous que pour les grosses bases (>100 Go) l'utilisation d'un cluster postgresql dédié soit LA solution ?
C'est la seule en tout cas. Cela te permettra de restaurer cette base individuellement, sans passer par pg_dump. Une base de 100Go ou plus est trop grosse pour être sauvegardée/restaurer par ce moyen (du moins dans un temps réaliste).

- Pensez vous que je devrais penser à migrer vers la version 9 de postgres et utiliser la replication ? (active/standby).
Ça n'apportera rien, pour les sauvegardes: ça ne résoudra pas le problème de restaurer une base séparément des autres.

- Pensez vous que je devrais revoir ma politique de sauvegarde/restauration ? Utiliser un autre outil ? je pense particulierement au projet pg-rman.
pg_rman n'est pas encore vraiment au point.
Par contre, oui, il faut revoir la politique de sauvegarde, et faire des sauvegardes fichier (avec pg_start_backup et pg_end_backup). Et éclater les bases dans différents clusters, si tu souhaites pouvoir les restaurer séparément.

---

Marc.

jp

Membre

Re : Conseils et avis: Politique de sauvegarde et restauration.

Merci pour ces reponses.
Je pense que j'ai un peu de boulot maintenant ;-)

Marc Cousin

Membre

Re : Conseils et avis: Politique de sauvegarde et restauration.

Quelques réunions, un peu de gestion du changement. La routine quoi

---

Marc.