Vous n'êtes pas identifié(e).
- Contributions : Récentes | Sans réponse
Pages : 1
#1 Général » Restauration d'une base de données avec tablespaces séparés » 17/02/2017 16:50:06
- dangil
- Réponses : 1
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
#2 Réplication » Outils de failover automatique » 29/09/2016 15:44:31
- dangil
- Réponses : 5
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
#3 Re : Général » Différence de taille entre un environnement source et cible » 22/07/2016 13:26:00
Merci beaucoup Julien pour ces explications. Je vais parcourir les slides et la doc pour ensuite analyser la situation.
Daniel
#4 Re : Général » Différence de taille entre un environnement source et cible » 22/07/2016 12:43:33
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
#5 Re : Général » Différence de taille entre un environnement source et cible » 22/07/2016 12:07:30
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
#6 Général » Différence de taille entre un environnement source et cible » 22/07/2016 10:53:07
- dangil
- Réponses : 6
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
#7 Général » Erreur d'archivage du dernier WAL après restore » 28/10/2013 14:06:59
- dangil
- Réponses : 1
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