Vous n'êtes pas identifié(e).
Bonjour à tous,
Je suis sur un moteur 9.3.2 sous RedHat 4.1.2.
Suite à analyse des logs, j'ai des messages :
2016-10-24 08:25:09 EAT [4507]: [1-1] user=,db= LOG: autovacuum: found orphan temp table "pg_temp_14"."tmpctrl" in database "geo"
2016-10-24 08:25:09 EAT [4507]: [2-1] user=,db= LOG: autovacuum: found orphan temp table "pg_temp_11"."tmpctrl" in database "geo"
2016-10-24 08:26:09 EAT [4558]: [1-1] user=,db= LOG: autovacuum: found orphan temp table "pg_temp_14"."tmpctrl" in database "geo"
2016-10-24 08:26:09 EAT [4558]: [2-1] user=,db= LOG: autovacuum: found orphan temp table "pg_temp_11"."tmpctrl" in database "geo"
2016-10-24 08:27:09 EAT [4649]: [1-1] user=,db= LOG: autovacuum: found orphan temp table "pg_temp_14"."tmpctrl" in database "geo"
2016-10-24 08:27:09 EAT [4649]: [2-1] user=,db= LOG: autovacuum: found orphan temp table "pg_temp_11"."tmpctrl" in database "geo"
En regardant les objets de la base, j'ai un paquet de pg_temp_??? et pg_toast_temp_??? (environ une vingtaine de chaque) :
geo=# \dnS
List of schemas
Name | Owner
--------------------+----------
geo | postgres
information_schema | postgres
jrn_local | postgres
pg_catalog | postgres
....
....
pg_temp_11 | postgres
pg_temp_14 | postgres
....
....
pg_toast | postgres
....
....
pg_toast_temp_11 | postgres
pg_toast_temp_14 | postgres
....
....
public | postgres
(41 rows)
Est-ce qu'il suffit de supprimer ces schémas ?
Y-a-t'il un risque (base en prod) ?
Comment ces schémas arrivent-ils ?
Pourquoi des pg_temp et des pg_toast_temp ?
Je sais qu'il y a eu quelques plantages du serveur, mais PostgreSQL redémarre toujours correctement (après suppression du postmaster.pid).
D'avance merci pour les réponses.
Bonjour,
Je travaille sur un moteur 9.5.3 sous Cent-OS 7.2.
Je regarde l'utilisation de PG_BASEBACKUP().
Dans la doc en ligne, je lis :
24.3. Archivage continu et récupération d'un instantané (PITR)
24.3.6. Conseils et exemples
Il est possible d'utiliser les capacités de sauvegarde de PostgreSQL™ pour produire des sauvegardes autonomes à chaud. Ce sont des sauvegardes QUI NE PEUVENT PAS ETRE
UTILISEES POUR LA RECUPERATION A UN INSTANT DONNE, mais ce sont des sauvegardes qui sont typiquement plus rapide à obtenir et à restaurer que ceux issus de pg_dump.
Mais je lis aussi, toujours dans la doc en ligne, dans la description de la commande PG_BASEBACKUP :
pg_basebackup est utilisé pour prendre une sauvegarde de base d'une instance PostgreSQL™ en cours d'exécution. Elles se font sans affecter les autres clients du serveur de bases de
données et PEUVENT ETRE UTILISEES POUR UNE RESTAURATION JUSQU'A UN CERTAIN POINT DANS LE TEMPS.
Est-ce que l'on parle du même outil ?
Ou est-ce que je n'ai pas compris ?
Quelqu'un peut-il m'éclairer, svp ?
D'avance merci.
Bonjour Julien,
Ok, merci pour l'info.
Merci de transmettre la "coquille" à Guillaume pour la prochaine édition de son excellent livre.
Bonjour,
Je travaille sur un moteur 9.5.3 sous Cent-OS 7.2.
Je viens de lire le chapitre 11 SAUVEGARDE et RESTAURATION du livre de Guillaume "PostgreSQL - Architecture et notions avancées"
Page 283, il y a un exemple d'utilisation de pg_dump et pg_dumpall.
Je n'arrive pas à tester. Visiblement la parallélisation n'est possible qu'en mode DIRECTORY.
Quelqu'un a t'il testé ?
D'avance merci pour les réponses.
Le changement sur la restore_command ne change rien.
Je refais toute la procédure en reconstruisant mon nouvel esclave (après bascule) à partir du même hot-backup qui m'a servi à construire mon premier esclave (avant bascule).
Les traces me disent :
2016-06-15 13:29:40 CEST [21775]: [1-1] user= 2016-06-15 13:29:40 CEST LOG: database system was interrupted; last known up at 2016-06-15 13:15:59 CEST
2016-06-15 13:29:40 CEST [21775]: [2-1] user= 2016-06-15 13:29:40 CEST LOG: entering standby mode
2016-06-15 13:29:40 CEST [21775]: [3-1] user= 2016-06-15 13:29:40 CEST LOG: restored log file "00000001000000000000000B" from archive
2016-06-15 13:29:40 CEST [21775]: [4-1] user= 2016-06-15 13:29:40 CEST LOG: redo starts at 0/B000028
2016-06-15 13:29:40 CEST [21775]: [5-1] user= 2016-06-15 13:29:40 CEST LOG: consistent recovery state reached at 0/B00EFB8
2016-06-15 13:29:40 CEST [21775]: [6-1] user= 2016-06-15 13:29:40 CEST LOG: restored log file "00000001000000000000000C" from archive
2016-06-15 13:29:41 CEST [21775]: [7-1] user= 2016-06-15 13:29:40 CEST LOG: restored log file "00000001000000000000000D" from archive
2016-06-15 13:29:41 CEST [21775]: [8-1] user= 2016-06-15 13:29:40 CEST LOG: restored log file "00000001000000000000000E" from archive
2016-06-15 13:29:42 CEST [21775]: [9-1] user= 2016-06-15 13:29:40 CEST LOG: restored log file "00000001000000000000000F" from archive
2016-06-15 13:29:42 CEST [21775]: [10-1] user= 2016-06-15 13:29:40 CEST LOG: restored log file "000000010000000000000010" from archive
2016-06-15 13:29:43 CEST [21775]: [11-1] user= 2016-06-15 13:29:40 CEST LOG: restored log file "000000010000000000000011" from archive
2016-06-15 13:29:43 CEST [21775]: [12-1] user= 2016-06-15 13:29:40 CEST LOG: restored log file "000000010000000000000012" from archive
2016-06-15 13:29:43 CEST [21775]: [13-1] user= 2016-06-15 13:29:40 CEST LOG: restored log file "000000010000000000000013" from archive
cp: impossible d'évaluer « /home/postgres/PG_ARC/000000010000000000000014 »: Aucun fichier ou dossier de ce type
2016-06-15 13:29:44 CEST [21788]: [1-1] user= 2016-06-15 13:29:44 CEST LOG: fetching timeline history file for timeline 2 from primary server
2016-06-15 13:29:44 CEST [21788]: [2-1] user= 2016-06-15 13:29:44 CEST LOG: started streaming WAL from primary at 0/14000000 on timeline 1
2016-06-15 13:29:44 CEST [21788]: [3-1] user= 2016-06-15 13:29:44 CEST LOG: replication terminated by primary server
2016-06-15 13:29:44 CEST [21788]: [4-1] user= 2016-06-15 13:29:44 CEST DETAIL: End of WAL reached on timeline 1 at 0/14000098.
cp: impossible d'évaluer « /home/postgres/PG_ARC/000000010000000000000014 »: Aucun fichier ou dossier de ce type
2016-06-15 13:29:44 CEST [21775]: [14-1] user= 2016-06-15 13:29:40 CEST LOG: invalid record length at 0/14000098
2016-06-15 13:29:44 CEST [21788]: [5-1] user= 2016-06-15 13:29:44 CEST LOG: restarted WAL streaming at 0/14000000 on timeline 1
2016-06-15 13:29:44 CEST [21788]: [6-1] user= 2016-06-15 13:29:44 CEST LOG: replication terminated by primary server
2016-06-15 13:29:44 CEST [21788]: [7-1] user= 2016-06-15 13:29:44 CEST DETAIL: End of WAL reached on timeline 1 at 0/14000098.
cp: impossible d'évaluer « /home/postgres/PG_ARC/000000010000000000000014 »: Aucun fichier ou dossier de ce type
2016-06-15 13:29:49 CEST [21788]: [8-1] user= 2016-06-15 13:29:44 CEST LOG: restarted WAL streaming at 0/14000000 on timeline 1
2016-06-15 13:29:49 CEST [21788]: [9-1] user= 2016-06-15 13:29:44 CEST LOG: replication terminated by primary server
Le fichier 0...1...14 n'existe pas dans mon PG_ARC, c'est un 0...1...14.partial
Ensuite j'ai un 00000002.history, qui je présume correspond au moment ou j'ai promu mon esclave
Puis des 0...2...14, 0...2...15, ...
Il y a certainement quelque chose que je n'ai pas compris au niveau timeline ? Pouvez-vous m'éclairer ?
Ou un problème de configuration mais je ne vois pas où ? Quelle piste creuser ?
J'ai refait la procédure complète (mise en place Warm-Standby+Streaming, puis bascule, puis reconstruction) mais cette fois en partant d'un hot-backup de l'esclave devenu maître et CA MARCHE :-)
Peut-être le $HOME dans la restore_command ?
Je vais refaire la procédure complète en remplaçant le $HOME par /home/postgres pour voir.
Bonjour Guillaume,
Je n'ai qu'un répertoire PG_ARC des WAL archivés, au même endroit sur les 2 machines, ce qui semble écarter ce problème.
L'archivage est configuré de la façon suivante :
J'ai les paramètres suivants sur le maître :
wal_level = 'archive'
archive_mode = on
archive_command = 'sh /home/postgres/scripts/pg_archive_wal.sh "%p" "%f"'
Le pg_archive_wal.sh fait un CP en local dans le répertoire PG_ARC et un RSYNC sur l'esclave toujours dans le répertoire PG_ARC.
La restauration est configurée de la façon suivante :
Sur l'esclave j'ai le même fichier postgresql.conf.
Le recovery.conf contient :
standby_mode = 'on'
primary_conninfo = 'host=dev-postgres-01 port=5432 user=replic'
restore_command = 'cp $HOME/PG_ARC/%f %p'
trigger_file = '$HOME/bascule.txt'
Cela peut-il vous aider dans le diagnostic ?
Bonjour Sébastien,
Merci pour la réponse.
Le hot-backup fait à 4h et la bascule à 7h.
Cela ne peut pas fonctionner ?
Il faut forcément faire un hot-backup après bascule ?
Bonjour,
Je travaille sur un moteur 9.5.3 sous Cent-OS 7.2.
J'ai mis en place un warm-standby (log_shipping+streaming replication).
J'ai un répertoire PG_ARC sur mon maître et sur mon esclave qui contient les WAL archivés de moins de 3 jours.
Je teste aujourdhui la bascule (failover).
J'ai arrêté mon maître : ./pgsql stop. J'ai les logs suivants sur l'esclave :
2016-06-15 07:10:15 CEST [17265]: [445-1] user= 2016-06-14 12:08:09 CEST LOG: restartpoint starting: time
2016-06-15 07:10:19 CEST [17265]: [446-1] user= 2016-06-14 12:08:09 CEST LOG: restartpoint complete: wrote 32 buffers (0.0%); 0 transaction log file(s) added, 0 removed, 0 recycled; write=3.114 s, sync=0.019 s, total=3.140 s; sync files=18, longest=0.006 s, average=0.001 s; distance=153 kB, estimate=2794 kB
2016-06-15 07:10:19 CEST [17265]: [447-1] user= 2016-06-14 12:08:09 CEST LOG: recovery restart point at 2/220ECD68
2016-06-15 07:10:19 CEST [17265]: [448-1] user= 2016-06-14 12:08:09 CEST DETAIL: last completed transaction was at log time 2016-06-15 07:10:12.097019+02
2016-06-15 07:10:44 CEST [17268]: [2-1] user= 2016-06-14 12:08:09 CEST LOG: replication terminated by primary server
2016-06-15 07:10:44 CEST [17268]: [3-1] user= 2016-06-14 12:08:09 CEST DETAIL: End of WAL reached on timeline 1 at 2/23000098.
2016-06-15 07:10:44 CEST [17268]: [4-1] user= 2016-06-14 12:08:09 CEST FATAL: could not send end-of-streaming message to primary: no COPY in progress
cp: impossible d'évaluer « /home/postgres/PG_ARC/000000010000000200000023 »: Aucun fichier ou dossier de ce type
2016-06-15 07:10:44 CEST [17263]: [6-1] user= 2016-06-14 12:08:07 CEST LOG: invalid record length at 2/23000098
2016-06-15 07:10:44 CEST [7195]: [1-1] user= 2016-06-15 07:10:44 CEST FATAL: could not connect to the primary server: FATAL: the database system is shutting down
cp: impossible d'évaluer « /home/postgres/PG_ARC/000000010000000200000023 »: Aucun fichier ou dossier de ce type
2016-06-15 07:10:49 CEST [7223]: [1-1] user= 2016-06-15 07:10:49 CEST FATAL: could not connect to the primary server: could not connect to server: Connexion refusée
Is the server running on host "dev-postgres-01" (10.71.4.19) and accepting
TCP/IP connections on port 5432?
cp: impossible d'évaluer « /home/postgres/PG_ARC/000000010000000200000023 »: Aucun fichier ou dossier de ce type
J'ai donc fait un pg_ctl promote sur mon esclave. J'ai les logs suivants :
2016-06-15 07:10:58 CEST [17263]: [7-1] user= 2016-06-14 12:08:07 CEST LOG: received promote request
2016-06-15 07:10:58 CEST [17263]: [8-1] user= 2016-06-14 12:08:07 CEST LOG: redo done at 2/23000028
2016-06-15 07:10:58 CEST [17263]: [9-1] user= 2016-06-14 12:08:07 CEST LOG: last completed transaction was at log time 2016-06-15 07:10:12.097019+02
cp: impossible d'évaluer « /home/postgres/PG_ARC/000000010000000200000023 »: Aucun fichier ou dossier de ce type
cp: impossible d'évaluer « /home/postgres/PG_ARC/00000002.history »: Aucun fichier ou dossier de ce type
2016-06-15 07:10:58 CEST [17263]: [10-1] user= 2016-06-14 12:08:07 CEST LOG: selected new timeline ID: 2
cp: impossible d'évaluer « /home/postgres/PG_ARC/00000001.history »: Aucun fichier ou dossier de ce type
2016-06-15 07:10:59 CEST [17263]: [11-1] user= 2016-06-14 12:08:07 CEST LOG: archive recovery complete
2016-06-15 07:10:59 CEST [17263]: [12-1] user= 2016-06-14 12:08:07 CEST LOG: MultiXact member wraparound protections are now enabled
2016-06-15 07:10:59 CEST [17265]: [449-1] user= 2016-06-14 12:08:09 CEST LOG: checkpoint starting: force
2016-06-15 07:10:59 CEST [17261]: [3-1] user= 2016-06-14 12:08:07 CEST LOG: database system is ready to accept connections
2016-06-15 07:10:59 CEST [7234]: [1-1] user= 2016-06-15 07:10:59 CEST LOG: autovacuum launcher started
2016-06-15 07:10:59 CEST [17265]: [450-1] user= 2016-06-14 12:08:09 CEST LOG: checkpoint complete: wrote 0 buffers (0.0%); 0 transaction log file(s) added, 0 removed, 0 recycled; write=0.003 s, sync=0.000 s, total=0.559 s; sync files=0, longest=0.000 s, average=0.000 s; distance=15436 kB, estimate=15436 kB
2016-06-15 07:11:00 Archivage du WAL pg_xlog/000000010000000200000023.partial.
2016-06-15 07:11:00 Archivage du WAL pg_xlog/00000002.history.
Jusque là tout semble ok. Je me connecte sur mon nouveau maître, les dernières mises à jour sont faites.
Je veux maintenant restaurer la sauvegarde de cette nuit sur mon ancien maître, qui doit devenir mon nouvel esclave. Après démarrage, j'ai les logs suivants :
2016-06-15 08:11:50 CEST [1717]: [1-1] user= 2016-06-15 08:11:50 CEST LOG: database system was interrupted; last known up at 2016-06-15 04:10:02 CEST
2016-06-15 08:11:50 CEST [1717]: [2-1] user= 2016-06-15 08:11:50 CEST LOG: entering standby mode
2016-06-15 08:11:50 CEST [1717]: [3-1] user= 2016-06-15 08:11:50 CEST LOG: restored log file "000000010000000200000021" from archive
2016-06-15 08:11:51 CEST [1717]: [4-1] user= 2016-06-15 08:11:50 CEST LOG: redo starts at 2/21000098
2016-06-15 08:11:51 CEST [1717]: [5-1] user= 2016-06-15 08:11:50 CEST LOG: consistent recovery state reached at 2/210000C0
2016-06-15 08:11:51 CEST [1717]: [6-1] user= 2016-06-15 08:11:50 CEST LOG: restored log file "000000010000000200000022" from archive
cp: impossible d'évaluer « /home/postgres/PG_ARC/000000010000000200000023 »: Aucun fichier ou dossier de ce type
2016-06-15 08:11:51 CEST [1723]: [1-1] user= 2016-06-15 08:11:51 CEST LOG: fetching timeline history file for timeline 2 from primary server
2016-06-15 08:11:51 CEST [1723]: [2-1] user= 2016-06-15 08:11:51 CEST LOG: started streaming WAL from primary at 2/23000000 on timeline 1
2016-06-15 08:11:51 CEST [1723]: [3-1] user= 2016-06-15 08:11:51 CEST FATAL: could not receive data from WAL stream: ERROR: requested WAL segment 000000020000000200000023 has already been removed
cp: impossible d'évaluer « /home/postgres/PG_ARC/000000010000000200000023 »: Aucun fichier ou dossier de ce type
Dans mon répertoire de WAL archivés, j'ai :
-rw------- 1 postgres postgres 16777216 15 juin 04:10 000000010000000200000020
-rw------- 1 postgres postgres 16777216 15 juin 04:10 000000010000000200000021
-rw------- 1 postgres postgres 319 15 juin 04:10 000000010000000200000021.00000028.backup
-rw------- 1 postgres postgres 16777216 15 juin 07:10 000000010000000200000022
-rw------- 1 postgres postgres 16777216 15 juin 07:11 000000010000000200000023.partial
-rw------- 1 postgres postgres 16777216 15 juin 07:28 000000020000000200000023
-rw------- 1 postgres postgres 16777216 15 juin 07:28 000000020000000200000024
-rw------- 1 postgres postgres 16777216 15 juin 07:29 000000020000000200000025
-rw------- 1 postgres postgres 16777216 15 juin 07:29 000000020000000200000026
-rw------- 1 postgres postgres 16777216 15 juin 07:29 000000020000000200000027
-rw------- 1 postgres postgres 16777216 15 juin 07:29 000000020000000200000028
-rw------- 1 postgres postgres 16777216 15 juin 07:29 000000020000000200000029
-rw------- 1 postgres postgres 16777216 15 juin 07:29 00000002000000020000002A
-rw------- 1 postgres postgres 16777216 15 juin 07:29 00000002000000020000002B
-rw------- 1 postgres postgres 16777216 15 juin 07:29 00000002000000020000002C
-rw------- 1 postgres postgres 16777216 15 juin 07:29 00000002000000020000002D
-rw------- 1 postgres postgres 16777216 15 juin 07:29 00000002000000020000002E
-rw------- 1 postgres postgres 16777216 15 juin 07:29 00000002000000020000002F
-rw------- 1 postgres postgres 16777216 15 juin 07:29 000000020000000200000030
-rw------- 1 postgres postgres 16777216 15 juin 07:29 000000020000000200000031
-rw------- 1 postgres postgres 16777216 15 juin 07:29 000000020000000200000032
-rw------- 1 postgres postgres 16777216 15 juin 07:29 000000020000000200000033
-rw------- 1 postgres postgres 16777216 15 juin 07:29 000000020000000200000034
-rw------- 1 postgres postgres 16777216 15 juin 07:29 000000020000000200000035
-rw------- 1 postgres postgres 16777216 15 juin 07:29 000000020000000200000036
-rw------- 1 postgres postgres 16777216 15 juin 07:29 000000020000000200000037
-rw------- 1 postgres postgres 16777216 15 juin 07:29 000000020000000200000038
-rw------- 1 postgres postgres 16777216 15 juin 07:29 000000020000000200000039
-rw------- 1 postgres postgres 16777216 15 juin 07:29 00000002000000020000003A
-rw------- 1 postgres postgres 16777216 15 juin 07:29 00000002000000020000003B
-rw------- 1 postgres postgres 16777216 15 juin 07:29 00000002000000020000003C
-rw------- 1 postgres postgres 16777216 15 juin 07:29 00000002000000020000003D
-rw------- 1 postgres postgres 16777216 15 juin 07:29 00000002000000020000003E
-rw------- 1 postgres postgres 16777216 15 juin 07:29 00000002000000020000003F
-rw------- 1 postgres postgres 16777216 15 juin 07:29 000000020000000200000040
-rw------- 1 postgres postgres 16777216 15 juin 07:29 000000020000000200000041
-rw------- 1 postgres postgres 16777216 15 juin 07:29 000000020000000200000042
-rw------- 1 postgres postgres 16777216 15 juin 07:29 000000020000000200000043
-rw------- 1 postgres postgres 16777216 15 juin 07:29 000000020000000200000044
-rw------- 1 postgres postgres 16777216 15 juin 07:29 000000020000000200000045
-rw------- 1 postgres postgres 16777216 15 juin 07:29 000000020000000200000046
-rw------- 1 postgres postgres 16777216 15 juin 07:29 000000020000000200000047
-rw------- 1 postgres postgres 16777216 15 juin 07:29 000000020000000200000048
-rw------- 1 postgres postgres 16777216 15 juin 07:32 000000020000000200000049
-rw------- 1 postgres postgres 16777216 15 juin 07:32 00000002000000020000004A
-rw------- 1 postgres postgres 16777216 15 juin 07:32 00000002000000020000004B
-rw------- 1 postgres postgres 16777216 15 juin 07:32 00000002000000020000004C
-rw------- 1 postgres postgres 16777216 15 juin 07:32 00000002000000020000004D
-rw------- 1 postgres postgres 16777216 15 juin 07:32 00000002000000020000004E
-rw------- 1 postgres postgres 16777216 15 juin 07:32 00000002000000020000004F
-rw------- 1 postgres postgres 16777216 15 juin 07:33 000000020000000200000050
-rw------- 1 postgres postgres 16777216 15 juin 07:33 000000020000000200000051
-rw------- 1 postgres postgres 16777216 15 juin 07:33 000000020000000200000052
-rw------- 1 postgres postgres 16777216 15 juin 07:33 000000020000000200000053
-rw------- 1 postgres postgres 16777216 15 juin 07:33 000000020000000200000054
-rw------- 1 postgres postgres 16777216 15 juin 07:33 000000020000000200000055
-rw------- 1 postgres postgres 16777216 15 juin 07:33 000000020000000200000056
-rw------- 1 postgres postgres 16777216 15 juin 07:33 000000020000000200000057
-rw------- 1 postgres postgres 16777216 15 juin 07:33 000000020000000200000058
-rw------- 1 postgres postgres 16777216 15 juin 07:33 000000020000000200000059
-rw------- 1 postgres postgres 16777216 15 juin 07:33 00000002000000020000005A
-rw------- 1 postgres postgres 16777216 15 juin 07:33 00000002000000020000005B
-rw------- 1 postgres postgres 16777216 15 juin 07:33 00000002000000020000005C
-rw------- 1 postgres postgres 16777216 15 juin 07:33 00000002000000020000005D
-rw------- 1 postgres postgres 16777216 15 juin 07:33 00000002000000020000005E
-rw------- 1 postgres postgres 16777216 15 juin 07:33 00000002000000020000005F
-rw------- 1 postgres postgres 16777216 15 juin 07:33 000000020000000200000060
-rw------- 1 postgres postgres 16777216 15 juin 07:33 000000020000000200000061
-rw------- 1 postgres postgres 16777216 15 juin 07:33 000000020000000200000062
-rw------- 1 postgres postgres 16777216 15 juin 07:33 000000020000000200000063
-rw------- 1 postgres postgres 16777216 15 juin 07:33 000000020000000200000064
-rw------- 1 postgres postgres 16777216 15 juin 07:33 000000020000000200000065
-rw------- 1 postgres postgres 16777216 15 juin 08:01 000000020000000200000066
-rw------- 1 postgres postgres 16777216 15 juin 08:10 000000020000000200000067
-rw------- 1 postgres postgres 16777216 15 juin 08:10 000000020000000200000068
-rw------- 1 postgres postgres 319 15 juin 08:10 000000020000000200000068.00000028.backup
-rw------- 1 postgres postgres 42 15 juin 07:11 00000002.history
Avez-vous une idée du problème ?
D'avancer merci pour votre aide.
Bonjour,
Je travaille sur un moteur 9.5.3 sous Cent-OS 7.2.
J'ai mis en place un warm-standby (log_shipping+streaming replication = Archivage en Push).
En lisant le chapitre sur la réplication, dans le livre de Guillaume "PostgreSQL - Architecture et notions avancées" (bravo au passage, très riche, clair, et en plus en français), je vois qu'on parle d'archivage en PULL (depuis la 9.2) et de réplication synchrone en mémoire.
Existe t-il de la doc. sur ces techniques ? Quels sont les avantages/inconvénients ?
D'avance merci.
Super, merci Julien.
Re,
Sur le Maître, j'ai :
- les fichiers WAL "courants", dans /home/postgres/PG_XLOG,
- les fichiers WAL archivés, dans /home/postgres/PG_ARC.
Sur l'Esclave, j'ai :
- les fichiers WAL archivés du Maître, dans /home/postgres/PG_ARC
Ces fichiers archivés, le sont par ARCHIVE_COMMAND sur le maître (cp en local et rsync sur l'Esclave).
J'ai enlevé ARCHIVE_CLEANUP_COMMAND du recovery.conf sur l'Esclave.
Si l'Esclave a besoin de fichiers WAL, il va les copier de /home/postgres/PG_ARC vers /home/postgres/PG_XLOG grace à la RESTORE_COMMAND.
Sur l'esclave, les fichiers vont donc s'accumuler dans /home/postgres/PG_ARC. Il y a donc bien des fichiers à supprimer sur le secondaire ?
Bonjour Julien,
Merci pour la réponse.
Pour confirmer, je viens de reconstruire mon esclave, avec la sauvegarde de minuit et :
2016-06-01 07:29:40 CEST [17869]: [1-1] user= 2016-06-01 07:29:40 CEST LOG: database system was interrupted; last known up at 2016-06-01 00:10:01 CEST
2016-06-01 07:29:40 CEST [17869]: [2-1] user= 2016-06-01 07:29:40 CEST LOG: entering standby mode
cp: impossible d'évaluer « /home/postgres/PG_ARC_MASTER/000000010000000300000087 »: Aucun fichier ou dossier de ce type
2016-06-01 07:29:40 CEST [17871]: [1-1] user= 2016-06-01 07:29:40 CEST LOG: started streaming WAL from primary at 3/87000000 on timeline 1
2016-06-01 07:29:40 CEST [17871]: [2-1] user= 2016-06-01 07:29:40 CEST FATAL: could not receive data from WAL stream: ERROR: requested WAL segment 000000010000000300000087 has already been removed
cp: impossible d'évaluer « /home/postgres/PG_ARC_MASTER/000000010000000300000087 »: Aucun fichier ou dossier de ce type
2016-06-01 07:29:40 CEST [17873]: [1-1] user= 2016-06-01 07:29:40 CEST LOG: started streaming WAL from primary at 3/87000000 on timeline 1
2016-06-01 07:29:40 CEST [17873]: [2-1] user= 2016-06-01 07:29:40 CEST FATAL: could not receive data from WAL stream: ERROR: requested WAL segment 000000010000000300000087 has already been removed
Je vais donc retirer la commande ARCHIVE_CLEANUP_COMMAND du recovery.conf.
J'ai déjà un shell sur le maître qui nettoie les WAL archivés de plus de 2 jours. Je vais donc rajouter le nettoyage des mêmes fichiers sur l'esclave.
Est-ce une bonne pratique ?
Bonjour,
Je travaille sur un moteur 9.5.3 sous Cent-OS 7.2.
J'ai mis en place un warm-standby (log_shipping+streaming replication).
Sur mon maître, j'ai un shell pour mon ARCHIVE_COMMAND qui fait un CP en local et un RSYNC vers mon esclave.
J'ai un shell pour faire une sauvegarde de base toutes les 12 heures :
pg_basebackup -D ${BACKUP_DIR}/HOT_BACKUP -F t -R -x -z -c fast -l ${LABEL} -P -v -U replic
Cela génére un fichier .backup qui se "propage" dans mon répertoire d'archive local et dans celui de l'esclave.
Sur mon esclave, dans mon recovery.conf, j'ai indiqué :
ARCHIVE_CLEANUP_COMMAND='pg_archivecleanup /home/postgres/PG_ARC %r'
Les WAL archivés devenus inutiles sont bien supprimés au fil de l'eau, mais pas les .backup
Est-ce normal ? à moi de gérer ?
Bonjour Guillaume,
J'ai trouvé l'erreur, le .pgpass de mon esclave ne contenait pas la référence (en replication) vers mon maître.
Merci.
Bonjour,
Personne n'a "déporté" le password du recovery.conf vers le .pgpass ?
Super, merci Marc.
Donc si mon esclave traîne à redémarrer et que je n'ai pas défini de slot de réplication mais que j'ai activé l'archivage, les enregistrements WAL non transférés seront stockés dans les fichiers WAL archivés ?
Et comme mon esclave va les lire en redémarrant, tout va bien ?
Bonjour Marc,
Merci pour la réponse.
J'ai un peu de mal avec le mécanisme.
Les enregistrements WAL sont stockés dans les fichiers WAL "courants" et transférés sur l'esclave au fil de l'eau ?
Si je perds mon esclave, que se passe t'il ? les enregistrements WAL s'accumulent dans les fichiers WAL. Mais ils vont être recyclés au bout d'un moment ?
Voulez-vous bien m'éclairer sur le sujet, svp ?
Bonjour Guillaume,
Effectivement, la communication est revenue, c'est juste un peu long.
Est-ce lié aux paramètres ci-dessous du PostgreSQL.conf ?
tcp_keepalives_idle = 10
tcp_keepalives_interval = 10
tcp_keepalives_count = 0
Comment cela fonctionne-t-il ?
J'ai activé l'archivage des fichiers WAL.
Le transfert des enregistrements WAL se fait au travers du réseau.
Si celui-ci est coupé, est-ce que les enregistrements WAL sont stockés dans les fichiers WAL ?
Puis archivés ?
Puis restaurés sur l'esclave ?
Pourriez-vous décrire le mécanisme, svp ?
Merci.
Bonjour,
Je travaille sur un moteur 9.5.3 sous Cent-OS 7.2. J'ai 2 VM pour moi tester la haute disponibilité.
J'ai mis en place la STREAMING REPLICATION.
J'arrête l'esclave.
J'insère 10000 lignes sur le Maître.
Je redémarre l'esclave, les 10000 lignes ne sont pas là.
La communication entre les 2 n'est pas restaurée automatiquement ?
Je dois faire un pg_ctl reload sur le Maître pour redémarrer Sender/Receiver. Est-ce normal ?
Merci pour votre aide.
Bonjour à tous,
Suite de mes tests : Le warm-standby en mode Streaming replication.
Sur le maître, modifier le fichier /home/postgres/PG_DATA/postgresql.conf :
max_wal_senders = 2
archive_timeout = 0 # Plus nécessaire
Sur le maître, ajouter au fichier /home/postgres/PG_DATA/pg_hba.conf
host replication replic mon-esclave/32 md5
Sur le maître, arrêter/Redémarrer l'instance :
/etc/init.d/.pgsql restart
Faire une sauvegarde de base sur le maître
Sur l'esclave, restaurer la sauvegarde :
cd /home/postgres/PG_DATA
tar xfv base.tar.gz
Sur l'esclave, supprimer les fichiers inutiles :
rm postmaster.pid
rm pg_xlog/*
Sur l'esclave, modifier le fichier /home/postgres/PG_DATA/postgresql.conf :
#wal_level = minimal
#archive_mode = off
#archive_command = ''
#max_wal_senders = 0
Sur l'esclave, éditer le fichier /home/postgres/PG_DATA/recovery.conf :
standby_mode = 'on'
primary_conninfo = 'host=mon-serveur port=5432 user=replic'
restore_command = 'cp /home/postgres/PG_ARC/%f %p'
archive_cleanup_command = 'pg_archivecleanup /home/postgres/PG_ARC %r'
Sur l'esclave, démarrer l'instance :
/etc/init.d/.pgsql start
Dans les logs, j'ai les messages :
2016-05-23 07:34:52 CEST [14653]: [23-1] user= 2016-05-23 07:34:43 CEST LOG: restored log file "00000001000000010000002F" from archive
2016-05-23 07:34:52 CEST [14653]: [24-1] user= 2016-05-23 07:34:43 CEST LOG: consistent recovery state reached at 1/2FFFFFF0
cp: impossible d'évaluer « /home/postgres/PG_ARC/000000010000000100000030 »: Aucun fichier ou dossier de ce type
2016-05-23 07:34:52 CEST [14689]: [1-1] user= 2016-05-23 07:34:52 CEST FATAL: could not connect to the primary server: fe_sendauth: no password supplied
cp: impossible d'évaluer « /home/postgres/PG_ARC/000000010000000100000030 »: Aucun fichier ou dossier de ce type
2016-05-23 07:34:52 CEST [14691]: [1-1] user= 2016-05-23 07:34:52 CEST FATAL: could not connect to the primary server: fe_sendauth: no password supplied
Certainement car je n'ai pas indiqué le password sur la ligne "primary_conninfo" de mon recovery.conf. Mais j'utilise un .pgpass, dans lequel j'ai ajouté :
mon-esclave:5432:replication:replic:mon-password
Comment indiqué à recovery.conf qu'il doit lire le password dans mon .pgpass ?
Bonjour Guillaume,
Merci pour l'intervention.
Le FORCE au niveau du checkpoint starting est également normal ?
J'ai ensuite promu mon esclave en maître : pg_ctl promote.
Dans les logs, j'ai les messages :
2016-05-20 11:28:24 CEST [7513]: [30-1] user= 2016-05-20 10:54:48 CEST LOG: received promote request
2016-05-20 11:28:24 CEST [7513]: [31-1] user= 2016-05-20 10:54:48 CEST LOG: redo done at 0/F3000098
2016-05-20 11:28:24 CEST [7513]: [32-1] user= 2016-05-20 10:54:48 CEST LOG: last completed transaction was at log time 2016-05-20 10:54:51.834983+02
2016-05-20 11:28:24 CEST [7513]: [33-1] user= 2016-05-20 10:54:48 CEST LOG: restored log file "0000000100000000000000F3" from archive
cp: impossible d'évaluer « /home/postgres/PG_ARC/00000002.history »: Aucun fichier ou dossier de ce type
2016-05-20 11:28:25 CEST [7513]: [34-1] user= 2016-05-20 10:54:48 CEST LOG: selected new timeline ID: 2
cp: impossible d'évaluer « /home/postgres/PG_ARC/00000001.history »: Aucun fichier ou dossier de ce type
2016-05-20 11:28:26 CEST [7513]: [35-1] user= 2016-05-20 10:54:48 CEST LOG: archive recovery complete
2016-05-20 11:28:26 CEST [7513]: [36-1] user= 2016-05-20 10:54:48 CEST LOG: MultiXact member wraparound protections are now enabled
2016-05-20 11:28:26 CEST [7516]: [13-1] user= 2016-05-20 10:54:50 CEST LOG: checkpoint starting: force
2016-05-20 11:28:26 CEST [7511]: [3-1] user= 2016-05-20 10:54:48 CEST LOG: database system is ready to accept connections
Pourquoi ces messages sur des fichiers history ?
Y-a-t'il un nouveau problème ?
Deuxième étape : Le Warm-standby.
Sur mon serveur 2, j'ai :
- restauré ma sauvegarde.
- supprimé les fichiers inutiles : rm postmaster.pid pg_xlog/*
- modifé le fichier postgresql.conf :
#wal_level = minimal
#archive_mode = off
#archive_command = ''
#max_wal_senders = 0
#archive_timeout = 0
- modifié le fichier recovery.conf :
standby_mode = 'on'
restore_command = 'cp /home/postgres/PG_ARC/%f %p'
archive_cleanup_command = 'pg_archivecleanup /home/postgres/PG_ARC %r'
- démarré l'instance
Dans les logs, j'ai les messages :
2016-05-20 10:54:48 CEST [7513]: [1-1] user= 2016-05-20 10:54:48 CEST LOG: database system was interrupted; last known up at 2016-05-20 10:50:56 CEST
2016-05-20 10:54:48 CEST [7513]: [2-1] user= 2016-05-20 10:54:48 CEST LOG: entering standby mode
2016-05-20 10:54:48 CEST [7513]: [3-1] user= 2016-05-20 10:54:48 CEST LOG: restored log file "0000000100000000000000DF" from archive
2016-05-20 10:54:49 CEST [7513]: [4-1] user= 2016-05-20 10:54:48 CEST LOG: restored log file "0000000100000000000000DE" from archive
2016-05-20 10:54:50 CEST [7513]: [5-1] user= 2016-05-20 10:54:48 CEST LOG: redo starts at 0/DE002180
2016-05-20 10:54:50 CEST [7513]: [6-1] user= 2016-05-20 10:54:48 CEST LOG: restored log file "0000000100000000000000DF" from archive
2016-05-20 10:54:51 CEST [7513]: [7-1] user= 2016-05-20 10:54:48 CEST LOG: restored log file "0000000100000000000000E0" from archive
2016-05-20 10:54:52 CEST [7513]: [8-1] user= 2016-05-20 10:54:48 CEST LOG: restored log file "0000000100000000000000E1" from archive
2016-05-20 10:54:53 CEST [7513]: [9-1] user= 2016-05-20 10:54:48 CEST LOG: restored log file "0000000100000000000000E2" from archive
2016-05-20 10:54:57 CEST [7513]: [10-1] user= 2016-05-20 10:54:48 CEST LOG: consistent recovery state reached at 0/E2944290
2016-05-20 10:54:57 CEST [7513]: [11-1] user= 2016-05-20 10:54:48 CEST LOG: restored log file "0000000100000000000000E3" from archive
2016-05-20 10:54:57 CEST [7513]: [12-1] user= 2016-05-20 10:54:48 CEST LOG: restored log file "0000000100000000000000E4" from archive
2016-05-20 10:54:58 CEST [7513]: [13-1] user= 2016-05-20 10:54:48 CEST LOG: restored log file "0000000100000000000000E5" from archive
2016-05-20 10:54:59 CEST [7513]: [14-1] user= 2016-05-20 10:54:48 CEST LOG: restored log file "0000000100000000000000E6" from archive
2016-05-20 10:54:59 CEST [7513]: [15-1] user= 2016-05-20 10:54:48 CEST LOG: restored log file "0000000100000000000000E7" from archive
2016-05-20 10:55:01 CEST [7513]: [16-1] user= 2016-05-20 10:54:48 CEST LOG: restored log file "0000000100000000000000E8" from archive
2016-05-20 10:55:02 CEST [7513]: [17-1] user= 2016-05-20 10:54:48 CEST LOG: restored log file "0000000100000000000000E9" from archive
2016-05-20 10:55:05 CEST [7513]: [18-1] user= 2016-05-20 10:54:48 CEST LOG: restored log file "0000000100000000000000EA" from archive
2016-05-20 10:55:07 CEST [7513]: [19-1] user= 2016-05-20 10:54:48 CEST LOG: restored log file "0000000100000000000000EB" from archive
2016-05-20 10:55:07 CEST [7513]: [20-1] user= 2016-05-20 10:54:48 CEST LOG: restored log file "0000000100000000000000EC" from archive
2016-05-20 10:55:10 CEST [7513]: [21-1] user= 2016-05-20 10:54:48 CEST LOG: restored log file "0000000100000000000000ED" from archive
2016-05-20 10:55:11 CEST [7513]: [22-1] user= 2016-05-20 10:54:48 CEST LOG: restored log file "0000000100000000000000EE" from archive
2016-05-20 10:55:15 CEST [7513]: [23-1] user= 2016-05-20 10:54:48 CEST LOG: restored log file "0000000100000000000000EF" from archive
2016-05-20 10:55:17 CEST [7513]: [24-1] user= 2016-05-20 10:54:48 CEST LOG: restored log file "0000000100000000000000F0" from archive
cp: impossible d'évaluer « /home/postgres/PG_ARC/0000000100000000000000F1 »: Aucun fichier ou dossier de ce type
cp: impossible d'évaluer « /home/postgres/PG_ARC/0000000100000000000000F1 »: Aucun fichier ou dossier de ce type
cp: impossible d'évaluer « /home/postgres/PG_ARC/0000000100000000000000F1 »: Aucun fichier ou dossier de ce type
Est-ce juste un avertissement parce que le fichier WAL archivé (de mon maître) n'est pas encore présent ?
Où s'agit-il d'un autre problème ?
