Vous n'êtes pas identifié(e).
Pages : 1
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,
Dernière modification par jotheroot (16/01/2015 18:17:28)
Hors ligne
Apparemment, il n'y a pas eu de pg_stop_backup().
Guillaume.
Hors ligne
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,
Hors ligne
Avant de tout complexifier avec pgpool, avez-vous essayé de faire ce type de sauvegarde manuellement ? puis avec les scripts, mais exécuté par vous (et pas par pgpool) ?
Parce que, qu'on soit clair, il est tout à fait possible qu'il y ait un bug dans PostgreSQL, mais c'est assez fortement improbable. En tout cas, beaucoup plus improbable qu'une erreur dans vos scripts, ou dans la configuration de pgpool ou dans pgpool lui-même
Là, la sortie que vous indiquez précise que l'archivage des journaux de transactions n'est pas activé. Ce qui sous-entend que vous avez un problème dans la configuration de PostgreSQL pour la sauvegarde PITR.
Guillaume.
Hors ligne
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,
Dernière modification par jotheroot (21/01/2015 16:27:14)
Hors ligne
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,
Dernière modification par jotheroot (21/01/2015 16:38:22)
Hors ligne
Je me demande si mon problème ne provient pas de la
postgres=# show archive_mode;
archive_mode
--------------
off
(1 row)
Hors ligne
Alors ce n'est pas pour les backups mais pour un cluster.
Blanc bonnet et bonnet blanc. Vous avez besoin d'un backup de ce type pour créer un cluster de réplication de ce type
Est-ce normal?
Oui, c'est normal que les fichiers soient modifiés. Comme vous archivez les journaux de transactions, lors de la restauration, PostgreSQL saura corriger les incohérences.
Problème que vous avez trouvé vous-même, vous n'archivez pas les journaux de transactions...
Bref, on en revient à ce que je disais : avant de coller pgpool et ses scripts dans le schmilblick, commencez par comprendre le fonctionnement du schmilblick
Guillaume.
Hors ligne
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.
Hors ligne
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).
Non, ça faisait semblant de fonctionner. Sauf si vous arrêtez le serveur pendant la sauvegarde des fichiers, vous ne pouvez pas faire de sauvegarde des fichiers, serveur allumé, sans archivage. Enfin, plus exactement, vu qu'on joue sur les mots, vous pouvez. Par contre, vous ne pourrez pas restaurer de façon cohérente.
Guillaume.
Hors ligne
Pages : 1