Re: [pgsql-fr-generale] Re: [pgsql-fr-generale] Re: [pgsql-fr-generale] pg_start_backup et cohérence de la base

CQFD, c'est parfait. Maintenant j'ai tout compris. Merci beaucoup!

Le 6 octobre 2014 11:20, Guillaume Lelarge <guillaume(at)lelarge(dot)info> a écrit
:

> Le 6 octobre 2014 11:18, adrien nayrat <adrien(dot)nayrat(dot)axess(at)gmail(dot)com> a
> écrit :
>
>
>>
>> Le 6 octobre 2014 10:57, Guillaume Lelarge <guillaume(at)lelarge(dot)info> a
>> écrit :
>>
>>>
>>>
>>> Le 6 octobre 2014 10:54, adrien nayrat <adrien(dot)nayrat(dot)axess(at)gmail(dot)com>
>>> a écrit :
>>>
>>>> Merci pour vos réponses, je comprends mieux.
>>>>
>>>>
>>>> Ensuite, à l'appel de pg_stop_backup(), le fichier backup_label est
>>>>> modifié pour ajouter le point (WAL + emplacement) ou en était l'instance à
>>>>> ce moment. Et c'est ce point qui devra être atteint lors de la restauration
>>>>> pour que MVCC puisse présenter des données cohérentes aux clients de
>>>>> l'instance restaurée.
>>>>
>>>> Dois-je comprendre qu'il faut également sauvegarder ce fichier
>>>> backup_label à l'issue du pg_stop_backup(), ainsi que les WAL jusqu'au
>>>> pg_stop_backup() ?
>>>>
>>>>
>>> Non, parce qu'il est archivé comme les journaux de transactions.
>>>
>>>
>> Il faut donc mettre en place un système d'archivage des WAL sur une autre
>> machine ?
>>
>
> Oui, bien sûr. Une sauvegarde PITR (donc avec pg_start_backup,
> pg_stop_backup) sans archivage ne sert à rien. D'ailleurs, dans les
> dernières versions de PostgreSQL, le pg_stop_backup ne termine pas si
> l'archivage n'est pas fonctionnel (pour ce que PostgreSQL peut en savoir en
> tout cas :) ).
>
> --
> Guillaume.
> http://blog.guillaume.lelarge.info
> http://www.dalibo.com
>