Re: vacuum full et hot standby WAL stream: FATAL
adrien nayrat <[email protected]>
| Newsgroups | gmane.comp.db.postgresql.french |
|---|---|
| Message-ID | <CAHf5EFQA0Kx4i3-uj4TA4KFrMsHNmT1HtwgGAkRP8oBUV888Gw@mail.gmail.com> |
Bonjour, Comme indiqué par Lionel votre slave a "décroché" de la streaming réplication. Celui-ci demande des journaux que le maître a déjà recyclé. Vous n'avez pas d'autres solution que de reconstruire votre esclave. Plutôt que d'augmenter wal_keep_segments vous devriez mettre en place l'archivage : https://blog.anayrat.info/2015/01/02/replication-par-transfert-de-journaux-de-transaction-part-2/ Attention si le maître n'arrive plus à archiver il conserve les journaux de transaction, jusqu'à remplir le système de fichier. L'inconvénient de wal_keep_segments est qu'en cas de forte activité en écriture) le maître peut nettoyer des wal encore nécessaire à l'esclave (s'il n'est pas suffisamment élevé). Le 24 mai 2016 à 18:24, Lionel Bargeot <[email protected]> a écrit : > Bonjour > > la rotation de vos fichiers de transaction sur le maitre est certainement > trop "courte" au regard de la capacité d'absorption des modifications par > l'esclave. Augmentez wal_keep_segments. Vous pouvez le régler en fonction de > votre espace disponible (1 segment fait 16 Mo par défaut, Il ne faudrait pas > saturer à terme le filesystem du maitre). > > En revanche votre réplication est cassée. Vous devez réinitialiser votre > cluster esclave pour la relancer. > > Lionel > > > Le 24/05/2016 17:57, Sébastien Dinot a écrit : >> >> ----- Mail original ----- >>> >>> j'ai un plantage suite à l’exécution d'un vacuum full sur une base >>> primaire , vacuum full afin de palier à une fragmentation suite à >>> une série d'insert/update sur un table d'historique instrumenté par >>> un autovacuum >>> L’erreur sur l’esclave qui le fait planté :=> 2016-05-24 03:10:07.420 >>> UTC 0 FATAL: could not receive data from WAL stream: FATAL: >>> requested WAL segment 00000063000003B700000091 has already been >>> removed >>> Sur le maitre, on a l’équivalent :=> 2016-05-24 00:00:00.908 UTC >>> replication [unknown] 0 47/0FATAL: requested WAL segment >>> 00000063000003B700000091 has already been removed >> >> J'ai trouvé plusieurs occurrence du message d'erreur sur le net ; la >> solution semble être d'augmenter le nombre de segments (variable >> wal_keep_segments) ou d'activer l'archivage du WAL : >> >> >> http://stackoverflow.com/questions/28201475/how-do-i-fix-a-postgresql-9-3-slave-that-cannot-keep-up-with-the-master >> >> http://www.postgresql.org/message-id/[email protected] >> >> Plus d'infos ici : >> >> https://wiki.postgresql.org/wiki/Streaming_Replication >> http://www.postgresql.org/docs/9.2/static/runtime-config-replication.html >> >> Sébastien >> > > > > -- > Envoi via la liste pgsql-fr-generale ([email protected]) -- Envoi via la liste pgsql-fr-generale ([email protected])