Vous n'êtes pas identifié(e).
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
Hors ligne
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?
Tout dépend de comment vous installez PostgreSQL.
Pour l'utilisation des wals dans quel mode d'archivage doit on être (je suis en replica apriori ça fonctionne ) ?
Tout dépend de quelle utilisation vous parlez. replica est le bon pour l'archivage et le rejeu sur des serveurs secondaires.
je n'arrive pas a savoir quand intervient la partie compression pour BARMAN avez vous une idée ?
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).
Savez vous quand est ce que les fichiers *.done qui ce trouve dans pg_wal/archive_status sont ils supprimer ?
C'est le rôle du checkpointer, à chaque itération dans sa boucle principale.
Guillaume.
Hors ligne
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
Dernière modification par alpi45 (10/07/2018 14:04:10)
Hors ligne
via les RPM
Dans ce cas, il vous faut créer un fichier dans /etc/sysconfig/pgsql dont le nom correspond au nom du service et y ajouter une ligne du type "PGDATA=/le/chemin/vers/data". Ceci fait, il ne vous reste plus qu'à faire un initdb avec le script du service.
mon but est de pouvoir les rejouer sur le meme serveur en cas de panne
Donc replica est suffisant.
faut il les supprimer ou surtout pas?
Vous n'êtes pas sensé modifier les fichiers contenus dans le répertoire de l'instance, y compris les .done. Les seuls fichiers à modifier sont les fichiers de conf.
Guillaume.
Hors ligne
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
Hors ligne
bonjour,
Il me semble que si vous n'êtes pas en mode "archiver on" vous ne pouvez pas faire de restauration PITR.
(après j'ai peut être lu un peu trop rapidement ce fil).
Cordialement,
Sébastien.
Hors ligne
Sans archives des journaux de transactions, votre sauvegarde de fichiers en ligne ne sert à rien. Toute restauration aboutira à une instance corrompue.
Guillaume.
Hors ligne
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
Hors ligne
postgres: archiver process failed on 00000002.history
L'archivage n'est apparemment pas fonctionnel. L'utilisateur postgres ne peut pas se connecter en tant qu'utilisateur barman à la machine, soit parce que l'adresse est mauvaise, soit parce qu'il n'y pas eu d'échange de clé ou ce genre de chose. Les logs postgres devrait vous donner plus de détails sur la cause de ce problème.
Julien.
https://rjuju.github.io/
En ligne
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$
Hors ligne
ok commencez par bien paramétrer vos logs pour qu'apparaissent tous les messages importants :
Cordialement,
Sébastien.
Hors ligne
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
Dernière modification par alpi45 (12/07/2018 11:13:06)
Hors ligne
si vous supprimez votre table à 10H, il faut restaurer une sauvegarde avant 10H et faire du PITR jusqu'avant le suppression de la table.
Cordialement,
Sébastien.
Hors ligne
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 ?
Hors ligne
Pas les PITR, mais les WAL ou les journaux de transactions. barman peut rejouer les journaux jusqu'à l'heure que vous souhaitez. Pour ça, il a besoin d'une sauvegarde qui date d'avant cette heure et de tous les journaux achivés entre le début de cette sauvegarde et l'heure souhaitée.
Guillaume.
Hors ligne
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
Hors ligne
Une doc sur quoi ? les sauvegardes PITR ? barman ?
Guillaume.
Hors ligne
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
Dernière modification par alpi45 (12/07/2018 14:36:40)
Hors ligne
cette ligne :
#BARMAN# archive_command = 'rsync -a %p barman@XXXXXXX:/incoming-wal/%f'
est commentée donc pas prise en compte par postgres.
Cordialement,
Sébastien.
Hors ligne
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é
Dernière modification par alpi45 (12/07/2018 15:03:22)
Hors ligne
le postgresql.conf contient des erreurs. Le mieux est de nous envoyer les lignes décommentées de ce fichier.
Cordialement,
Sébastien.
Hors ligne
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
Dernière modification par alpi45 (12/07/2018 15:54:29)
Hors ligne
Bonjour
je cherche maintenant a restaurer la dernière transaction validé pour avoir le plus court RPO
quelle est la bonne méthode?
cordialement
Hors ligne
La dernière transaction validée est la dernière présente dans le dernier journal de transaction. Il faut donc avoir la possibilité de récupérer ce journal qui n'a pas encore été archivé, et rejouer tous les journaux y compris celui-ci.
Guillaume.
Hors ligne
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
Hors ligne
