Re: pertinence pgbarman / cloud

Lists: pgsql-fr-generale
From: Cloc <ccastello(at)athmo(dot)eu>
To: pgsql-fr-generale(at)postgresql(dot)org
Subject: pertinence pgbarman / cloud
Date: 2014-10-02 12:52:44
Message-ID: 542D4A9C.10300@athmo.eu
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-fr-generale

Bonjour.

Rebondissant sur la très récente discussion concernant les scripts de
backup (et de récupération), je me posais la question de la pertinence
d'une solution telle que pg_barman dans le cadre d'un serveur disposé
sur une plateforme de cloud intégrant une réplication hors site.

En cas de problème, étant donné que les fichiers WAL sont répliqués avec
la machine, le redémarrage avec un minimum de pertes devrait être
réalisable, non ?

Salutations.

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


From: Dimitri Fontaine <dimitri(at)2ndQuadrant(dot)fr>
To: Cloc <ccastello(at)athmo(dot)eu>
Cc: pgsql-fr-generale(at)postgresql(dot)org
Subject: Re: pertinence pgbarman / cloud
Date: 2014-10-02 13:31:27
Message-ID: m2d2aaionk.fsf@2ndQuadrant.fr
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-fr-generale

Cloc <ccastello(at)athmo(dot)eu> writes:
> En cas de problème, étant donné que les fichiers WAL sont répliqués avec la
> machine, le redémarrage avec un minimum de pertes devrait être réalisable,
> non ?

La réplication n'est *jamais* une solution adéquate aux problèmes que
l'on résoud via une restauration de données : DROP TABLE en production
est un exemple typique.

L'ordre sera répliqué avant de constater l'erreur.

--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support

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


From: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>
To: Dimitri Fontaine <dimitri(at)2ndquadrant(dot)fr>
Cc: Cloc <ccastello(at)athmo(dot)eu>, PostgreSQL mailing lists <pgsql-fr-generale(at)postgresql(dot)org>
Subject: Re: pertinence pgbarman / cloud
Date: 2014-10-03 00:22:05
Message-ID: CAB7nPqReFnNwVs1RP+Q7vVV+_QtP2evkj=LsiRwDBEUm5FpUcA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-fr-generale

2014-10-02 22:31 GMT+09:00 Dimitri Fontaine <dimitri(at)2ndquadrant(dot)fr>:
>
> Cloc <ccastello(at)athmo(dot)eu> writes:
> > En cas de problème, étant donné que les fichiers WAL sont répliqués avec la
> > machine, le redémarrage avec un minimum de pertes devrait être réalisable,
> > non ?
>
> La réplication n'est *jamais* une solution adéquate aux problèmes que
> l'on résoud via une restauration de données : DROP TABLE en production
> est un exemple typique.
>
> L'ordre sera répliqué avant de constater l'erreur.

recovery_min_apply_delay de 9.4 permet d'appliquer un délai à la
réplication pour COMMIT et les points de restoration (terme français
correct?):
http://www.postgresql.org/docs/devel/static/standby-settings.html
--
Michael

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


From: Cloc <ccastello(at)athmo(dot)eu>
To: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, Dimitri Fontaine <dimitri(at)2ndquadrant(dot)fr>
Cc: PostgreSQL mailing lists <pgsql-fr-generale(at)postgresql(dot)org>
Subject: Re: pertinence pgbarman / cloud
Date: 2014-10-03 07:05:45
Message-ID: 542E4AC9.8000606@athmo.eu
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-fr-generale

Bonjour.

Merci à vous tous pour les précisions apportées.

Salutations.

Le 03/10/2014 02:22, Michael Paquier a écrit :
> 2014-10-02 22:31 GMT+09:00 Dimitri Fontaine <dimitri(at)2ndquadrant(dot)fr>:
>>
>> Cloc <ccastello(at)athmo(dot)eu> writes:
>>> En cas de problème, étant donné que les fichiers WAL sont répliqués avec la
>>> machine, le redémarrage avec un minimum de pertes devrait être réalisable,
>>> non ?
>>
>> La réplication n'est *jamais* une solution adéquate aux problèmes que
>> l'on résoud via une restauration de données : DROP TABLE en production
>> est un exemple typique.
>>
>> L'ordre sera répliqué avant de constater l'erreur.
>
>
> recovery_min_apply_delay de 9.4 permet d'appliquer un délai à la
> réplication pour COMMIT et les points de restoration (terme français
> correct?):
> http://www.postgresql.org/docs/devel/static/standby-settings.html
>

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


From: Sébastien Lardière <sebastien(at)2ndquadrant(dot)fr>
To: Cloc <ccastello(at)athmo(dot)eu>, pgsql-fr-generale(at)postgresql(dot)org
Subject: Re: pertinence pgbarman / cloud
Date: 2014-10-03 14:29:33
Message-ID: 542EB2CD.7080605@2ndquadrant.fr
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-fr-generale

On 02/10/2014 14:52, Cloc wrote:
> Bonjour.
>

Bonjour,

> Rebondissant sur la très récente discussion concernant les scripts de
> backup (et de récupération), je me posais la question de la pertinence
> d'une solution telle que pg_barman dans le cadre d'un serveur disposé
> sur une plateforme de cloud intégrant une réplication hors site.

Ici, je suppose que la réplication dont il est question est une
réplication des données de la VM, utilisant les outils de l'hyperviseur ?

Si c'est bien le cas, je préfère la réplication intégrée à PostgreSQL,
en ce qui concerne les données de PostgreSQL.

>
> En cas de problème, étant donné que les fichiers WAL sont répliqués avec
> la machine, le redémarrage avec un minimum de pertes devrait être
> réalisable, non ?

Dans tous les cas, attention, une réplication n'est pas une sauvegarde,
même avec les options pour retarder l'application de cette réplication.

La confusion est possible, car la réplication et la sauvegarde physique
s'appuient sur les mêmes "outils" internes à PostgreSQL, mais il
toujours préférable de mettre en place une sauvegarde physique *et* une
stratégie de réplication.

--
Sébastien Lardière 06 22 67 28 20
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support

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