Re: Restauration d'une sauvegarde PITR avec recovery_target_time

On 19/06/2016 00:07, Éric de la Musse wrote:
> Le Sat, 18 Jun 2016 22:27:14 +0200,
> Dimitri Fontaine <dim(at)tapoueh(dot)org> a écrit :
>
>> Éric de la Musse <eric901(at)pouik(dot)org> writes:
>>> Mais la restauration s'effectue jusqu'à 2016-06-18
>>> 05:00:02.655446+02 ...soit 2 heures de plus que l'objectif fixé.
>> À quelle heure s'est terminé le backup depuis lequel le PITR est
>> effectué ?
> Quelques secondes après avoir commencé. La base est quasi vide
> aujourd'hui.
>
>> Le recovery ne peut pas s'arrêter avant d'avoir atteind un
>> point de consistence dans les WAL et par construction ce point ne peut
>> pas exister en plein milieu d'un backup… il faut rejouer au moins les
>> WAL produits pendant le backup pour atteindre le point au plus tôt…
> A priori le problème ne se situe donc pas là. Et puis le décalage entre
> l'heure restaurée et l'heure demandée est pile 2 heures. Cela
> correspond au décalage avec UTC. Ce n'est probablement pas un hasard.
>
> Pour compléter l'exposé je précise quand même que la restauration n'a
> pas lieu sur le serveur d'origine des données mais via un container
> docker. Le but est de mettre en place une procèdure de restauration
> continue qui valide à intervalle périodique (tous les jours) que la
> restauration fonctionne (un peu sur le principe de la CI en matière de
> dev). Pour ca je suis en train de créer une image docker.
>
> Tout ca pour dire que la restauration s'effectue via un container
> qui n'a pas forçément la même configuration que le serveur de
> prod (bien sûr c'est la même architecture pour que le cluster soit
> compatible entre le serveur source et celui de restauration).
>
> J'ai imaginé aussi que le problème pouvait provenir de la date
> système/time zone qui différait effectivement entre les 2 serveurs: la
> prod sur Europe/Paris et le container sur UTC. Mais même en
> positionnant le container sur Europe/Paris ca n'a pas changé le
> comportement. Et puis on voit bien au lancement de la restauration que
> l'heure du backup est reconnue correctement. Donc a priori j'ai rejeté
> cette piste.
>
Pour essayer l'explication simple avant de chercher compliqué, il ne
peut pas ne pas y avoir eu de transaction qui ait commité entre 3h et 5h
du matin ?

Parce que le recover regarde le timestamp des transactions et s'arrête
juste avant la transaction qui ferait dépasser la date demandée… ça se
trouve, il y avait un gros batch d'insertion dans une grosse transaction
qui a généré tous ces journaux, mais qui n'a commité qu'à 5h du matin.

Ça serait un gros hasard, qu'il n'y ait qu'une seule transaction, qui
ait commité à presque 5h pile, mais bon, d'habitude le recover ça marche
plutôt bien :)

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