Vous n'êtes pas identifié(e).
Pages : 1
C'est pas faux, mais disons que je n'avais pas eu à aller jusqu'à ce niveau de détail sur le fonctionnement car cela fonctionnait auparavant sans l'activation du archive_mode (Il n'est d'ailleurs pas précisé qu'il faut l'activer dans la procédure de pgpool).
Mais bon, maintenant que je comprends un peu mieux comment fonctionne le schmilblick , j'ai juste à attendre le go pour tester avec l'activation de l'archive_mode voir si cela règle le problème.
Merci des réponses en tout cas.
Je me demande si mon problème ne provient pas de la
postgres=# show archive_mode;
archive_mode
--------------
off
(1 row)
D'ailleurs, petite question, je suis en train de faire des tests et théoriquement, lorsqu'on active le mode sauvegarde à chaud:
postgres=# select pg_start_backup('test');
Toutes les modifications faites sur la base sont bien censées être uniquement écrites dans les fichiers de logs et non dans la base elle même? Si oui, je constate que j'ai quand même des modifications sur des fichiers de base:
# ls -l /var/lib/postgresql/9.3/main/base/12035/16386
-rw------- 1 postgres postgres 65536 janv. 21 15:14 /var/lib/postgresql/9.3/main/base/12035/16386
# ls -l /var/lib/postgresql/9.3/main/base/12035/16386
-rw------- 1 postgres postgres 73728 janv. 21 15:17 /var/lib/postgresql/9.3/main/base/12035/16386
Est-ce normal?
Edit: A priori oui:
Certains outils de sauvegarde que vous souhaiteriez utiliser émettent des messages d'avertissements ou d'erreurs si les fichiers qu'ils essaient de copier changent lors de la copie. Cette situation est normale, ce n'est pas une erreur, lors de la création de la sauvegarde de base d'une base de données active ; vous devez donc vous assurer que vous pouvez distinguer les messages de cette sorte des autres messages. Par exemple, certaines versions de rsync renvoient un code de sortie séparé pour des « fichiers source disparus », et vous pouvez écrire un script qui accepte ce code de sortie comme un cas normal. De plus, certaines versions de GNU tar considèrent que la modification d'un fichier lors de sa copie par tar est une erreur. Il ne semble pas exister de moyen simple pour distinguer cette erreur des autres types d'erreurs, autrement qu'en inspectant manuellement les messages de tar. Du coup, GNU tar n'est pas le meilleur outil pour réaliser des sauvegardes de base.
Cordialement,
Bonjour,
Alors ce n'est pas pour les backups mais pour un cluster. Je pense aussi que le problème doit provenir d'un bout de conf/script mais disons que ça fonctionnait avant et plus après sans qu'il n'y ai à ma connaissance eu de modification (je regarde quand même si une modification ne serait pas passée à l'as).
Du coup les scripts sont lancés par pcp_recovery_node, je n'ai donc pas beaucoup de marge de manœuvre pour lancer les scripts. Si je regarde les variables chargées, le wal_level n'a donc pas été modifié
postgres=# show wal_level;
wal_level
-------------
hot_standby
(1 row)
Du coup, je ne sais pas quelle autre variable pourrait influer la dessus.
Cordialement,
Hello,
Pourtant celui-ci est bien présent dans le copy-base-backup
psql -c 'select pg_stop_backup()' postgres
Dans les logs du pgpool il n'y a pas d'erreur particulière
Jan 16 16:26:32 lrqpool1 pgpool[30966]: starting recovery command: "SELECT pgpool_recovery('copy-base-backup', 'xx.xx.xx.xx', '/var/lib/postgresql/9.3/main/')"
Jan 16 16:40:48 lrqpool1 pgpool[30966]: 1st stage is done
Jan 16 16:40:48 lrqpool1 pgpool[30966]: starting 2nd stage
Jan 16 16:41:03 lrqpool1 pgpool[30966]: starting recovery command: "SELECT pgpool_recovery('pgpool_recovery_pitr', 'xx.xx.xx.xx', '/var/lib/postgresql/9.3/main/')"
Et dans les logs du postgres sur la bdd master, je vois bien le start et le stop
pg_start_backup
-----------------
1A/1E000028
(1 ligne)
tar: main/pg_xlog/000000090000001A0000001E : fichier modifié pendant sa lecture
tar: main/base/16386/32566 : fichier modifié pendant sa lecture
tar: main/base/16386/40436 : fichier modifié pendant sa lecture
tar: main/base/16386/23899 : fichier modifié pendant sa lecture
tar: main/base/16386/51929 : fichier modifié pendant sa lecture
tar: main/base/16386/51927 : fichier modifié pendant sa lecture
tar: main/base/16386/32565 : fichier modifié pendant sa lecture
tar: main/base/16386/32562 : fichier modifié pendant sa lecture
tar: main/base/16386/24099 : fichier modifié pendant sa lecture
tar: main/base/16386/32504 : fichier modifié pendant sa lecture
tar: main/base/16386/31813 : fichier modifié pendant sa lecture
NOTICE: L'archivage des journaux de transactions n'est pas activé ;
vous devez vous assurer que tous les fichiers requis des journaux de
transactions sont copiés par d'autre moyens pour terminer la sauvegarde.
pg_stop_backup
----------------
1A/1FE18D60
(1 ligne)
Dans la configuration, le wal_level est bien à hot_standby.
Merci,
Hello,
Je rencontre un petit soucis avec la remise en ligne à chaud de pgpool (PITR). Tout d'abord quelques infos:
OS: Debian wheezy
pgpool version: pgpool-II version 3.3.2 (tokakiboshi)
Postgresql version (on both node): 9.3.3
replication mode: on
doc suivie: http://pgpool.projects.pgfoundry.org/pg … e-recovery
copy-base-backup:
#! /bin/sh
DATA=$1
RECOVERY_TARGET=$2
RECOVERY_DATA=$3
psql -c "select pg_start_backup('pgpool-recovery')" postgres
echo "restore_command = 'scp -o StrictHostKeyChecking=no $(hostname):/var/lib/postgresql/9.3/main/pg_xlog/%f %p'" > /var/lib/postgresql/9.3/main/recovery.conf
tar -C /var/lib/postgresql/9.3/ -zcf /var/lib/postgresql/9.3/main.tar.gz main
psql -c 'select pg_stop_backup()' postgres
scp -o StrictHostKeyChecking=no /var/lib/postgresql/9.3/main.tar.gz $RECOVERY_TARGET:/var/lib/postgresql/9.3
pgpool_recovery_pitr:
#! /bin/sh
# Online recovery 2nd stage script
#
datadir=$1 # master dabatase cluster
DEST=$2 # hostname of the DB node to be recovered
DESTDIR=$3 # database cluster of the DB node to be recovered
port=5432 # PostgreSQL port number
archdir=/var/lib/postgresql/9.3/main/pg_xlog/ # archive log directory
# Force to flush current value of sequences to xlog
psql -p $port -t -c 'SELECT datname FROM pg_database WHERE NOT datistemplate AND datallowconn' template1
while read i
do
if [ "$i" != "" ];then
psql -p $port -c "SELECT setval(oid, nextval(oid)) FROM pg_class WHERE relkind = 'S'" $i
fi
done
psql -p $port -c "SELECT pgpool_switch_xlog('$archdir')" template1
pgpool_remote_start:
#!/bin/sh
DEST=$1
DESTDIR=$2
PGCTL=/usr/lib/postgresql/9.3/bin/pg_ctl
# Déploiement du script de backup
ssh -o StrictHostKeyChecking=no -T $DEST 'cd /var/lib/postgresql/9.3/; tar zxf main.tar.gz' 2>/dev/null 1>/dev/null < /dev/null
# Démarrage du serveur PostgreSQL
ssh -o StrictHostKeyChecking=no -T $DEST $PGCTL -w -D /etc/postgresql/9.3/main/ start 2>/dev/null 1>/dev/null < /dev/null &
Lorsque j'essaye de rajouter le second noeud dans le pool, cela échoue car le postgresql ne peut pas démarrer à cause de l'erreur suivante:
Starting PostgreSQL 9.3 database server: mainThe PostgreSQL server failed to start. Please check the log output: 2015-01-06 15:57:56 CET LOG: database system was interrupted while in recovery at log time 2015-01-06 15:36:44 CET 2015-01-06 15:57:56 CET HINT: If this has occurred more than once some data might be corrupted and you might need to choose an earlier recovery target. 2015-01-06 15:57:56 CET LOG: starting archive recovery 2015-01-06 15:57:56 CET LOG: restored log file "00000009.history" from archive scp: /var/lib/postgresql/9.3/main/pg_xlog/00000009000000130000003A: No such file or directory 2015-01-06 15:57:56 CET LOG: redo starts at 13/3A000028 2015-01-06 15:57:56 CET LOG: record with zero length at 13/3A07D3F0 2015-01-06 15:57:56 CET LOG: redo done at 13/3A07D3C0 2015-01-06 15:57:56 CET LOG: last completed transaction was at log time 2015-01-06 15:36:52.032545+01 scp: /var/lib/postgresql/9.3/main/pg_xlog/00000009000000130000003A: No such file or directory 2015-01-06 15:57:56 CET FATAL: WAL ends before end of online backup 2015-01-06 15:57:56 CET HINT: Online backup started with pg_start_backup() must be ended with pg_stop_backup(), and all WAL up to that point must be available at recovery. 2015-01-06 15:57:56 CET LOG: startup process (PID 11150) exited with exit code 1 2015-01-06 15:57:56 CET LOG: terminating any other active server processes ... failed!
Sur le master au moment de lancer le online recovery
-rw------- 1 postgres postgres 16777216 Jan 6 15:36 000000090000001300000039
-rw------- 1 postgres postgres 16777216 Jan 6 15:36 00000009000000130000003A
-rw------- 1 postgres postgres 16777216 Jan 6 14:56 00000009000000130000003B
-rw------- 1 postgres postgres 16777216 Jan 6 15:02 00000009000000130000003C
-rw------- 1 postgres postgres 16777216 Jan 6 15:10 00000009000000130000003D
-rw------- 1 postgres postgres 16777216 Jan 6 15:17 00000009000000130000003E
-rw------- 1 postgres postgres 16777216 Jan 6 15:24 00000009000000130000003F
-rw------- 1 postgres postgres 16777216 Jan 6 15:31 000000090000001300000040
Et après au moment de l'erreur
-rw------- 1 postgres postgres 16777216 Jan 6 15:48 00000009000000130000003B
-rw------- 1 postgres postgres 16777216 Jan 6 15:49 00000009000000130000003C
-rw------- 1 postgres postgres 16777216 Jan 6 15:10 00000009000000130000003D
-rw------- 1 postgres postgres 16777216 Jan 6 15:17 00000009000000130000003E
-rw------- 1 postgres postgres 16777216 Jan 6 15:24 00000009000000130000003F
-rw------- 1 postgres postgres 16777216 Jan 6 15:31 000000090000001300000040
-rw------- 1 postgres postgres 16777216 Jan 6 15:36 000000090000001300000041
-rw------- 1 postgres postgres 16777216 Jan 6 15:43 000000090000001300000042
Quelqu'un a t-il une idée?
Merci d'avance,
Pages : 1