Vous n'êtes pas identifié(e).
Bonjour,
J'ai un serveur postgresql-12 version 12.7 sur un serveur
Je démarre une instance en mode réplication sur un autre server
bash $ pg_basebackup -h 172.16.18.201 -U repli --format=p --wal-method=stream --progress --write-recovery-conf -D $PGDATA
pg_basebackup: initiating base backup, waiting for checkpoint to complete
pg_basebackup: checkpoint completed
pg_basebackup: write-ahead log start point: 0/1F000028 on timeline 1
pg_basebackup: starting background WAL receiver
pg_basebackup: created temporary replication slot "pg_basebackup_23935"
43875/43875 kB (100%), 1/1 tablespace
pg_basebackup: write-ahead log end point: 0/1F000100
pg_basebackup: waiting for background process to finish streaming ...
pg_basebackup: syncing data to disk ...
pg_basebackup: base backup completedLa commande se passe bien tous les fichiers sont récupérés
Lors du démarrage du serveur, cela se passe mal
Le démarrage de ce serveur de backup est refusé
bash $ sudo systemctl start postgresql-12 ... les log de démarrage
2021-09-29 19:30:13 +04 [22855]: db=,user=,app=,client=LOG: database system was interrupted; last known up at 2021-09-29 19:30:09 +04
2021-09-29 19:30:14 +04 [22855]: db=,user=,app=,client=LOG: restored log file "00000002.history" from archive
rsync: link_stat "/data/sadm/postgresql-archivedir/00000003.history" failed: No such file or directory (2)
rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1651) [Receiver=3.1.2]
rsync: [Receiver] write error: Broken pipe (32)
2021-09-29 19:30:14 +04 [22855]: db=,user=,app=,client=LOG: entering standby mode
2021-09-29 19:30:14 +04 [22855]: db=,user=,app=,client=LOG: restored log file "00000002.history" from archive
rsync: link_stat "/data/sadm/postgresql-archivedir/00000002000000000000001F" failed: No such file or directory (2)
rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1651) [Receiver=3.1.2]
rsync: [Receiver] write error: Broken pipe (32)
2021-09-29 19:30:15 +04 [22855]: db=,user=,app=,client=LOG: restored log file "00000001000000000000001F" from archive
2021-09-29 19:30:15 +04 [22855]: db=,user=,app=,client=FATAL: requested timeline 2 is not a child of this server's history
2021-09-29 19:30:15 +04 [22855]: db=,user=,app=,client=DETAIL: Latest checkpoint is at 0/1F000060 on timeline 1, but in the history of the requested timeline, the server forked off from that timeline at 0/9000000.
2021-09-29 19:30:15 +04 [22847]: db=,user=,app=,client=LOG: startup process (PID 22855) exited with exit code 1
2021-09-29 19:30:15 +04 [22847]: db=,user=,app=,client=LOG: aborting startup due to startup process failure
2021-09-29 19:30:15 +04 [22847]: db=,user=,app=,client=LOG: database system is shut downLa configuration du serveur pour la réplication et le wal est la même sur les deux machines (j'ai supprimé les variables qui n'ont pas été changé par nos soins).
Le serveur main copie en local les fichiers WAL /data/sadm/postgresql-archivedir/ et le serveur de backup les récupère avec un rsync.
Le serveur de backup fait le ménage avec une commande ssh sur le serveur main.
Le serveur principal tourne en mode main
bash $ systemctl status postgresql-12
● postgresql-12.service - PostgreSQL 12 database server
Loaded: loaded (/usr/lib/systemd/system/postgresql-12.service; enabled; vendor preset: disabled)
Active: active (running) since mer. 2021-09-29 17:50:15 +04; 2h 10min ago
Docs: https://www.postgresql.org/docs/12/static/
Process: 4796 ExecStartPre=/usr/pgsql-12/bin/postgresql-12-check-db-dir ${PGDATA} (code=exited, status=0/SUCCESS)
Main PID: 4802 (postmaster)
CGroup: /system.slice/postgresql-12.service
├─4802 /usr/pgsql-12/bin/postmaster -D /var/lib/pgsql/12/data/
├─4804 postgres: logger
├─4806 postgres: checkpointer
├─4807 postgres: background writer
├─4808 postgres: walwriter
├─4809 postgres: autovacuum launcher
├─4810 postgres: archiver last was 000000010000000000000021.00000028.backup
├─4811 postgres: stats collector
└─4812 postgres: logical replication launcher Voici la config postgresql.conf
#------------------------------------------------------------------------------
# WRITE-AHEAD LOG
#------------------------------------------------------------------------------
# - Settings -
#checkpoint_timeout = 5min # range 30s-1d
max_wal_size = 1GB
min_wal_size = 80MB
# - Archiving -
archive_mode = 'on'
# (change requires restart)
archive_command = 'test ! -f /data/sadm/postgresql-archivedir/%f && cp %p /data/sadm/postgresql-archivedir/%f'
# placeholders: %p = path of file to archive
# %f = file name only
# e.g. 'test ! -f /mnt/server/archivedir/%f && cp %p /mnt/server/archivedir/%f'
# - Archive Recovery -
# These are only used in recovery mode.
restore_command = 'rsync -a 172.16.18.201:/data/sadm/postgresql-archivedir/%f %p'
# placeholders: %p = path of file to restore
# %f = file name only
# e.g. 'cp /mnt/server/archivedir/%f %p'
# (change requires restart)
archive_cleanup_command = 'echo pg_archivecleanup -d /data/sadm/postgresql-archivedir %r | ssh 172.16.18.201 "bash -ls"'
#------------------------------------------------------------------------------
# REPLICATION
#------------------------------------------------------------------------------
# - Sending Servers -
# Set these on the master and on any standby that will send replication data.
primary_conninfo = 'host=172.16.18.201 user=repli'
# (change requires restart)Dernière modification par cdelarue (29/09/2021 18:03:10)
Hors ligne
Le serveur était sur la timeline 1. Il a tenté de passer sur la timeline 2, il a récupéré le fichier history pour ça. Cependant, il n'a pas trouvé de journaux de transactions pour la TL 2, donc il est resté sur le TL 1 mais apparemment la TL 2 était demandé (certainement à cause de la configuration mais le peu de config indiqué ici ne le montre pas). La TL 2 n'était pas disponible mais réclamé, le serveur n'a pas eu d'autre choix que de s'arrêter en erreur.
C'est en tout cas comme ça que j'interprète les logs.
Guillaume.
Hors ligne
De ce que je vois la timeline 2 existe et a été trouvée, mais la sauvegarde ne correspond pas cet historique.
J'ai l'impression que la restore_command récupère les mauvais fichiers, ou que le serveur source a été promu puis repassé en timeline 1.
Julien.
https://rjuju.github.io/
Hors ligne
bonjour,
on ne le voit pas ici dans ce post mais il est possible que ce soit du à la valeur de recovery_target_timeline (j'ai eu un cas similaire récemment).
Selon sa valeur dans recovery.conf, cela peut avoir des effets indésirés.
Sinon comme le dit rjuju, il est probable qu'il manque des fichiers dans le backup.
Cordialement,
Sébastien.
Hors ligne