Vous n'êtes pas identifié(e).
J'ai trouvé !
En fait, vous me l'aviez déjà dit : il faut que TOUS les repertoires du serveur maitre soient rsynqués vers le serveur esclave... ça fonctionne !
Le problème est que je ne travaille pas à temps complet sur ce projet...
Merci encore pour vos réponses..
Bonjour à tous...
Pour plus d'infos, j'ai reconstitué l'esclave avec un rsync des répertoires 'pg_xlog' et 'base' du nouveau maître vers le nouvel esclave... Mais le problème est que, quand je suis sur mon nouvel esclave, le pg_start_backup ne fonctionne pas car il me dit que mon nouvel esclave est en cours de démarrage (voir la log du message précédent avec le timeline !)... et donc je ne peux pas faire, comme sur le post : 'Mise en place de la réplication avec PostgreSQL 9.0 - 2/2' => pg_start_backup, cp (ici je fais un rsync) et pg_stop_backup... est-ce la raison de mon problème ?
Merci encore pour vos réponses...
Désolé, j'ai envoyé le message un peu vite...
Lors de l'ouverture de mon slave j'ai effectivement :
Jun 14 14:18:31 vpfdipsql1 postgres[23515]: [2-1] LOG: received fast shutdown request
Jun 14 14:18:31 vpfdipsql1 postgres[23525]: [2-1] LOG: shutting down
Jun 14 14:18:31 vpfdipsql1 postgres[23525]: [3-1] LOG: database system is shut down
Jun 14 14:31:47 vpfdipsql1 postgres[23628]: [1-1] LOG: could not create IPv6 socket: Address family not supported by protocol
Jun 14 14:31:47 vpfdipsql1 postgres[23637]: [2-1] LOG: database system was shut down in recovery at 2012-06-14 14:18:31 CEST
Jun 14 14:31:47 vpfdipsql1 postgres[23637]: [3-1] LOG: entering standby mode
Jun 14 14:31:47 vpfdipsql1 postgres[23637]: [4-1] LOG: redo starts at A9/79001FC8
Jun 14 14:31:47 vpfdipsql1 postgres[23637]: [5-1] LOG: consistent recovery state reached at A9/7B000000
Jun 14 14:31:47 vpfdipsql1 postgres[23637]: [6-1] LOG: unexpected pageaddr A9/6E000000 in log file 169, segment 123, offset 0
Jun 14 14:31:47 vpfdipsql1 postgres[23639]: [2-1] FATAL: timeline 2 of the primary does not match recovery target timeline 1
Jun 14 14:31:52 vpfdipsql1 postgres[23645]: [2-1] FATAL: timeline 2 of the primary does not match recovery target timeline 1
il semble dire qu'à partir du A9/7B000000 la restauration peut s'effectuer => OK
Mais qu'il y a un problème sur une page adresse A9/6E00000 => ok
Or voici le pg_xlog du serveur que je veux starter (qui d'ailleurs a été rsyncé avec le serveur maître=> pg_xlog identiques)
drwx------. 17 postgres postgres 4096 Jun 14 14:32 ..
drwx------. 3 postgres postgres 20480 Jun 14 14:30 .
-rw-------. 1 postgres postgres 16777216 Jun 14 14:30 00000002000000A90000008B
-rw-------. 1 postgres postgres 16777216 Jun 14 14:30 00000002000000A90000008C
drwx------. 2 postgres postgres 20480 Jun 14 14:30 archive_status
-rw-------. 1 postgres postgres 16777216 Jun 14 14:01 00000002000000A90000008A
-rw-------. 1 postgres postgres 293 Jun 14 14:01 00000002000000A90000008A.00000020.backup
-rw-------. 1 postgres postgres 16777216 Jun 14 13:56 00000002000000A900000089
-rw-------. 1 postgres postgres 16777216 Jun 13 12:38 00000002000000A900000088
-rw-------. 1 postgres postgres 16777216 Jun 12 10:12 00000002000000A900000087
-rw-------. 1 postgres postgres 16777216 Jun 12 10:12 00000002000000A900000086
-rw-------. 1 postgres postgres 16777216 Jun 12 10:05 00000002000000A900000085
-rw-------. 1 postgres postgres 16777216 Jun 12 10:02 00000002000000A900000084
-rw-------. 1 postgres postgres 16777216 Jun 12 10:00 00000002000000A900000083
-rw-------. 1 postgres postgres 16777216 Jun 12 09:56 00000002000000A900000082
-rw-------. 1 postgres postgres 16777216 Jun 12 09:54 00000002000000A900000081
-rw-------. 1 postgres postgres 16777216 Jun 1 17:15 00000002000000A900000080
-rw-------. 1 postgres postgres 16777216 Jun 1 16:37 00000002000000A90000007F
-rw-------. 1 postgres postgres 16777216 Jun 1 16:15 00000002000000A90000007E
-rw-------. 1 postgres postgres 16777216 Jun 1 16:13 00000002000000A90000007D
-rw-------. 1 postgres postgres 16777216 Jun 1 16:10 00000002000000A90000007C
-rw-------. 1 postgres postgres 16777216 Jun 1 15:57 00000002000000A90000007B
-rw-------. 1 postgres postgres 16777216 Jun 1 12:16 00000002000000A90000007A
-rw-------. 1 postgres postgres 56 Jun 1 12:16 00000002.history
-rw-------. 1 postgres postgres 16777216 Jun 1 11:29 00000001000000A90000007A
-rw-------. 1 postgres postgres 16777216 Jun 1 11:17 00000001000000A900000079
-rw-------. 1 postgres postgres 16777216 Jun 1 10:17 00000001000000A900000078
-rw-------. 1 postgres postgres 16777216 Jun 1 09:17 00000001000000A900000084
-rw-------. 1 postgres postgres 16777216 Jun 1 08:17 00000001000000A900000083
-rw-------. 1 postgres postgres 16777216 Jun 1 07:17 00000001000000A900000082
-rw-------. 1 postgres postgres 16777216 Jun 1 06:17 00000001000000A900000081
-rw-------. 1 postgres postgres 16777216 Jun 1 05:17 00000001000000A900000080
-rw-------. 1 postgres postgres 16777216 Jun 1 04:17 00000001000000A90000007F
-rw-------. 1 postgres postgres 16777216 Jun 1 03:17 00000001000000A90000007E
-rw-------. 1 postgres postgres 16777216 Jun 1 02:17 00000001000000A90000007D
-rw-------. 1 postgres postgres 16777216 Jun 1 01:17 00000001000000A90000007C
-rw-------. 1 postgres postgres 16777216 Jun 1 00:17 00000001000000A90000007B
Soit des log 000000001nnnn et des logs 0000002nnn .
1°) Question : Ou se trouve ma A9/6E000000 que je ne vois pas dans mon pg_xlog ...
2°) les timelines définissent-elles les 0000001nn (pour timeline 1) et 000002nn (pour les timeline2
3°) Comment m'en sortir ?
Merci pour vos réponses...
Merci encore pour vos réponses...
en fait, mon esclave n'était pas bien configuré...
J'en encore une petite erreur sur mon NouveaEsclave ... il starte correctement mais la log me rends un message du type :
Jun 13 16:28:20 vpfdipsql1 postgres[16616]: [2-1] FATAL: timeline 2 of the primary does not match recovery target timeline 1
Jun 13 16:28:25 vpfdipsql1 postgres[16617]: [2-1] FATAL: timeline 2 of the primary does not match recovery target timeline 1
et je n'ai pas réussi à comprendre sur les posts, si ce problème était grave...
Pouvez-vous encore m'aider en m'expliquant le truc ?
Merci pour vos explications... je comprends mieux maintenant .. moi qui croyait que seuls les WAL basculés d'un serveur à l'autre suffiraient à remettre le bazar en marche, je me suis bien trompé ... ok aussi pour le archive_command, son emplacement était géré par 'root' et donc je ne pouvais pas écrire dessus...
Maintenant j'ai une autre erreur sur mon NouveauMaitre... en effectuant un stop (Ok) et un start (non Ok)de l'instance, le start part en 'failure' et me répond ceci dans ma log...
Jun 13 13:50:48 vpfdipsql2 postgres[16626]: [2-1] LOG: could not create IPv6 socket: Address family not supported by protocol
Jun 13 13:50:48 vpfdipsql2 postgres[16626]: [3-1] WARNING: could not create listen socket for "*"
Jun 13 13:50:48 vpfdipsql2 postgres[16626]: [4-1] FATAL: could not create any TCP/IP sockets
Pouvez-vous m'expliquer pourquoi ?
Merci encore ...
Rebonjour à tous...
je reprends mon post pour vous dire que j'ai bien fait ce qu'il fallait et que ça ne fonctionne toujours pas :
J'ai effectué sur mon NouveauMaitre : pg_start_backup/rsync des xlog (vers l'esclave)/pg_stop_backup
premièrement le pg_stop backup ne s'arrête pas et me rend :
NOTICE: pg_stop_backup cleanup done, waiting for required WAL segments to be archived
WARNING: pg_stop_backup still waiting for all required WAL segments to be archived (60 seconds elapsed)
HINT: Check that your archive_command is executing properly. pg_stop_backup can be canceled safely, but the database backup will not be usable without all the WAL segments.
Mais, me suis-je dit, étant donné que les wal sont passés du coté de mon NouvelEsclave, je peux restarter mon nouvealEsclave afin qu'il fonctionne... et bé non, il semblerait qu'il lui manque des wal (mais lequels ?) !
Voici ce que me dit mon fichier log dans /var/log/ :
LOG: could not create IPv6 socket: Address family not supported by protocol
Jun 12 10:17:40 vpfdipsql1 postgres[8116]: [2-1] LOG: database system was shut down in recovery at 2012-06-12 10:16:59 CEST
Jun 12 10:17:40 vpfdipsql1 postgres[8116]: [3-1] LOG: entering standby mode
Jun 12 10:17:40 vpfdipsql1 postgres[8116]: [4-1] LOG: redo starts at A9/79001FC8
Jun 12 10:17:40 vpfdipsql1 postgres[8116]: [5-1] LOG: consistent recovery state reached at A9/7B000000
Jun 12 10:17:40 vpfdipsql1 postgres[8116]: [6-1] LOG: unexpected pageaddr A9/6E000000 in log file 169, segment 123, offset 0
Jun 12 10:17:40 vpfdipsql1 postgres[8118]: [2-1] FATAL: timeline 2 of the primary does not match recovery target timeline 1
Jun 12 10:17:45 vpfdipsql1 postgres[8122]: [2-1] FATAL: timeline 2 of the primary does not match recovery target timeline 1
Jun 12 10:17:50 vpfdipsql1 postgres[8123]: [2-1] FATAL: timeline 2 of the primary does not match recovery target timeline 1
Jun 12 10:17:51 vpfdipsql1 postgres[8107]: [2-1] LOG: received fast shutdown request
Suis-je clair..
Merci pour vos réponses...
Je voulais tester un 'switchover'... car imaginons une panne d'une heure sur le ServeurMaître sans crash de disque... juste un problème par exemple de database arrétee (pour diverses raisons !) sur mon AncienMaitre...
Je switche l'AncienEsclave en NouveauMaitre => OK
J'effectue des m.a.j sur le NouveauMaitre => OK
Et je voulais au bout d'une heure, 'rallumer' le NouvelEsclave (AncienMaitre) afin que les modifications effectuées sur le NouveauMaitre puissent être envoyées via les WAL, sur le NouvelEsclave...
Vous semblez me dire que ce n'est pas possible et qu'il faut, à chaque fois et quelle que soit la panne, restaurer le NouvelEsclave avant de repartir... mais alors, cela implique que pendant la restauration du NouvelEsclave, il faut arrêter le NouveauMaitre, sous peine qu'il y ait des modifications dessus et qu'il faille recommencer la restauration... non ?
Vous voulez un cachet d'aspirine ?
Merci...
1°) mais alors, cela veut dire que s'il y a un switch entre serveurs (et qu'il y a eu des m.a.j sur le nouveau maître), on est obligé d'effectuer une restauration sur le nouvel esclave(à partir d'un backup du nouveau maître), avant de le remettre en route ...
Moi qui croyait que le simple fait de réallumer le nouvel esclave, reprenait les wal du nouveau maître et repartait comme en l'an 40 en tant qu'esclave... je me suis bien trompé !!!
Ai-je raison dans ma première affirmation 1°)
Autre chose : Quel WAL manque t'il dans pg_xlog ? Que veut dire A9/19000000 in log file 169 ?
Bonjour...
j'ai effectué le switch en :
- Arrêtant le serveurMaitre
- Création du fichier trigger_ha' pour que mon esclave devvienne le maître (ce qui a fait passer mon recovery.conf en recovery.done)
- J'ai ensuite effectué des m.a.j sur mon NouveauMaitre
- J'ai rallumé l'ancien ServeurMaitre pour qu'il deviene mon nouveau ServeurEsclave (evec le recovery.conf qui va bien !)
- Je pensais que les WAL de mon NouveauMaître seraient interceptées NouvauEsclave et que cela continuerait comme ça...
Questions :
1°) N'est-ce pas ce qu'il faut faire quand il y a une panne sur le serveur maitre, afin de passer sur l'esclave (comme le dit la doc d'ailleurs !)?
2°) Comment m'en sortir maintenant si je n'ai pas de dump ?
merci pour vos réponses...
Bonjour à tous...
j'ai deux serveurs en streaming :
1°) Arrété mon ancienMAitre
2°) effectué un switch entre mon AncienMaitre et mon NouveauMaitre => OK
3°) Effectué des mises à jours sur mon nouveauMaitre => OK
4°) 'Ralumé' AncienMaître afin qu'il devienne NouvelEsclave avec recovery.conf => OK
5°) Quand je starte mon nouvel esclave voici l'erreur qu'il me renvoie :
Jun 6 11:54:50 vpfdipsql1 postgres[31151]: [2-1] LOG: received fast shutdown request
Jun 6 11:54:50 vpfdipsql1 postgres[31161]: [2-1] LOG: shutting down
Jun 6 11:54:50 vpfdipsql1 postgres[31161]: [3-1] LOG: database system is shut down
Jun 6 11:54:52 vpfdipsql1 postgres[31337]: [1-1] LOG: could not create IPv6 socket: Address family not supported by protocol
Jun 6 11:54:52 vpfdipsql1 postgres[31346]: [2-1] LOG: database system was shut down in recovery at 2012-06-06 11:54:50 CEST
Jun 6 11:54:52 vpfdipsql1 postgres[31346]: [3-1] LOG: entering standby mode
Jun 6 11:54:52 vpfdipsql1 postgres[31346]: [4-1] LOG: redo starts at A9/79001FC8
Jun 6 11:54:52 vpfdipsql1 postgres[31346]: [5-1] LOG: consistent recovery state reached at A9/7B000000
Jun 6 11:54:52 vpfdipsql1 postgres[31346]: [6-1] LOG: unexpected pageaddr A9/19000000 in log file 169, segment 123, offset 0
Jun 6 11:54:52 vpfdipsql1 postgres[31348]: [2-1] FATAL: timeline 2 of the primary does not match recovery target timeline 1
Jun 6 11:54:57 vpfdipsql1 postgres[31354]: [2-1] FATAL: timeline 2 of the primary does not match recovery target timeline 1
Je suppose que le nouvel esclave attend un Wal de mon nouveau maitre (qui a eu des mises à jour)...
Voici les wal de mon NouveauMaitre :
-rw-------. 1 postgres postgres 16777216 Jun 1 10:17 00000001000000A900000078
-rw-------. 1 postgres postgres 16777216 Jun 1 11:17 00000001000000A900000079
-rw-------. 1 postgres postgres 16777216 Jun 1 11:29 00000001000000A90000007A
-rw-------. 1 postgres postgres 16777216 Jun 1 00:17 00000001000000A90000007B
-rw-------. 1 postgres postgres 16777216 Jun 1 01:17 00000001000000A90000007C
-rw-------. 1 postgres postgres 16777216 Jun 1 02:17 00000001000000A90000007D
-rw-------. 1 postgres postgres 16777216 Jun 1 03:17 00000001000000A90000007E
-rw-------. 1 postgres postgres 16777216 Jun 1 04:17 00000001000000A90000007F
-rw-------. 1 postgres postgres 16777216 Jun 1 05:17 00000001000000A900000080
-rw-------. 1 postgres postgres 16777216 Jun 1 06:17 00000001000000A900000081
-rw-------. 1 postgres postgres 16777216 Jun 1 07:17 00000001000000A900000082
-rw-------. 1 postgres postgres 16777216 Jun 1 08:17 00000001000000A900000083
-rw-------. 1 postgres postgres 16777216 Jun 1 09:17 00000001000000A900000084
-rw-------. 1 postgres postgres 16777216 Jun 1 12:16 00000002000000A90000007A
-rw-------. 1 postgres postgres 16777216 Jun 1 15:57 00000002000000A90000007B
-rw-------. 1 postgres postgres 16777216 Jun 1 16:10 00000002000000A90000007C
-rw-------. 1 postgres postgres 16777216 Jun 1 16:13 00000002000000A90000007D
-rw-------. 1 postgres postgres 16777216 Jun 1 16:15 00000002000000A90000007E
-rw-------. 1 postgres postgres 16777216 Jun 1 16:37 00000002000000A90000007F
-rw-------. 1 postgres postgres 16777216 Jun 1 17:15 00000002000000A900000080
-rw-------. 1 postgres postgres 16777216 Jun 6 11:55 00000002000000A900000081
-rw-------. 1 postgres postgres 56 Jun 1 12:16 00000002.history
Quel wal attend mon Nouvel esclave (A9/19000000 in log file 169 !!!!) ... et pourquoi ce plantage ?
Merci pour vos réponses...
Ok ... merci à vous !
Merci pour votre réponse...
Si j'ai bien compris, en général, s'il y a un problème sur l'un des deux serveurs, il faut reconstruire les deux serveurs non ?
Bonjour à tous...
Nous avons deux databases maitre/esclave en streaming réplication => OK
Nous passons un traitement batch tous les soirs sur le serveur maître et qui duplique (via la streaming) sur le serveur esclave => OK
Imaginons un gros problème après ce batch genre : mauvais fichier en entrée qui vérole 2 grosses tables et nous oblige à restaurer l'instance maître d'avant le passage du batch => OK
1°) Imaginons la restauration sur le serveur (écrasement des répertoire de l'instance du serveur maître avec le fichier basemaitre.tar.gz et 'rejouage' des Wal)... ma grande question est la suivante : Qu'est-ce qu'il se passe sur le serveur esclave ... faut-il :
- couper la 'réplication' entre le maître et l'esclave
- écraser les répertoires de l'esclave par la sauvegarde de l'instance basemaitre.tar.gz
- remettre la 'réplication' entre maître et esclave
- Effectuer la restauration du serveur maître qui, grâce à la réplication revenue, effectuera aussi la restauration de l'esclave...
Si je suis assez clair, pouvez-vous me répondre ?
Merci d'avance...
Ok pour le drop malheureux... c'est vrai que cela n'arrive pas tous les jours... jusqu'au jour où !
Bref, mon problème sur les dumps réguliers est que ma database fait 90 Gigas... et donc nous préférerions une formule comme start-cp-stop backup avec les wal à rejouer...
Je reprends ma question 1 : ais-je bien compris si je dis que Le pg_create_restore_point() pourrait donc être effectué disons toutes les heures, pendant la journée de travail... en cas de restauration je pourrai ensuite choisir le point de synchro voulu ?
Merci rjuju pour vos explications...
Je trouve cela néanmoins pas très souple... car recharger complètement un environnement et ensuite rejouer les wal archivés pour par exemple, un drop malheureux sur une table, est très lourd a gérer...
Y aura t'il dans les versions suivantes de postgres quelques améliorations sur ce genre de problème ?
dans le paragraphe (ce maton => ...) C'était drop de la base TITI que je voulais écrire (donc de la plus petite )
je suis en train de tester une restauration de database...
Le contexte : 1 instance avec deux databases TOTO (80 gigas) et TITI (200 Méga)
Hier soir :
pg_start_backup
cp de mes repertoire 'base' (fichier base.tar.gz ) et du répertoir x_log (xlog.tar.gz) donc 2 fichiers...
pg_stop_backup
Ce matin => Drop de la base toto
Cet aprèm => Je voudrais restaurer avant le drop de TITI donc la plus petite base => ok
1°) Dans la doc postgrès, ils parlent de : pg_create_restore_point()... je n'ai pas compris pourquoi... faut-il l'exécuter en même temps que start-cp-et stop backup afin d'avoir un point d'ancrage ?
2°) Mon instance TITI étant ma base la plus petite, j'aimerai ne pas dropper mon repertoire 'base' (pour ensuite le remplacer par mon 'base.tar.gz') mais garder mon répertoire 'base' et juste rejouer les wal qui sont archivées... est-ce possible ?
Pouvez-vous m'aider
Merci rjuju...
après modification des valeurs du archive_command, le problème persistait et en regardant la log j'ai vu qu'il manquait de la place sur le l'arborescence cible... nous avons corrigé et c'est bon maintenant !
rebonjour...
j'effectue un pg_start_backup (toto) => Ok
lorsque je fais mon pg_stop_backup ... voici les messages d'erreur :
Mabase=# SELECT pg_stop_backup ();
NOTICE: pg_stop_backup cleanup done, waiting for required WAL segments to be archived
WARNING: pg_stop_backup still waiting for all required WAL segments to be archived (60 seconds elapsed)
HINT: Check that your archive_command is executing properly. pg_stop_backup can be canceled safely, but the database backup will not be usable without all the WAL segments.
et ça continue jusqu'à ce que je cancelle...
Il semblerait que ce soit un problème dans mon archive_command, mais je ne vois pas pourquoi... pouvez-vous m'aider
Voici mon prostgresql.conf :
archive_command = 'cp %f /srv/pgsql/backup/%p'
archive_timeout = 360 # force a logfile segment switch after this
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
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 ?
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
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...
Merci pour votre réponse...
