Re: vacuum full et hot standby WAL stream: FATAL

From: adrien nayrat <adrien(dot)nayrat(dot)axess(at)gmail(dot)com>
To: Lionel Bargeot <lionel(dot)bargeot(at)gmail(dot)com>
Cc: pgsql-fr-generale <pgsql-fr-generale(at)postgresql(dot)org>
Subject: Re: vacuum full et hot standby WAL stream: FATAL
Date: 2016-05-24 16:46:01
Message-ID: CAHf5EFQA0Kx4i3-uj4TA4KFrMsHNmT1HtwgGAkRP8oBUV888Gw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-fr-generale

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 <lionel(dot)bargeot(at)gmail(dot)com> 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/28495974b30f304b064b36c372654517.squirrel@sq.gransy.com
>>
>> 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 (pgsql-fr-generale(at)postgresql(dot)org)

--
Envoi via la liste pgsql-fr-generale (pgsql-fr-generale(at)postgresql(dot)org)

In response to

Browse pgsql-fr-generale by date

  From Date Subject
Next Message Stéphane Schildknecht 2016-05-24 16:47:14 Re: vacuum full et hot standby WAL stream: FATAL
Previous Message Lionel Bargeot 2016-05-24 16:24:40 Re: vacuum full et hot standby WAL stream: FATAL