Vous n'êtes pas identifié(e).
Pages : 1
Bonjour à tous...
Afin d'archiver mes logs je me sers de la doc postgres 9.1.3 (chapitre 24.3.5) => http://docs.postgresqlfr.org/9.1/contin … iving.html
Dans ce document il est indiqué comment archiver ses WAL en vue d'une récupération => Ok
J'ai modifié les variable : archive_mode, wal_level du postgrès.conf comme il faut => Ok
Pour la variable archive_command, j'ai une petite question à vous poser : Si j'ai bien compris, la ligne : archive_command = 'test ! -f /var/lib/pgsql/backup_in_progress || (test ! -f /var/lib/pgsql/archive/%f && cp %p /var/lib/pgsql/archive/%f)' teste si le fichier backup_in_progress existe et ensuite enclenche l'archivage => ok ?
Si j'ai toujours compris le truc, le fichier 'backup_in_progress' est créé lors d'une sauvegarde de type :
touch backup_in_progress
pg_start_backup
tar de mes données de la base 'repertoire base'
pg_stop_backup
etc...
plusieurs questions :
1°) Me trompe-je si je dis que l'archivage des Wal ne sera effectué que dans le cas d'une sauvegarde des données ? Et pourquoi ce genre de choix...
2°) Pourquoi tout simplement ne pas implémenter dans archive_command : cp /repertoire/pg_xlog /repertoire/sauvegarde_des_xlog qui envoie les wal dans un autre répertoire, au jour le jour, et faire toute les semaines un :
pg_start_backup
tar des données de la base
pg_stop_backup
Ainsi ce serait comme un scénario rman : d'une fois par semaine un dump complet et tous les jours de la semaine des wal envoyées comme des incrémentales...
3°) Et vous, qu'avez-vous choisi pour vos bases en archivelog on (excusez si je parle oracle !) ... avez-vous implémenté un shell dans archive_command et pouvez-vous m'en donner un exemple...
4°) Après avoir archivé vos wal, les deletez-vous du repertoire pg_xlog ?
Merci pour vos réponses...
Hors ligne
Bonjour.
Comme indiqué dans la doc, ce genre d'implémentation est utilisé pour réaliser des sauvegardes autonomes. C'est à dire une copie du répertoire data ainsi que les wal générés durant la sauvegarde à chaud. Cela évite d'avoir à supprimer les wal copiés lors du archvie_command s'ils ne sont pas utiles (ex: pas de réplication).
Personnellement, j'ai un serveur en streaming réplication. Je sauvegarde tous les wal sur une ressource externe partagée sur mes 2 serveurs, et je supprime les wal copiés périodiquement (archive_cleanup_command).
Il ne faut pas vider le répertoire pg_xlog manuellement, postgres s'en occupe, et cela se configure dans le fichier postgresql.conf
Dernière modification par rjuju (15/05/2012 13:32:16)
Julien.
https://rjuju.github.io/
Hors ligne
1. Oui, vous vous trompez. L'archivage des journaux de transactions se met en place pour de la sauvegarde autonome, mais aussi pour de la réplication.
2. C'est généralement comme ça qu'on l'utilise (à part que les journaux sont sauvegardées une fois qu'ils sont terminées, et non pas une fois par jour).
3. Généralement, un simple scp suffit mais il est possible de faire des scripts plus avancés, surtout si on veut copier vers plusieurs serveurs. Quelques exemples, omnipitr, pitrtools, pitrery.
4. Surtout pas. PostgreSQL s'en charge. Vous ne devez jamais modifier ou supprimer des fichiers du répertoire pg_xlog.
Guillaume.
Hors ligne
merci rjuju...
Je n'ai pas bien compris la phrase : Cela évite d'avoir à supprimer les wal copiés lors du archvie_command s'ils ne sont pas utiles (ex: pas de réplication).
1°) Ce que j'ai du mal à comprendre, c'est que l'archivage des wal (exemple du chapitre 24.3.5) n'est effectuée qu'avec une sauvegarde pg_start et pg-stop_backup... or, si ce genre de sauvegarde ne se fait qu'une fois la journée, les wal ne sont archivés et sauvegardés qu'une seul fois dans la journée... et cela implique qu'à chaque fois que l'on veut archiver les wal, il faut faire un pg_start, copie et pg_stop backup...
Me trompe-je ? Et quel est l’intérêt d'une telle manœuvre ?
2°) Le scénario 2°) (avec cp des répertoire source vers cible, des wal) de mon premier mail est-il de bon aloi ?
3°) Je trouve la doc pas très claire... pour moi, le paramètre archive_cleanup_command ne doit être implémenté que sur le serveur esclave afin de virer les vieux wal, qui ont été transféré et utilisés par la database en standby... suis-je neuneu ?
Merci encore pour vos réponses
Hors ligne
1)
Le pg_start_backup et pg_stop_backup permettent de faire une sauvegarde à chaud du répertoire data de postgresql. Pour que ces fichiers soient utilisables, il faut avoir les wal générés durant cette copie.
Dans le cas d'une sauvegarde autonome c'est le minimum requis, et c'est pourquoi dans ce cas les wal ne sont pas archivés en dehors de ce cadre mais uniquement entre le pg_start_backup et le pg_stop_backup.
Mais l'archivage des wal permet d'autres opérations, comme de la réplication en log_shipping ou de la sauvegarde PITR. Tout dépend de ce que vous voulez faire.
2)
Votre scénario 2 correspond à une sauvegarde PITR (paragraphe 24.3 dans votre lien). Ca fonctionne parfaitement, il faut juste penser à supprimer les wal antérieurs à la nouvelle sauvegarde du répertoire data. La sauvegarde PITR permet une très grande souplesse sur la restauration mais est beaucoup plus gourmande en espace disque.
3)
Oui, le archive_cleanup_command sert à ça. C'était dans le cadre de mon utilisation personnelle du archive_command pour de la réplication et non pour de la sauvegarde, désolé pour la confusion.
Dernière modification par rjuju (15/05/2012 15:33:05)
Julien.
https://rjuju.github.io/
Hors ligne
1°) Ok pour vos explications, mais ce genre de sauvegarde n'est-elle pas un peu 'dangereuse' dans le sens où je ne ferai qu'une sauvegarde pg_start_backup/cp/pg_stop_backup , par semaine... et donc en cas de catastrophe entre les deux (imaginons le répertoire pg_xlog qui ne soit plus accessible) je ne pourrai que revenir 1 semaine en arrière... me trompe-je ?
2°) Sauvegarde par scénario 2 => Comment supprimer les wal qui ont été sauvegardées
3°) Nous avons, comme je l'ai précisé plus haut, deux databases en log shipping... les logs sont donc envoyées entre le maître et l'esclave => OK .. dans le cas d'un switch entre les deux serveurs, pour que les sauvegardes continuent, il faudra mettre l'équivalent du postgrès.conf du maître sur le serveur esclave non ?
Hors ligne
1) Non c'est exactement ça. Ce genre de sauvegarde est plutôt à envisager pour pouvoir mettre en place une réplique d'une instance postgres rapidement sur demande.
Si vous voulez restaurer jusqu'à quelques minutes avant l'incident, il faut stocker tous les wal. Vous devez donc vous assurer que vous avez assez d'espace disque pour stocker une semaine entière de wal (la taille dépend de l'activité sur votre base). Il faut aussi prendre en compte le temps nécessaire pour rejouer tous ces wal lors d'une reprise sur incident.
2) Vous pouvez supprimer tous les wal sauvegardés avant d'effectuer la nouvelle sauvegarde, ceux-ci ne seront plus utiles une fois la sauvegarde effectuée, sauf s'ils sont utilisés ailleurs, comme pour votre réplication, auquel cas il faut faire attention qu'ils ne soient pas requis. Si vous n'avez pas de problème de place, il serait peut-être plus simple de sauvegarder vos wal sur 2 endroits différents selon l'utilité.
3) Oui
Dernière modification par rjuju (15/05/2012 17:43:16)
Julien.
https://rjuju.github.io/
Hors ligne
Merci rjuju...
La réplication étant en ce qui nous concerne, presque instantanée, je pense que nous allons nous orienter vers le schéma suivant :
Sauvegarde du répertoire 'base' tous les dimanche : (pg_stop_backup, copie du répértoire 'base' complet, pg_start_backup) en job de nuit...
Sauvegardes des wal tous les jours à intervalles réguliers ...
Question 1°) : Pour la sauvegarde full, celle du répertoire 'base' suffit-elle ou bien englobez-vous, en général, d'autres répertoires ?
Question 2°) : Suivant votre expérience, à quel intervalle sauvegardez-vous vos wal ?
Merci encore pour vos réponses
Hors ligne
Sauvegarde du répertoire 'base' tous les dimanche : (pg_stop_backup, copie du répértoire 'base' complet, pg_start_backup) en job de nuit...
C'est l'inverse (start, copie du répertoire des données et des tablespaces, stop).
Question 1°) : Pour la sauvegarde full, celle du répertoire 'base' suffit-elle ou bien englobez-vous, en général, d'autres répertoires ?
Non, il faut sauvegarder tout ce qui se trouve dans le répertoire des données de PostgreSQL (généralement lié à la variable PGDATA) et les tablespaces.
Question 2°) : Suivant votre expérience, à quel intervalle sauvegardez-vous vos wal ?
Il n'y a pas d'intervalle à donner, c'est PostgreSQL qui s'en occupe automatiquement.
Guillaume.
Hors ligne
Pages : 1
