Forums PostgreSQL.fr

dt

Membre

Réplication par fichier journaux : fonctionnement aléatoire...

Bonjour,

j'essaye depuis plusieurs jours de mettre en place la réplication par fichier journaux entre 2 serveurs PostgreSQL, en préalable de la réplication par streaming. Et des fois, ça fonctionne, mais plus souvent, ça ne fonctionne pas, et je n'arrive pas à savoir pourquoi ...
Voilà comment je procède ;
Je fais une sauvegarde du serveur maître avec barman. La configuration de l'archivage est configuré comme suit :

wal_level = hot_standby
checkpoint_segments = 3
checkpoint_timeout = 5min
checkpoint_completion_target = 0.5
checkpoint_warning = 30s
archive_mode = on
archive_command = 'rsync -a %p barman@backup:/var/lib/barman/master/incoming/%f'
archive_timeout = 60

Je restaure cette sauvegarde sur le serveur esclave, je redémarre ma base, c'est OK, je retrouve bien mes enregistrements. Je mets donc en place la réplication par fichier journaux. Voici la partie réplication de mon postgresql.conf :

hot_standby = on
max_standby_archive_delay = 30s
max_standby_streaming_delay = 30s
wal_receiver_status_interval = 10s
hot_standby_feedback = off

Mon recovery.conf :

restore_command = '/var/lib/postgresql/9.1/main/restore_command.sh %f %p'
standby_mode = on
archive_cleanup_command = 'pg_archivecleanup /var/lib/postgres/9.1/main/pg_xlog %r'

Mon script restore_command.sh :

#!/bin/bash
# $1: %f nom du journal souhaité
# $2: %p nom du chemin où copier le journal
scp barman@backup:master/wals/0000000100000000/$1 $2
bzip2 -d $2
mv $2.out $2

Mon script archive_command.sh :

#!/bin/bash
# $1: %r le fichier le plus ancien à conservé
pg_archivecleanup /var/lib/postgres/9.1/main/pg_xlog $1

Et là, je n'arrive plus à redémarrer postgresql, j'ai ça dans les logs :

2013-12-18 18:05:53.327 CET,,,2334,,52b1d5f0.91e,3,,2013-12-18 18:05:52 CET,,0,LOG,00000,"restored log file ""00000001000000000000008C"" from archive",,,,,,,,,""
2013-12-18 18:05:53.327 CET,,,2334,,52b1d5f0.91e,4,,2013-12-18 18:05:52 CET,,0,LOG,00000,"invalid record length at 0/8C0000A8",,,,,,,,,""
2013-12-18 18:05:53.411 CET,,,2334,,52b1d5f0.91e,5,,2013-12-18 18:05:52 CET,,0,WARNING,01000,"WAL was generated with wal_level=minimal, data may be missing",,"This happens if you temporarily set wal_level=minimal without taking a new base backup.",,,,,,,""
2013-12-18 18:05:53.412 CET,,,2334,,52b1d5f0.91e,6,,2013-12-18 18:05:52 CET,,0,FATAL,XX000,"hot standby is not possible because wal_level was not set to ""hot_standby"" on the master server",,"Either set wal_level to ""hot_standby"" on the master, or turn off hot_standby here.",,,,,,,""

Si je mets hot_standby sur off, ça reste bloqué en démarrage : service postgresql restart me dit ok, mais je peux pas me connecter, et j'ai ça dans les logs :

2013-12-18 18:07:10.639 CET,"postgres","postgres",2413,"[local]",52b1d63e.96d,2,"",2013-12-18 18:07:10 CET,,0,FATAL,57P03,"the database system is starting up",,,,,,,,,""
2013-12-18 18:07:10.944 CET,,,2404,,52b1d63e.964,3,,2013-12-18 18:07:10 CET,,0,LOG,00000,"restored log file ""00000001000000000000008C"" from archive",,,,,,,,,""
2013-12-18 18:07:10.944 CET,,,2404,,52b1d63e.964,4,,2013-12-18 18:07:10 CET,,0,LOG,00000,"invalid record length at 0/8C0000A8",,,,,,,,,""
2013-12-18 18:07:10.964 CET,,,2404,,52b1d63e.964,5,,2013-12-18 18:07:10 CET,,0,WARNING,01000,"WAL was generated with wal_level=minimal, data may be missing",,"This happens if you temporarily set wal_level=minimal without taking a new base backup.",,,,,,,""
2013-12-18 18:07:10.967 CET,,,2404,,52b1d63e.964,6,,2013-12-18 18:07:10 CET,,0,LOG,00000,"consistent recovery state reached at 0/8C000100",,,,,,,,,""
2013-12-18 18:07:10.967 CET,,,2404,,52b1d63e.964,7,,2013-12-18 18:07:10 CET,,0,LOG,00000,"record with zero length at 0/8C000100",,,,,,,,,""
2013-12-18 18:07:11.145 CET,,,2424,"",52b1d63f.978,1,"",2013-12-18 18:07:11 CET,,0,LOG,00000,"connection received: host=[local]",,,,,,,,,""

J'ai pensé à moment donné que le problème venait que barman compressait les archives, puisqu'en lui disant de ne pas les compresser, ça fonctionnait. J'ai remis la compression, ça fonctionnait. J'ai recommencé à 0, ça marche plus ... J'ai fait un md5 des fichiers archives sur le maitre et après décompression sur l'esclave, c'est le même...
J'ai pensé qu'il me mettait record with zero length at 0/8C000100 parce que je n'avais pas modifié la base après la sauvegarde et que mon fichier wal était vide, j'ai donc inséré un enregistrement, attendu que mon fichier wal arrive sur le serveur de backup, ça a marché. J'ai recommencé, ça marche de nouveau plus...
Bref, je suis incapable de voir la différence des cas où ça fonctionne, et où ça ne fonctionne pas...
PostgreSQL est en version 9.1.11 sur les deux machines, des Ubuntu Server 12.04.

Merci de votre aide, je n'ai vraiment pas la moindre idée de ce qui se passe.

gleu

Administrateur

Re : Réplication par fichier journaux : fonctionnement aléatoire...

Il y a déjà une grosse incompréhension : pourquoi utiliser barman ? barman, c'est pour de la sauvegarde, pas pour de la réplication. De plus, c'est un outil qui vous facilite la vie, mais pour cela, il faut avoir compris comment cela fonctionnait. Et pour comprendre, il vaut mieux commencer par le système de base. Donc oubliez barman dans un premier temps.

Ensuite, vous donnez plein de détails mais ça part un peu dans tous les sens. Il serait préférable de montrer ce que vous faites, de A à Z. Par exemple, quand vous dites "je restaure cette sauvegarde...", OK, mais comment ?

Bref, pour en revenir sur les messages d'erreur que vous avez, tout d'abord évitez le format csvlog, c'est difficile à lire par un humain (stderr est préférable). Ensuite, chaque exemple indique que wal_level est à minimal, ce qui n'est pas bon. Il faut qu'il soit au minimum à archive, voire mieux à hot_standby.

Avez-lu des articles sur ce sujet ? notamment ceux qui se trouvent sur dalibo.org ? (je pense surtout à http://www.dalibo.org/glmf131_mise_en_p … resl_9.0_1 et http://www.dalibo.org/glmf131_mise_en_p … esl_9.0_2)

---

Guillaume.

dt

Membre

Re : Réplication par fichier journaux : fonctionnement aléatoire...

Bonjour, et merci pour la réponse.

Si j'ai utilisé barman, c'est simplement que la documentation de PostgreSQL indique que les fichiers wals utilisés pour la réplication doivent être à un endroit accessible par le maitre et l'esclave. J'ai donc tout naturellement pensé au serveur de sauvegarde, pour éviter d'utiliser un autre serveur pour faire la même chose. Pour restaurer la base sur le serveur esclave avant la mise en place de la réplication, je la fais avec barman également. Ce n'est qu'une fois que la base restaurée tourne que je mets en œuvre la réplication, en demandant au serveur esclave d'aller chercher les fichiers journaux que le maitre a envoyé sur le serveur de sauvegarde. Et c'est quand j'arrive à faire tourner le réplication par transfert de fichiers journaux que je met en place la réplication par streaming, qui elle marche très bien. Est-ce les bonnes étapes : Restauration -> Réplication par fichier journal -> Réplication par streaming ?

Quant au message d'erreur indiquant que wal_level est à minimal, il a toujours été à hot_standby, du moins après l'import de la base. Je ne comprends donc pas pourquoi j'ai ce message. Je vais essayer ce matin en le mettant à hot_standby avant l'import, juste après l'installation de PostgreSQL.

Et merci pour ces deux articles que je ne connaissais pas, je vais me plonger dedans. Pour mettre en place la réplication, je m'étais basé uniquement sur la documentation officielle. J'espère trouver quelques pistes intéressantes dans ces articles.

Dernière modification par dt (19/12/2013 10:27:00)

gleu

Administrateur

Re : Réplication par fichier journaux : fonctionnement aléatoire...

Il y a quelque chose que vous faites mal. Difficile de dire quoi, mais il y a un truc qui se passe mal. Vous devez avoir le wal_level à autre chose que minimal avant de faire la sauvegarde de base car vous devez avoir l'archivage fonctionnel. Et un archivage fonctionnel, ça veut dire un wal_level à autre chose que minimal.

---

Guillaume.

dt

Membre

Re : Réplication par fichier journaux : fonctionnement aléatoire...

Mais justement c'est ça que je ne comprends pas : sur le master, le wal_level a toujours été à hot_standby, il n'a jamais été à minimal !
Pourquoi donc ai-je ce message ? Ça va me rendre fou. Ce matin j'ai pété la VM maitre pour réinstaller ubuntu, et la première chose que j'ai faite, c'est de mettre wal_level à hot_standby et de redémarrer postgresql, avant même d'importer ma base de test. Et pourtant, j'ai encore eu ce message de wal_level à minimal... J'ai noté étape par étape ce que je faisais, je n'ai pas trouvé ce qui cloche...

J'en suis maintenant à faire une sauvegarde manuelle comme décrit dans l'article plutôt qu'avec barman, mais je crains que ça continue pareil. Un coup ça marche, je refais pareil, ça marche plus, et sans que je trouve ce qui diffère...

PS : merci pour le truc des logs à stderr, les logs sont effectivement beaucoup plus facile à lire.

gleu

Administrateur

Re : Réplication par fichier journaux : fonctionnement aléatoire...

Après avoir recréé le maître, vous avez fait de nouveau une sauvegarde du maître ? après la configuration ?

---

Guillaume.

dt

Membre

Re : Réplication par fichier journaux : fonctionnement aléatoire...

Tout à fait. Voici les étapes que j'ai suivi :
1 - j'ai recréé le maitre
2 - je l'ai passé à wal_level = hot_standby
3 - je l'ai redémarré
4 - j'ai mis à jour ubuntu, pour avoir la même version que l'esclave
5 - j'ai importé la base sur le maitre
6 - j'ai fait la sauvegarde du maitre avec barman
7 - j'ai restauré la base sur l'esclave toujours avec barman
8 - j'ai redémarré postgresql sur l'esclave
9 - j'ai en place la réplication : création des fichiers restore_command.sh, recovery.conf, archive_command.sh, j'ai mis dans postgresql.conf hot_standby = on
10 - Postgresql n'a pas redémarré, voici les logs :

2013-12-19 15:02:59 CET  LOG:  entering standby mode
2013-12-19 15:02:59 CET  LOG:  connection received: host=[local]
2013-12-19 15:02:59 CET [local] LOG:  incomplete startup packet
bzip2: Can't guess original name for pg_xlog/RECOVERYXLOG -- using pg_xlog/RECOVERYXLOG.out
2013-12-19 15:03:00 CET  LOG:  connection received: host=[local]
2013-12-19 15:03:00 CET [local] FATAL:  the database system is starting up
2013-12-19 15:03:00 CET  LOG:  restored log file "00000001000000010000005B" from archive
2013-12-19 15:03:00 CET  LOG:  record with zero length at 1/5B0000A8
2013-12-19 15:03:00 CET  WARNING:  WAL was generated with wal_level=minimal, data may be missing
2013-12-19 15:03:00 CET  HINT:  This happens if you temporarily set wal_level=minimal without taking a new base backup.
2013-12-19 15:03:00 CET  FATAL:  hot standby is not possible because wal_level was not set to "hot_standby" on the master server
2013-12-19 15:03:00 CET  HINT:  Either set wal_level to "hot_standby" on the master, or turn off hot_standby here.
2013-12-19 15:03:00 CET  LOG:  startup process (PID 2711) exited with exit code 1
2013-12-19 15:03:00 CET  LOG:  aborting startup due to startup process failure

J'ai beau cherché, je ne vois pas ce qui diffère de la procédure telle que décrite dans la doc officielle, si ce n'est que je me sers de barman pour la sauvegarde et que je dois décompresser les fichiers wals. Mais d'après ce que j'ai compris, barman ne fait qu'automatiser la procédure de sauvegarde manuelle, dans les logs je vois bien le select pg_start_backup() et le pg_end_backup.
Le pire, c'est que la semaine dernière tout a fonctionné du premier coup. C'est depuis que j'ai voulu refaire l'ensemble des opérations et les noter en prévision du passage en prod que ça coince...
--
Denis

gleu

Administrateur

Re : Réplication par fichier journaux : fonctionnement aléatoire...

Refaites sans barman. Pas que barman soit un mauvais logiciel, bien au contraire. Mais clairement, ça va être un soucis pour vous aider.

Juste une petite question : on est d'accord que le maître et l'esclave sont des machines de même architecture (ie, les deux 32 ou 64 bits ?).

---

Guillaume.

dt

Membre

Re : Réplication par fichier journaux : fonctionnement aléatoire...

Tout à fait, les 2 VMs sont identiques, à la taille du disque près.
Je viens de finir les essais sans barman, j'ai eu des problèmes d'espace disque justement. Je casse l'esclave et le remonte avant de recommencer...

Merci pour votre aide.

dt

Membre

Re : Réplication par fichier journaux : fonctionnement aléatoire...

Bon ça y est, tout fonctionne.
Je me suis inspiré de la procédure dans les articles que tu m'as donnés. Je fais une sauvegarde manuelle, et pour le transfert des journaux, j'utilise un script qui les envoie à deux endroits : sur le serveur de sauvegarde de Barman comme auparavant, ainsi que dans un répertoire sur le serveur esclave. Mais je ne vois pas pourquoi ça ne fonctionnait pas auparavant avec Barman, et je voudrais bien savoir ce qui clochait. Peut être qu'en faisant la restauration avec Barman, et en conservant l'envoi des fichiers journaux sur l'esclave ça marchera. On verra si j'ai le temps de faire l'essai.
Maintenant, je m'amuse avec pgpool pour mettre en place un failover auto.

Merci pour ton aide.

Denis