Re: Restauration d'une sauvegarde PITR avec recovery_target_time

On 19/06/2016 11:44, Éric de la Musse wrote:
> Le Sun, 19 Jun 2016 08:59:51 +0200,
> Marc Cousin <[email protected]> a écrit :
>
>> 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 ?
> Bien vu ! C'est exactement ca. La base actuellement est quasi vide et un
> cron passe dessus tous les jours à .... 5 heures pour effectuer des
> taches administratives.
>
> En fait il ne se passe rien entre 3 heures et 5 heures du matin, y
> compris a priori une transaction en cours non commitée.
>
>> 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…
> Oui c'est bien le comportement constaté. On pourrait peut être
> s'attendre à ce qu'il s'arrête dès que l'heure est atteinte
> puisqu'au-delà il n'est pas censé prendre les commits qui surviennent
> même si les transactions ont été initiées avant.
En fait ça ne serait pas possible: dans le journal, tu as les
modifications de toutes les transactions qui sont entrelacées… Il n'y a
pas moyen de savoir quand chacune va se terminer, tant qu'on n'a pas
atteint le point où elle se termine dans le journal (c'est là qu'on a
l'horodatage).

Si on reprend ton cas, le moteur va devoir tout rejouer jusqu'à la
première transaction qui commit juste après le point demandé (celle de
5h), en excluant cette transaction.

En simplifiant un peu, ce que Postgres fait donc, c'est qu'il rejoue
tout le contenu du journal jusqu'à ce point, et au lieu de commiter
cette dernière transaction, il l'annule (avec toutes les autres
transactions encore en cours à ce point), ce qui amène la base à l'état
«juste avant». C'est exactement pareil dans Oracle par exemple. Mais
c'est vrai que le message est un peu préoccupant dans ton cas
particulier, vu le trou béant entre 3h et 5h :)


--
Envoi via la liste pgsql-fr-generale ([email protected])