Vous n'êtes pas identifié(e).
Pages : 1
Bonjour,
Merci pour vos réponses. Je peux maintenant supprimer l'ancien PGDATA de la v11 sans soucis.
Merci encore pour le support et bonne journée
Daniel
oui elle est éteinte, seul l'instance 13 est startée :
postgres 58310 1 0 Mar05 ? 00:34:09 /usr/pgsql-13/bin/postmaster -D /opt/postgres/bsi/13
postgres 58314 58310 0 Mar05 ? 00:00:00 postgres: logger
postgres 58316 58310 0 Mar05 ? 00:36:40 postgres: checkpointer
postgres 58317 58310 0 Mar05 ? 00:02:10 postgres: background writer
postgres 58318 58310 0 Mar05 ? 00:04:57 postgres: walwriter
postgres 58319 58310 0 Mar05 ? 00:00:06 postgres: autovacuum launcher
postgres 58320 58310 0 Mar05 ? 00:00:09 postgres: archiver last was 0000000100002C190000000F
postgres 58321 58310 12 Mar05 ? 09:07:34 postgres: stats collector
postgres 58322 58310 0 Mar05 ? 00:00:00 postgres: logical replication launcherNon, pas eu de message d'erreur. c'est très curieux.
Voici les derniers accès à la db dans le répertoire v11 :
...
-rw-------. 2 postgres postgres 668590080 Mar 8 09:57 19729529
-rw-------. 2 postgres postgres 164839424 Mar 8 09:57 38464246
-rw-------. 2 postgres postgres 13008896 Mar 8 09:57 38464252et dans le répertoire V13 :
...
-rw-------. 2 postgres postgres 165543936 Mar 8 09:57 8472048
-rw-------. 2 postgres postgres 21913600 Mar 8 09:57 9495352
-rw-------. 2 postgres postgres 13066240 Mar 8 09:57 8472076Merci pour vos réponses.
Si je lance le script "delete_old_cluster.sh" qui effectue simplement un "rm -rf '/opt/postgres/bsi/11'" la db aura des problèmes car certains fichiers de l'ancien répertoire V11 sont toujours touchés.
Par exemple :
-rw-------. 2 postgres postgres 17358848 Mar 8 09:15 21823741
-rw-------. 2 postgres postgres 706199552 Mar 8 09:15 17401164Bonjour,
Samedi dernier nous avons upgradé un de nos Postgres de prod en v13 (VM sur Linux 7.9) avec l'option --link de pg_upgrade mais après cela nous avons remarqué que les liens du répertoire de la db applicative pointent toujours sur le répertoire de la v11.
Commande éxecutée sans erreur :
time /usr/pgsql-13/bin/pg_upgrade --link --old-datadir=/opt/postgres/bsi/11 --new-datadir=/opt/postgres/bsi/13 --old-bindir=/usr/pgsql-11/bin --new-bindir=/usr/pgsql-13/binVoici le "du -h" des 2 répertoires et nous remarquons que le répertoire de la db "/11/base/16792" avec 990GB pointe toujours sur la v11
0 ./11/pg_serial
1.6M ./11/pg_stat_tmp
1.1G ./11/log
0 ./11/pg_wal/archive_status
2.1G ./11/pg_wal
0 ./11/pg_tblspc
7.9M ./11/base/1
13M ./11/base/13881
990G ./11/base/16792
7.7M ./11/base/13880
0 ./11/base/pgsql_tmp
990G ./11/base
0 ./11/pg_replslot
8.0K ./11/pg_notify
0 ./11/pg_dynshmem
14M ./11/pg_stat
0 ./11/pg_twophase
0 ./11/pg_snapshots
0 ./11/pg_logical/snapshots
0 ./11/pg_logical/mappings
4.0K ./11/pg_logical
0 ./11/pg_commit_ts
8.0K ./11/pg_multixact/offsets
8.0K ./11/pg_multixact/members
16K ./11/pg_multixact
48M ./11/pg_xact
184K ./11/pg_subtrans
30M ./11/global
994G ./11
0 ./tablespaces/bsi_data/PG_11_201809051
0 ./tablespaces/bsi_data/PG_13_202007201
0 ./tablespaces/bsi_data
0 ./tablespaces/bsi_document/PG_11_201809051
0 ./tablespaces/bsi_document/PG_13_202007201
0 ./tablespaces/bsi_document
0 ./tablespaces/bsi_staging/PG_11_201809051
0 ./tablespaces/bsi_staging/PG_13_202007201
0 ./tablespaces/bsi_staging
0 ./tablespaces/bsi_email/PG_11_201809051
0 ./tablespaces/bsi_email/PG_13_202007201
0 ./tablespaces/bsi_email
0 ./tablespaces
0 ./13/pg_wal/archive_status
4.3G ./13/pg_wal
22M ./13/global
0 ./13/pg_commit_ts
0 ./13/pg_dynshmem
0 ./13/pg_notify
0 ./13/pg_serial
0 ./13/pg_snapshots
6.6M ./13/pg_subtrans
0 ./13/pg_twophase
8.0K ./13/pg_multixact/offsets
8.0K ./13/pg_multixact/members
16K ./13/pg_multixact
8.0M ./13/base/14173
8.2M ./13/base/16404
44G ./13/base/16405
94M ./13/base/200946
0 ./13/base/pgsql_tmp
44G ./13/base
0 ./13/pg_replslot
0 ./13/pg_tblspc
0 ./13/pg_stat
32M ./13/pg_stat_tmp
0 ./13/pg_logical/snapshots
0 ./13/pg_logical/mappings
4.0K ./13/pg_logical
82M ./13/log
48M ./13/pg_xact
48G ./13
1.1T .Comment pouvons-nous corriger cette situation ?
Merci d'avance pour vos réponses et bonne journée
Daniel
Bonjour,
Nous effectuons le backup d'une base de données avec tablespaces séparés (donc sur un autre répertoire que $PGDATA) avec pg_basebackup (pour permettre un PIT).
La restauration est (normalement) effectuée de cette manière :
Arrêt du cluster et suppression des fichiers
pg_ctl stop
rm -fr $PGDATA
Décompression du ficher de backup "base.tar"
cd $PGDATA
tar -xvf backup_directory/backup_postgres_93_all_basebackup_20170217_073953/base.tar.gz
ensuite décompression de chaque fichier contenant un tablespace
cd <répertoire des TS>
rm -fr *
tar -xvf backup_directory/backup_postgres_93_all_basebackup_20170217_073953/16385.tar.gz
tar -xvf backup_directory/backup_postgres_93_all_basebackup_20170217_073953/16386.tar.gz
tar -xvf backup_directory/backup_postgres_93_all_basebackup_20170217_073953/16387.tar.gz
tar -xvf backup_directory/backup_postgres_93_all_basebackup_20170217_073953/16388.tar.gz
pour terminer créer le ficher recovery.conf avec les variables nécessaires et redémarrer le cluster.
vi $PGDATA/recovery.conf
pg_ctl start
existe t'il un autre moyen de restauration d'une DB avec TS séparés que ce procédé manuel ?
Merci
Bonjour,
Pourriez-vous me dire quel est l'outil le plus approprié et peut être le plus simple à utiliser et configurer ;-) pour surveiller un environnent haute disponibilité (1 master et 1 slave) et qui pourra effectuer un failover automatique et cas de crash du master ?
Nous allons installer cet environnement sous postgres 9.3 en streaming replication.
Merci d'avance pour vos réponses et salutations
Daniel
Merci beaucoup Julien pour ces explications. Je vais parcourir les slides et la doc pour ensuite analyser la situation.
Daniel
la plupart de ces 35GB se trouvent dans le répertoire de données :
/opt/postgres/9.4/base > du -h
6.8M ./1
60M ./pgsql_tmp
6.8M ./12921
6.6M ./12916
32G ./16395
6.8M ./18907
619M ./16396
33G .
La différence de taille entre l'environnement source et cible est donc certainement du à la fragmentation et pour la supprimer et ainsi libérer de la place disque il me faudra comme vous le dites mieux configurer l'autovacuum. Auriez-vous peut-être déjà des recommandations 
Merci beaucoup
Daniel
En fait la taille de l'environnement à recopier est de 35GB et pour information la taille de son backup effectué avec pg_basebackup est de 5.2GB.
Pour reprendre les données de cet environnement sur le nouveau j'ai fait un pg_dumpall et un psql pour le restore sur le nouveau. La taille de ce nouvel environnement restauré ne fait ensuite plus que 14GB au lieu de 35GB pour l'ancien et son backup effectué également avec pg_basebackup ne fait plus qu 2.5GB au lieu de 5.2GB pour l'ancien.
J'aimerais comprendre cette différence de taille entre l'ancien et le nouvel environnement avec les mêmes données ?
Merci
Daniel
Bonjour,
j'ai repris un environnement Postgres d'un serveur existant sur un nouveau avec pg_dumpall.
La taille de l’environnement source est de 35GB et la taille d'un backup effectué avec pg_basebackup est de 5.2GB
La taille du nouvel environnement restauré avec psql est de 14GB et le backup de 2.5GB
En sachant que le vacuum automatique est enclenché quel est la raison de cette grosse différence ?
Merci d'avance pour vos réponses et salutations
Daniel
Bonjour,
Nous avons effectué des test de restore "to end of log" sur une instance avec archivage des WAL.
Le restore avec l'application des WAL's archivés s'est déroulé correctement et Postgres essaie ensuite de ré archiver le dernier WAL appliqué (qui était déjà archivé) durant le restore et renvoie l'erreur suivante :
2013-10-25 14:38:42 CEST [847]: [1-1] LOG: database system was interrupted; last known up at 2013-10-25 14:32:41 CEST
2013-10-25 14:38:42 CEST [847]: [2-1] LOG: creating missing WAL directory "pg_xlog/archive_status"
2013-10-25 14:38:42 CEST [847]: [3-1] LOG: restored log file "00000004.history" from archive
2013-10-25 14:38:42 CEST [847]: [4-1] LOG: starting archive recovery
2013-10-25 14:38:42 CEST [847]: [5-1] LOG: restored log file "000000040000000000000063" from archive
2013-10-25 14:38:42 CEST [847]: [6-1] LOG: redo starts at 0/63000020
2013-10-25 14:38:42 CEST [847]: [7-1] LOG: consistent recovery state reached at 0/630000E0
2013-10-25 14:38:42 CEST [841]: [2-1] LOG: database system is ready to accept read only connections
2013-10-25 14:38:42 CEST [847]: [8-1] LOG: restored log file "000000040000000000000064" from archive
cp: cannot stat `/opt/postgres/backups/archive_logs/000000040000000000000065': No such file or directory
2013-10-25 14:38:42 CEST [847]: [9-1] LOG: could not open file "pg_xlog/000000040000000000000065" (log file 0, segment 101): No such file or directory
2013-10-25 14:38:42 CEST [847]: [10-1] LOG: redo done at 0/64000F98
2013-10-25 14:38:42 CEST [847]: [11-1] LOG: last completed transaction was at log time 2013-10-25 14:34:03.539514+02
2013-10-25 14:38:42 CEST [847]: [12-1] LOG: restored log file "000000040000000000000064" from archive
cp: cannot stat `/opt/postgres/backups/archive_logs/00000005.history': No such file or directory
2013-10-25 14:38:42 CEST [847]: [13-1] LOG: selected new timeline ID: 5
2013-10-25 14:38:42 CEST [847]: [14-1] LOG: restored log file "00000004.history" from archive
2013-10-25 14:38:42 CEST [847]: [15-1] LOG: archive recovery complete
WAL Restore terminated
2013-10-25 14:38:42 CEST [841]: [3-1] LOG: database system is ready to accept connections
2013-10-25 14:38:42 CEST [860]: [1-1] LOG: autovacuum launcher started
2013-10-25 14:38:42 CEST [861]: [1-1] LOG: archive command failed with exit code 1
2013-10-25 14:38:42 CEST [861]: [2-1] DETAIL: The failed archive command was: test ! -f /opt/postgres/backups/archive_logs/000000040000000000000064 && cp pg_xlog/000000040000000000000064 /opt/postgres/backups/archive_logs/000000040000000000000064
2013-10-25 14:38:43 CEST [861]: [3-1] LOG: archive command failed with exit code 1
2013-10-25 14:38:43 CEST [861]: [4-1] DETAIL: The failed archive command was: test ! -f /opt/postgres/backups/archive_logs/000000040000000000000064 && cp pg_xlog/000000040000000000000064 /opt/postgres/backups/archive_logs/000000040000000000000064
2013-10-25 14:38:44 CEST [861]: [5-1] LOG: archive command failed with exit code 1
2013-10-25 14:38:44 CEST [861]: [6-1] DETAIL: The failed archive command was: test ! -f /opt/postgres/backups/archive_logs/000000040000000000000064 && cp pg_xlog/000000040000000000000064 /opt/postgres/backups/archive_logs/000000040000000000000064
2013-10-25 14:38:44 CEST [861]: [7-1] WARNING: transaction log file "000000040000000000000064" could not be archived: too many failures
Voici la comande d'archivage des WAL dans le fichier Postgresql.conf :
archive_command = 'test ! -f /opt/postgres/backups/archive_logs/%f && cp %p /opt/postgres/backups/archive_logs/%f'
et le "restore_command" dans le fichier recovery.conf :
restore_command = 'cp /opt/postgres/backups/archive_logs/%f "%p"'
Le seul moyen trouvé est de supprimer le fichier précédement archivé avec un rm mais ce n'est certainement pas la bonne méthode.
Merci pour votre aide et salutations
Daniel
Pages : 1