Vous n'êtes pas identifié(e).
Pages : 1
bonjour
j'utilise le wal streaming ainsi que rsync en archive command.
Cela fonctionne mais j'ai un doublon dans mes fichiers wal qui ne sont pas supprimer lors d'un delete de backup.
voici un exemple :
barman backup postgres
Starting backup using rsync-exclusive method for server postgres in /backup/barman/base/20191202T174330
Backup start at LSN: A/3F000028 (000000010000000A0000003F, 00000028)
Starting backup copy via rsync/SSH for 20191202T174330
Copy done (time: 3 seconds)
Asking PostgreSQL server to finalize the backup.
Backup size: 3.1 GiB. Actual size on disk: 158.9 MiB (-94.92% deduplication ratio).
Backup end at LSN: A/3F006B58 (000000010000000A0000003F, 00006B58)
Backup completed (start time: 2019-12-02 17:43:31.051648, elapsed time: 5 seconds)
Processing xlog segments from streaming for postgres
000000010000000A0000003E
000000010000000A0000003F
-bash-4.2$ barman list-backup postgres
postgres 20191202T174330 - Mon Dec 2 17:43:36 2019 - Size: 3.1 GiB - WAL Size: 0 B (tablespaces: data:/data/pgsql/data, idx:/data/pgsql/idx)
postgres 20191202T172607 - Mon Dec 2 17:26:13 2019 - Size: 3.1 GiB - WAL Size: 634.9 KiB (tablespaces: data:/data/pgsql/data, idx:/data/pgsql/idx)
postgres 20191202T172227 - Mon Dec 2 17:22:58 2019 - Size: 3.1 GiB - WAL Size: 134.1 KiB (tablespaces: data:/data/pgsql/data, idx:/data/pgsql/idx)
postgres 20191202T165859 - Mon Dec 2 16:59:54 2019 - Size: 3.1 GiB - WAL Size: 19.4 MiB (tablespaces: data:/data/pgsql/data, idx:/data/pgsql/idx)
postgres 20191202T000002 - Mon Dec 2 00:00:35 2019 - Size: 3.0 GiB - WAL Size: 64.0 MiB (tablespaces: data:/data/pgsql/data, idx:/data/pgsql/idx)
postgres 20191201T000003 - Sun Dec 1 00:00:36 2019 - Size: 2.9 GiB - WAL Size: 72.2 MiB (tablespaces: data:/data/pgsql/data, idx:/data/pgsql/idx)
postgres 20191130T000003 - Sat Nov 30 00:00:32 2019 - Size: 2.9 GiB - WAL Size: 89.0 MiB (tablespaces: data:/data/pgsql/data, idx:/data/pgsql/idx)
postgres 20191129T000002 - Fri Nov 29 00:00:41 2019 - Size: 2.8 GiB - WAL Size: 61.1 MiB (tablespaces: data:/data/pgsql/data, idx:/data/pgsql/idx)
je supprime le plus ancien :
-bash-4.2$ barman delete postgres 20191129T000002
Deleting backup 20191129T000002 for server postgres
Delete associated WAL segments:
0000000100000009000000C6
0000000100000009000000C7
0000000100000009000000C8
0000000100000009000000C9
0000000100000009000000CA
0000000100000009000000CB
0000000100000009000000CC
0000000100000009000000CD
0000000100000009000000CE
0000000100000009000000CF
0000000100000009000000D0
0000000100000009000000D1
0000000100000009000000D2
0000000100000009000000D3
0000000100000009000000D4
0000000100000009000000D5
0000000100000009000000D6
0000000100000009000000D7
0000000100000009000000D8
0000000100000009000000D9
0000000100000009000000DA
0000000100000009000000DB
0000000100000009000000DC
0000000100000009000000DD
0000000100000009000000DE
0000000100000009000000DF
0000000100000009000000E0
Deleted backup 20191129T000002 (start time: Mon Dec 2 17:45:44 2019, elapsed time: less than one second)
je fais une recherche de wal
locate 0000000100000009000000E0
/backup/incoming-wal/0000000100000009000000E0
/backup/incoming-wal/0000000100000009/0000000100000009000000E0
[root@es7-castel incoming-wal]#
je met a jour ma base locate
# updatedb
You have mail in /var/spool/mail/root
# locate 0000000100000009000000E0
/backup/incoming-wal/0000000100000009000000E0
Barman a bien supprimé le contenue du répertoire 0000000100000009
/backup/incoming-wal/0000000100000009/0000000100000009000000E0
mais par contre le wal /backup/incoming-wal/0000000100000009000000E0 est toujours présent ainsi que tout les autres
je n'arrive pas à trouver la solution pour qu'il me supprime tous les fichiers
voici la conf barman
[barman]
; System user
barman_home = /backup/barman/
barman_user = barman
log_file = /var/log/barman/barman.log
compression = gzip
reuse_backup = link
minimum_redundancy = 5
immediate_checkpoint = true
basebackup_retry_times = 3
basebackup_retry_sleep = 30
last_backup_maximum_age = 1 DAYS
[postgres]
description = "Sauvegarde postgres"
ssh_command = ssh postgres@localhost
retention_policy = RECOVERY WINDOW OF 5 days
compression = gzip
reuse_backup = link
minimum_redundancy = 1
last_backup_maximum_age = '8 days'
recovery_options = 'get-wal'
conninfo = port=5432 host=localhost user=barman dbname=postgres
archiver = on
streaming_conninfo = port=5432 host=localhost user=barman
streaming_archiver = on
streaming_archiver_name = local_barman_receive_wal
slot_name = barman_local
backup_directory = /backup/barman
basebackups_directory = /backup/barman/base
wals_directory = /backup/incoming-wal
path_prefix = /usr/pgsql-11/bin/
backup_options=exclusive_backup
backup_method = rsync
PostgreSQL.conf
wal_level = replica
archive_command = 'rsync -a %p barman@localhost:/backup/incoming-wal/%f'
je pense que c'est l'archive_command qui fait doublon mais aucune certitude la conf est en full local bdd + sauvegarde sur le même serveur ( pas recommandé mais je n'ai pas le choix. )
Par avance merci
Merci pour le votre retour j ai donc commenté la ligne all
bon finalement le probleme ne venait pas de la mais bien du pg_hba.conf du pgpass du barman.conf et du postgresql.conf
effectivement j utilisé soit le nom dns soit l'ip de la machine dans tout ces fichiers en mettant tout en localhost plus de souci
je pense qu'il est important de choisir une maniere ( ip,nom,localhost) et de faire dans tout les fichiers la meme configuration
cordialement
ok je pense avoir trouvé
mon répertoire d'install de barman avec les droits barman etait un sous repertoire /backup qui lui meme etait en 777 root
drwxrwxrwx. 4 root root 4096 Jul 25 16:05 backup
j ai recréé un répertoire un niveau au dessus donc dans /barman-save appliqué les bon droits et rappliquer la même conf j'ai effectivement rajouté la ligne réplication pour barman
PostgreSQL: OK
is_superuser: OK
PostgreSQL streaming: OK
wal_level: OK
replication slot: OK
directories: OK
retention policy settings: OK
backup maximum age: OK (no last_backup_maximum_age provided)
compression settings: OK
failed backups: OK (there are 0 failed backups)
minimum redundancy requirements: OK (have 0 backups, expected at least 0)
ssh: OK (PostgreSQL server)
not in recovery: OK
archive_mode: OK
archive_command: OK
continuous archiving: OK
pg_receivexlog: OK
pg_receivexlog compatible: OK
receive-wal running: OK
archiver errors: OK
par contre la différence que je trouve
ici ça ne fonctionne pas
ALTER ROLE
postgres=# select usename, passwd is null from pg_shadow;
usename | ?column?
----------+----------
barman | f
postgres | f
(2 rows)
ici ça fonctionne ( autre serveur de test)
postgres=# select usename, passwd is null from pg_shadow;
usename | ?column?
----------+----------
postgres | t
barman | f
(2 rows)
j'ai fait le changement mes deux serveurs on la meme configuration
sur le serveur qui fonctionne
[root@postgre2 data]# ls -al /var/lib/barman/.pgpass
-rw------- 1 root root 126 Jul 16 10:58 /var/lib/barman/.pgpass
[root@postgre2 data]# su - barman
Last login: Wed Jul 25 12:03:48 CEST 2018 on pts/0
-bash-4.2$ psql -c 'SELECT version()' -U postgres -h postgre2 -d postgres
psql: FATAL: no pg_hba.conf entry for host "127.0.0.1", user "postgres", database "postgres", SSL off
-bash-4.2$ psql -c 'SELECT version()' -U barman -h postgre2 -d postgres
Password for user barman:
si je fais
psql -c 'SELECT version()' -U barman -h postgre2 -d postgres
j'ai forcement le mot de passe qui est demandé que je sois connecté en postgre ou barman ou root
sur mon serveur qui ne fonctionne pas
psql -c 'SELECT version()' -U postgres -h es7-stkw-dev -d postgres
lancé depuis root postgre ou barman ça ce connecte directement sans demande de mot de passe
je ne comprend pas comment c'est possible je n'ai meme pas de pgpass
les fichiers de configuration son similaire en tout point sauf pour le nom du serveur et l emplacement des fichiers
j'ai fais la modification mais pas mieux
J'arrive a me connecter sans pgpass avec le userbarman postgre ou root est ce normal ?? j'ai même supprimé le pgpass.
( sur mon autre serveur j'ai supprimé le pgpass il me demande le mot de passe)
cordialement
je n'ai pas de fichier pgpass pour root
-bash-4.2$ pwd
/var/lib/barman
-bash-4.2$ vi .pgpass
-bash-4.2$ psql -c 'SELECT version()' -U barman -h es7-stkw-dev -d postgres
WARNING: password file "/var/lib/barman/.pgpass" has group or world access; permissions should be u=rw (0600) or less
version
---------------------------------------------------------------------------------------------------------
PostgreSQL 10.4 on x86_64-pc-linux-gnu, compiled by gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-28), 64-bit
(1 row)
-bash-4.2$ psql -c 'SELECT version()' -U barman -h es7-stkw-dev -d postgres
version
---------------------------------------------------------------------------------------------------------
PostgreSQL 10.4 on x86_64-pc-linux-gnu, compiled by gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-28), 64-bit
(1 row)
j'ai changé les droits chmod 600 sur pgpass mais j'ai toujours le même souci
2018-07-24 16:45:02,173 [12485] barman.postgres WARNING: Error retrieving PostgreSQL status: fe_sendauth: no password supplied
2018-07-24 16:45:02,174 [12485] barman.server ERROR: ArchiverFailure:failed opening the PostgreSQL streaming connection for server xxxxxxxxx
2018-07-24 16:45:02,181 [12486] barman.wal_archiver INFO: No xlog segments found from file archival for xxxxxxx.
2018-07-24 16:45:02,181 [12486] barman.wal_archiver INFO: No xlog segments found from streaming forxxxxxx
PostgreSQL: OK
is_superuser: OK
PostgreSQL streaming: FAILED (fe_sendauth: no password supplied)
wal_level: OK
replication slot: FAILED (replication slot 'barman_local' doesn't exist. Please execute 'barman receive-wal --create-slot XXXXXXX')
directories: OK
retention policy settings: OK
backup maximum age: OK (no last_backup_maximum_age provided)
compression settings: OK
failed backups: OK (there are 0 failed backups)
minimum redundancy requirements: FAILED (have 0 backups, expected at least 5)
ssh: OK (PostgreSQL server)
not in recovery: OK
archive_mode: OK
archive_command: OK
continuous archiving: OK
pg_receivexlog: OK
pg_receivexlog compatible: FAILED (PostgreSQL version: None, pg_receivexlog version: 10.4)
receive-wal running: FAILED (See the Barman log file for more details)
archiver errors: OK
effectivement mon .pgpass n'est pas utilisé ni par barman ni par postgres
mv /var/lib/barman/.pgpass /var/lib/barman/pgpass.old
[root@es7-stkw-dev ~]# systemctl restart postgresql-10.service
[root@es7-stkw-dev ~]# psql -c 'SELECT version()' -U barman -h XXXXXXX -d postgres
version
---------------------------------------------------------------------------------------------------------
PostgreSQL 10.4 on x86_64-pc-linux-gnu, compiled by gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-28), 64-bit
(1 row)
[root@es7-stkw-dev ~]# psql -c 'SELECT version()' -U postgres -h XXXXXXX -d postgres
version
---------------------------------------------------------------------------------------------------------
PostgreSQL 10.4 on x86_64-pc-linux-gnu, compiled by gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-28), 64-bit
(1 row)
la connexion ce fait toujours sans mot de passe
non pas de mot de passe demandé
Bonjour un nouveau petit souci suite à une nouvelle installation
PostgreSQL streaming: FAILED (fe_sendauth: no password supplied)
apriori mon
vi /var/lib/barman/.pgpass
192.168.103.191:5432:postgres:barman:barman
192.168.103.191:5432:replication:barman:barman
avec chmod 600
vi /app/pgsql/10/data/pg_hba.conf
# TYPE DATABASE USER ADDRESS METHOD
# "local" is for Unix domain socket connections only
local all all peer
# IPv4 local connections:
host all barman 127.0.0.1/32 md5
host all all 192.168.103.191/32 trust
host all postgres 192.168.103.191/32 trust
host all barman 192.168.103.191/32 md5
# IPv6 local connections:
host all all ::1/128 ident
# Allow replication connections from localhost, by a user with the
# replication privilege.
#local replication all peer
#host replication all 127.0.0.1/32 ident
#host replication all ::1/128 ident
host replication postgres 192.168.103.191/32 md5
host replication postgres 127.0.0.1/0 trust
log barman:
2018-07-24 11:41:02,101 [23431] barman.postgres WARNING: Error retrieving PostgreSQL status: fe_sendauth: no password supplied
2018-07-24 11:41:02,102 [23431] barman.server ERROR: ArchiverFailure:failed opening the PostgreSQL streaming connection for server
echange de clee ssh fait
la connexion ainsi fonctionne :
psql -c 'SELECT version()' -U barman -h 192.168.103.191 -d postgres
version
---------------------------------------------------------------------------------------------------------
PostgreSQL 10.4 on x86_64-pc-linux-gnu, compiled by gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-28), 64-bit
(1 row)
psql -c 'SELECT version()' -U barman -h nomduserveur -d postgres
version
---------------------------------------------------------------------------------------------------------
PostgreSQL 10.4 on x86_64-pc-linux-gnu, compiled by gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-28), 64-bit
(1 row)
je vous avoue je sèche j avais fait une bonne doc lors de mes précédentes installation mais j'ai beau chercher je trouve pas
dernier point je ne peux pas creer "barman receive-wal --create-slot"
ERROR: Cannot connect to server
Bonjour
est il possible de séparer le moteur BDD et le ficher de BDD?
sur oracle j ai mon moteur de bdd dans un fs spécifique et ma bdd dans un autre
en gros je voudrais pouvoir séparer /var/lib/pgsql/10/** et /var/lib/pgsql/10/base ?
est ce possible?
Bonjour
quand je lance une commande postgre j'ai ma réplication qui pose souci ( enfin je crois)
psostgres=# insert into temoin values(current_timestamp) returning *;
^CCancel request sent
WARNING: canceling wait for synchronous replication due to user request
DETAIL: The transaction has already committed locally, but might not have been replicated to the standby.
INSERT 0 1postgres=# select * from pg_stat_replication ;
pid | usesysid | usename | application_name | client_addr | client_hostname | client_port | backend_start | backend_xmin | state
| sent_lsn | write_lsn | flush_lsn | replay_lsn | write_lag | flush_lag | replay_lag | sync_priority | sync_state
-------+----------+----------+--------------------------+-------------+-----------------+-------------+-------------------------------+--------------+--------
---+------------+------------+------------+------------+-----------------+-----------------+----------------+---------------+------------
20901 | 10 | postgres | local_barman_receive_wal | 127.0.0.1 | | 9348 | 2018-07-16 14:06:02.569536+02 | | streami
ng | 0/38000540 | 0/38000540 | 0/38000000 | | 00:00:03.791241 | 00:16:48.764655 | 00:30:55.02751 | 1 | sync
(1 row)je précise je suis toujours dans un environnement mono serveur
cordialement
J'avais un backup failed après la suppression de celui ci dans barman plus de problème .
Maintenant ça fonctionne
Bonjour
quand je lance une commande postgre j'ai ma réplication qui pose souci ( enfin je crois)
psostgres=# insert into temoin values(current_timestamp) returning *;
^CCancel request sent
WARNING: canceling wait for synchronous replication due to user request
DETAIL: The transaction has already committed locally, but might not have been replicated to the standby.
INSERT 0 1
postgres=# select * from pg_stat_replication ;
pid | usesysid | usename | application_name | client_addr | client_hostname | client_port | backend_start | backend_xmin | state
| sent_lsn | write_lsn | flush_lsn | replay_lsn | write_lag | flush_lag | replay_lag | sync_priority | sync_state
-------+----------+----------+--------------------------+-------------+-----------------+-------------+-------------------------------+--------------+--------
---+------------+------------+------------+------------+-----------------+-----------------+----------------+---------------+------------
20901 | 10 | postgres | local_barman_receive_wal | 127.0.0.1 | | 9348 | 2018-07-16 14:06:02.569536+02 | | streami
ng | 0/38000540 | 0/38000540 | 0/38000000 | | 00:00:03.791241 | 00:16:48.764655 | 00:30:55.02751 | 1 | sync
(1 row)
je précise je suis toujours dans un environnement mono serveur
cordialement
Bonjour
je cherche maintenant a restaurer la dernière transaction validé pour avoir le plus court RPO
quelle est la bonne méthode?
cordialement
le postgresql.conf contient des erreurs. Le mieux est de nous envoyer les lignes décommentées de ce fichier.
Merci vous m avez debloqué j'avais decommenté la ligne archive_commande mais sans supprimer la ligne archive_commande= false
juste en dessous
donc maintenant j arrive a me balader avant la création des tables et a restaurer à après la création des tables
(je ne fais pas de BDD et je suis sur un projet passage de ORACLE à POSTGRE ^^ il y a un début a tout)
Merci
cette ligne :
#BARMAN# archive_command = 'rsync -a %p barman@XXXXXXX:/incoming-wal/%f'est commentée donc pas prise en compte par postgres.
oui j'ai essayé de la de-commenter voir si cela changer quelque chose mais ça n'a rien changé
je pense avoir trouvé mais il parle de PITR ( une doc sur la restauration des wal avec barman :-) )
https://pgphil.ovh/restauration_10_23_02.php
dans tous les cas je suis bloqué a cette étape
2018-07-12 14:29 :42.602 CEST [20239] LOG: archive command failed with exit code 1
2018-07-12 14:29:42.602 CEST [20239] DETAIL: The failed archive command was: false
2018-07-12 14:29:42.602 CEST [20239] WARNING: archiving write-ahead log file "00000002.history" failed too many times, will try again later
mv /postgresql/pgsql/10/data/postgresql.auto.conf.origin /postgresql/pgsql/10/data/postgresql.auto.conf
2018-07-12 14:26:51.423 CEST [20231] LOG: received SIGHUP, reloading configuration files
2018-07-12 14:26:51.424 CEST [20231] LOG: parameter "data_directory" cannot be changed without restarting the server
2018-07-12 14:26:51.424 CEST [20231] LOG: configuration file "/postgresql/pgsql/10/data/postgresql.conf" contains errors; unaffected changes were applied
dans le fichier postgresql.conf
#BARMAN# archive_command = 'rsync -a %p barman@XXXXXXX:/incoming-wal/%f'
j ai essayé de rajouter l'archive commande mais ca ne passe pas
cordialement
Bonjour Guillaume
Merci pour votre retour auriez vous une doc car je ne trouve rien ou je ne cherche peux être pas avec les bon termes
cordialement
Ok donc je restaure le backup du 6 juillet et apres j'utilise les PITR mais barman ne permet pas de m'emmener directement a une heure souhaitée ?
Ok merci pour votre aide, étant sur une machine de test je vais la restaurer et reprendre les essais
quelle sont les bonnes pratique au niveau d'une restauration car hier j'ai tout fait sans rien couper . basé allumée . De plus je suis sur un serveur unique base + sauvegarde
cordialement
9h50 j ai créer des tables
je vois bien dans pg_wal
-rw------- 1 postgres postgres 16777216 Jul 12 09:50 000000010000000000000018
a 10h je vais en dropper une table par erreur et essayer des la restaurer :-)
barman list-backup postgre2
postgre2 20180712T101259 - Thu Jul 12 10:13:04 2018 - Size: 24.0 MiB - WAL Size: 31.8 KiB
postgre2 20180706T113052 - Fri Jul 6 11:30:58 2018 - Size: 24.0 MiB - WAL Size: 134.8 KiB
Comment je fais pour restaurer ma base à 10h
Backup 20180712T101259:
Server Name : postgre2
Status : DONE
PostgreSQL Version : 100004
PGDATA directory : /postgresql/pgsql/10/data
Base backup information:
Disk usage : 23.9 MiB (24.0 MiB with WALs)
Incremental size : 2.8 MiB (-88.43%)
Timeline : 1
Begin WAL : 000000010000000000000019
End WAL : 000000010000000000000019
WAL number : 1
WAL compression ratio: 99.84%
Begin time : 2018-07-12 10:12:59.844987+02:00
End time : 2018-07-12 10:13:04.081104+02:00
Copy time : 1 second + 2 seconds startup
Estimated throughput : 2.1 MiB/s
Begin Offset : 40
End Offset : 304
Begin LSN : 0/19000028
End LSN : 0/19000130
WAL information:
No of files : 1
Disk usage : 31.8 KiB
WAL rate : 77.01/hour
Compression ratio : 99.81%
Last available : 00000001000000000000001A
Catalog information:
Retention Policy : VALID
Previous Backup : 20180706T113052
Next Backup : - (this is the latest base backup)
si j utilise cette commande
barman recover --target-time "2018-07-12 09:42:59.844987+02:00" --remote-ssh-command "ssh postgres@172.25.1.20" postgre2 20180712T101259 /postgresql/pgsql/10/data/
je devrais si je comprend bien arriver avant la création des tables qui sont créé a 9h50
mais ça ne fonctionne pas:
Starting remote restore for server postgre2 using backup 20180712T101259
Destination directory: /postgresql/pgsql/10/data/
ERROR: The requested target time 2018-07-12 09:42:59.844987+02:00 is before the backup end time 2018-07-12 10:13:04.081104+02:00
je pense que je ne m'y prend pas comme il faut effectivement je peux restaurer a l'heure du backup 10:12:59 mais ai je dans mon cas besoin de barman pour ce cas precis ? Je ne devrais pas juste a avoir a restaurer mes WALs ??
Merci pour votre aide
malheureusement je n'ai rien dans les log
[root@postgre2 log]# ll
total 568
-rw------- 1 postgres postgres 285365 Jul 6 11:33 postgresql-Fri.log
-rw------- 1 postgres postgres 0 Jul 9 00:00 postgresql-Mon.log
-rw------- 1 postgres postgres 0 Jul 7 00:00 postgresql-Sat.log
-rw------- 1 postgres postgres 0 Jul 8 00:00 postgresql-Sun.log
-rw------- 1 postgres postgres 290020 Jul 5 23:59 postgresql-Thu.log
-rw------- 1 postgres postgres 800 Jul 10 09:18 postgresql-Tue.log
-rw------- 1 postgres postgres 0 Jul 11 00:00 postgresql-Wed.log
[root@postgre2 log]# vi postgresql-Tue.log
[root@postgre2 log]# su - postgres
Last login: Wed Jul 11 17:58:29 CEST 2018 on pts/0
-bash-4.2$ ssh barman@xxxxxx
Last login: Thu Jul 12 08:37:15 2018
-bash-4.2$
-bash-4.2$ exit
logout
Connection to closed.
-bash-4.2$ exit
logout
[root@postgre2 log]# su - postgres
Last login: Thu Jul 12 08:40:18 CEST 2018 on pts/0
-bash-4.2$ ssh barman@xxxxxx
Last login: Thu Jul 12 08:40:35 2018 from postgre2
-bash-4.2$
je suis bien en mode archive on
quand je relance ma base j ai ça maintenant
postgres 23771 23755 0 17:58 ? 00:00:00 postgres: archiver process failed on 00000002.history
apriori la base est accessible mais barman ne peu plus faire de backup
archive_mode = on # enables archiving; off, on, or always
# (change requires restart)
archive_command = 'rsync -a %p barman@XXXXXXXX:/incoming-wal/%f' # command to use to archive a logfile segment
merci pour votre retour
j'ai ce backup qui ne comporte pas les changement d’aujourd’hui (les wal ne sont pas archiver) malgré ça je souhaite retourné au modification faite a midi aujourd'hui
postgre2 20180711T000002 - Wed Jul 11 00:00:05 2018 - Size: 24.0 MiB - WAL Size: 0 B
mais je n arrive pas a faire un restaure a 12h enfin si mais il ne me rend pas mes changements il me rend une base vide comment faire pour restaurer uniquement les wals
barman recover --target-time "2018-07-11 12:00" --remote-ssh-command "ssh postgres@postgre2" postgre2 20180711T000002 /postgresql/pgsql/10/data
avez vous une idee ?
j'ai peu être mal compris qq chose
merci
Tout dépend de comment vous installez PostgreSQL.
via les rpms
Tout dépend de quelle utilisation vous parlez. replica est le bon pour l'archivage et le rejeu sur des serveurs secondaires.
mon but est de pouvoir les rejouer sur le meme serveur en cas de panne
C'est pour l'archivage des journaux de transactions. Assez étonnamment, ça se compresse bien et ça permet d'éviter une consommation abusive de l'espace disque (ce qui est le risque d'une sauvegarde PITR).
Ok j'avais bien saisi mais je ne trouve pas les fichiers compressé
C'est le rôle du checkpointer, à chaque itération dans sa boucle principale.
faut il les supprimer ou surtout pas?
Pour vous donner plus d'info en gros j ai deux serveur qui on les même role ils sont en actif passif et la base est repliquer en permanance sur l'un ou l'autre pour avoir le même niveau de donnée
merci pour votre retour
Bonjour à tous
l'installation n'est pas des plus aiser effectivement pour mon contexte j'ai besoin d'avoir le serveur postgre et barman sur le meme serveur ( j'utilise des fs different eux meme sur des raids différent).
Savez vous si il y a une autre méthode autre que le déplacement du répertoire a la fin de l'installation et de l'initdb pour déplacer le repertoire par default de postgresql?
J'ai des petites question concernant l'archivage :
Pour l'utilisation des wals dans quel mode d'archivage doit on être (je suis en replica apriori ça fonctionne ) ?
je n'arrive pas a savoir quand intervient la partie compression pour BARMAN avez vous une idée ?
Savez vous quand est ce que les fichiers *.done qui ce trouve dans pg_wal/archive_status sont ils supprimer ?
merci pour vos éclaircissement
Pages : 1