Lists: | pgsql-fr-generale |
---|
From: | Emmanuel BEZAGU <emmanuel(dot)bezagu(at)dgfip(dot)finances(dot)gouv(dot)fr> |
---|---|
To: | pgsql-fr-generale(at)postgresql(dot)org |
Subject: | replication synchrone |
Date: | 2016-06-17 14:03:26 |
Message-ID: | 16114_1466172205_5764032D_16114_473_3_9c9da819-f7cf-1989-41bd-6e64ece9bdae@dgfip.finances.gouv.fr |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-fr-generale |
<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=utf-8">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<p>Bonjour,</p>
je fais quelques tests de replication synchrone et je cherche à
vérifier que le commit sur le maître fait bien en sorte que la
donnée soit disponible immédiatement en lecture sur l'esclave :<br>
1. insert et commit sur le serveur maître<br>
2. vérification de la donnée juste insérée sur l'esclave<br>
<br>
Les opération se font en OpenJDK 1.8.0-91 avec le driver jdbc
9.4.1208.<br>
<br>
Maître et esclave sont en version 9.5.3 sous CentOS 6.5<br>
<br>
J'ai positionné les paramétrages suivants.<br>
<i><br>
Maître :</i><br>
wal_level = hot_standby<br>
synchronous_commit = on<br>
archive_mode = on<br>
archive_command = 'scp %p
<a class="moz-txt-link-abbreviated" href="mailto:postgres(at)10(dot)156(dot)217(dot)201:/var/lib/pgsql/9.5/backups/%f">postgres(at)10(dot)156(dot)217(dot)201:/var/lib/pgsql/9.5/backups/%f</a>'<br>
synchronous_standby_names = 'cadawebcat'<br>
<i><br>
Esclave :</i><br>
wal_level = hot_standby<br>
synchronous_commit = on<br>
hot_standby = on<br>
<br>
<i>Dans le recovery.conf :</i><br>
restore_command = 'cp /var/lib/pgsql/9.5/backups/%f "%p"'<br>
standby_mode = on <br>
primary_conninfo = 'application_name=cadawebcat host=10.156.217.200
port=5432 user=replication password=replicationpass'<br>
<br>
Sur 10000 insertions/vérifications, j'ai environ 15 données que je
ne vois pas immédiatement sur l'esclave. La réplication ne semble
donc pas si synchrone que cela. Une idée ?<br>
<br>
Pour info complémentaire, j'ai passé les logs de l'esclave en debug
:<br>
< 2016-06-17 15:30:36.954 CEST >DEBUG:
StartTransactionCommand<br>
< 2016-06-17 15:30:36.954 CEST >DEBUG: lie <unnamed> à
<unnamed><br>
< 2016-06-17 15:30:36.954 CEST >DEBUG:
CommitTransactionCommand<br>
< 2016-06-17 15:30:36.963 CEST >DEBUG: sendtime 2016-06-17
15:30:03.152726+02 receipttime 2016-06-17 15:30:36.963286+02
replication apply delay 0 ms transfer latency 33810 ms<br>
< 2016-06-17 15:30:36.963 CEST >DEBUG: sending write
4/2C14F6F8 flush 4/2C14F680 apply 4/2C14F680<br>
< 2016-06-17 15:30:36.965 CEST >DEBUG: sending write
4/2C14F6F8 flush 4/2C14F6F8 apply 4/2C14F680<br>
< 2016-06-17 15:30:36.965 CEST >DEBUG: record known xact
157607 latestObservedXid 157606<br>
< 2016-06-17 15:30:36.965 CEST >CONTEXTE : xlog redo
Heap2/MULTI_INSERT: 1 tuples<br>
< 2016-06-17 15:30:36.965 CEST >DEBUG: record known xact
157607 latestObservedXid 157607<br>
< 2016-06-17 15:30:36.965 CEST >CONTEXTE : xlog redo
Transaction/COMMIT: 2016-06-17 15:30:03.147224+02<br>
< 2016-06-17 15:30:36.965 CEST >DEBUG: record known xact
157607 latestObservedXid 157607<br>
< 2016-06-17 15:30:36.965 CEST >CONTEXTE : xlog redo
Transaction/COMMIT: 2016-06-17 15:30:03.147224+02<br>
< 2016-06-17 15:30:36.965 CEST >DEBUG: remove
KnownAssignedXid 157607<br>
< 2016-06-17 15:30:36.965 CEST >CONTEXTE : xlog redo
Transaction/COMMIT: 2016-06-17 15:30:03.147224+02<br>
< 2016-06-17 15:30:36.966 CEST >DEBUG: analyse
<unnamed> : SELECT id FROM test WHERE
id='58be24ab-3490-11e6-48e6-8da21da751c4'<br>
< 2016-06-17 15:30:36.966 CEST >DEBUG:
StartTransactionCommand<br>
< 2016-06-17 15:30:36.966 CEST >DEBUG: lie <unnamed> à
<unnamed><br>
< 2016-06-17 15:30:36.966 CEST >DEBUG:
CommitTransactionCommand<br>
< 2016-06-17 15:30:37.185 CEST >DEBUG: sendtime 2016-06-17
15:30:03.374971+02 receipttime 2016-06-17 15:30:37.185528+02
replication apply delay 0 ms transfer latency 33810 ms<br>
< 2016-06-17 15:30:37.185 CEST >DEBUG: sending write
4/2C14F770 flush 4/2C14F6F8 apply 4/2C14F6F8<br>
< 2016-06-17 15:30:37.192 CEST >DEBUG: sending write
4/2C14F770 flush 4/2C14F770 apply 4/2C14F6F8<br>
< 2016-06-17 15:30:37.193 CEST >DEBUG: analyse
<unnamed> : SELECT id FROM test WHERE id='<b>58be24ac-3490-11e6-6b4d-8da21da751c4</b>'<br>
< 2016-06-17 15:30:37.193 CEST >DEBUG:
StartTransactionCommand<br>
< 2016-06-17 15:30:37.193 CEST >DEBUG: lie <unnamed> à
<unnamed><br>
< 2016-06-17 15:30:37.194 CEST >DEBUG:
CommitTransactionCommand<br>
< 2016-06-17 15:30:37.200 CEST >DEBUG: record known xact
157608 latestObservedXid 157607<br>
< 2016-06-17 15:30:37.200 CEST >CONTEXTE : xlog redo
Heap2/MULTI_INSERT: 1 tuples<br>
< 2016-06-17 15:30:37.200 CEST >DEBUG: record known xact
157608 latestObservedXid 157608<br>
< 2016-06-17 15:30:37.200 CEST >CONTEXTE : xlog redo
Transaction/COMMIT: 2016-06-17 15:30:03.361395+02<br>
< 2016-06-17 15:30:37.200 CEST >DEBUG: record known xact
157608 latestObservedXid 157608<br>
< 2016-06-17 15:30:37.200 CEST >CONTEXTE : xlog redo
Transaction/COMMIT: 2016-06-17 15:30:03.361395+02<br>
< 2016-06-17 15:30:37.200 CEST >DEBUG: remove
KnownAssignedXid 157608<br>
< 2016-06-17 15:30:37.200 CEST >CONTEXTE : xlog redo
Transaction/COMMIT: 2016-06-17 15:30:03.361395+02<br>
< 2016-06-17 15:30:37.206 CEST >DEBUG: sendtime 2016-06-17
15:30:03.395458+02 receipttime 2016-06-17 15:30:37.206025+02
replication apply delay 0 ms transfer latency 33810 ms<br>
< 2016-06-17 15:30:37.206 CEST >DEBUG: sending write
4/2C14F7E8 flush 4/2C14F770 apply 4/2C14F770<br>
< 2016-06-17 15:30:37.210 CEST >DEBUG: sending write
4/2C14F7E8 flush 4/2C14F7E8 apply 4/2C14F770<br>
< 2016-06-17 15:30:37.210 CEST >DEBUG: record known xact
157609 latestObservedXid 157608<br>
< 2016-06-17 15:30:37.210 CEST >CONTEXTE : xlog redo
Heap2/MULTI_INSERT: 1 tuples<br>
< 2016-06-17 15:30:37.210 CEST >DEBUG: record known xact
157609 latestObservedXid 157609<br>
< 2016-06-17 15:30:37.210 CEST >CONTEXTE : xlog redo
Transaction/COMMIT: 2016-06-17 15:30:03.387602+02<br>
< 2016-06-17 15:30:37.210 CEST >DEBUG: record known xact
157609 latestObservedXid 157609<br>
< 2016-06-17 15:30:37.210 CEST >CONTEXTE : xlog redo
Transaction/COMMIT: 2016-06-17 15:30:03.387602+02<br>
< 2016-06-17 15:30:37.210 CEST >DEBUG: remove
KnownAssignedXid 157609<br>
< 2016-06-17 15:30:37.210 CEST >CONTEXTE : xlog redo
Transaction/COMMIT: 2016-06-17 15:30:03.387602+02<br>
< 2016-06-17 15:30:37.211 CEST >DEBUG: analyse
<unnamed> : SELECT id FROM test WHERE
id='58be4ba0-3490-11e6-6b0d-8da21da751c4'<br>
<br>
La donnée 58be24ac-3490-11e6-6b4d-8da21da751c4 est une de celle que
je ne vois pas répliquée instantanément.<br>
<br>
Merci pour votre aide.<br>
<br>
<div class="moz-signature">
<table cellpadding="0" cellspacing="0" border="0">
<tbody>
<tr>
<td width="250" valign="top"> <font style="font-size: 8pt;"
color="#36a629" face="Arial, sans-serif" size="1">
<b>Adoptez l'éco-attitude.</b>
</font><br>
<font style="font-size: 7pt;" color="#36a629" face="Arial,
sans-serif" size="1">N'imprimez ce courriel que si c'est
vraiment nécessaire</font><br>
</td>
</tr>
</tbody>
</table>
</div>
</body>
</html>
Attachment | Content-Type | Size |
---|---|---|
unknown_filename | text/html | 7.7 KB |
From: | Vik Fearing <vik(at)2ndquadrant(dot)fr> |
---|---|
To: | Emmanuel BEZAGU <emmanuel(dot)bezagu(at)dgfip(dot)finances(dot)gouv(dot)fr>, pgsql-fr-generale(at)postgresql(dot)org |
Subject: | Re: replication synchrone |
Date: | 2016-06-17 14:22:07 |
Message-ID: | 5764078F.1040809@2ndquadrant.fr |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-fr-generale |
On 17/06/16 16:03, Emmanuel BEZAGU wrote:
> Sur 10000 insertions/vérifications, j'ai environ 15 données que je ne
> vois pas immédiatement sur l'esclave. La réplication ne semble donc pas
> si synchrone que cela. Une idée ?
Pour que la réplication synchrone réussisse, il faut just que le serveur
secondaire ait synchronisé le WAL sur disque, il n'est pas obligé
d'appliquer les changements contenus dedans.
Pour le comportement que vous voulez, il faut attendre la version 9.6 et
configurer synchronous_commit = 'remote_apply'
/docs/9.6/static/runtime-config-wal.html#GUC-SYNCHRONOUS-COMMIT
--
Vik Fearing +33 6 46 75 15 36
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
--
Envoi via la liste pgsql-fr-generale (pgsql-fr-generale(at)postgresql(dot)org)
From: | Emmanuel BEZAGU <emmanuel(dot)bezagu(at)dgfip(dot)finances(dot)gouv(dot)fr> |
---|---|
To: | Vik Fearing <vik(at)2ndquadrant(dot)fr>, pgsql-fr-generale(at)postgresql(dot)org |
Subject: | Re: replication synchrone |
Date: | 2016-06-17 14:37:34 |
Message-ID: | 15832_1466174253_57640B2D_15832_112_1_ef55e0f1-1074-a28a-ff5e-91f9fcb5b286@dgfip.finances.gouv.fr |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-fr-generale |
Effectivement, vu comme cela c'est nettement plus clair.
Merci beaucoup pour l'information
Bon weekend.
Le 17/06/2016 à 16:22, Vik Fearing a écrit :
> On 17/06/16 16:03, Emmanuel BEZAGU wrote:
>> Sur 10000 insertions/vérifications, j'ai environ 15 données que je ne
>> vois pas immédiatement sur l'esclave. La réplication ne semble donc pas
>> si synchrone que cela. Une idée ?
> Pour que la réplication synchrone réussisse, il faut just que le serveur
> secondaire ait synchronisé le WAL sur disque, il n'est pas obligé
> d'appliquer les changements contenus dedans.
>
> Pour le comportement que vous voulez, il faut attendre la version 9.6 et
> configurer synchronous_commit = 'remote_apply'
>
> /docs/9.6/static/runtime-config-wal.html#GUC-SYNCHRONOUS-COMMIT
--
Envoi via la liste pgsql-fr-generale (pgsql-fr-generale(at)postgresql(dot)org)
From: | Cédric Villemain <cedric(at)2ndQuadrant(dot)com> |
---|---|
To: | Emmanuel BEZAGU <emmanuel(dot)bezagu(at)dgfip(dot)finances(dot)gouv(dot)fr>, Vik Fearing <vik(at)2ndquadrant(dot)fr>, pgsql-fr-generale(at)postgresql(dot)org |
Subject: | Re: replication synchrone |
Date: | 2016-06-17 15:39:02 |
Message-ID: | 57641996.3080807@2ndQuadrant.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-fr-generale |
On 17/06/2016 16:37, Emmanuel BEZAGU wrote:
> Effectivement, vu comme cela c'est nettement plus clair.
A noter qu'il existe également des options de réplication synchrone
«logique» (basée sur pgLogical et les Logical Slots PostgreSQL) qui sont
parfois plus intéressantes, en fonction du besoin.
--
Cédric Villemain +33 (0)6 20 30 22 52
http://2ndQuadrant.fr/
PostgreSQL: Support 24x7 - Développement, Expertise et Formation
--
Envoi via la liste pgsql-fr-generale (pgsql-fr-generale(at)postgresql(dot)org)
From: | Emmanuel BEZAGU <emmanuel(dot)bezagu(at)dgfip(dot)finances(dot)gouv(dot)fr> |
---|---|
To: | Cédric Villemain <cedric(at)2ndQuadrant(dot)com>, Vik Fearing <vik(at)2ndquadrant(dot)fr>, pgsql-fr-generale(at)postgresql(dot)org |
Subject: | Re: replication synchrone |
Date: | 2016-06-21 08:05:40 |
Message-ID: | 29359_1466496343_5768F557_29359_449_1_23a13179-35d1-754c-283b-12fbdcf7f9eb@dgfip.finances.gouv.fr |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-fr-generale |
Je vais exploré cette piste, je n'y avais pas pensé.
Merci pour cette aide précieuse.
Le 17/06/2016 à 17:39, Cédric Villemain a écrit :
> On 17/06/2016 16:37, Emmanuel BEZAGU wrote:
>> Effectivement, vu comme cela c'est nettement plus clair.
> A noter qu'il existe également des options de réplication synchrone
> «logique» (basée sur pgLogical et les Logical Slots PostgreSQL) qui sont
> parfois plus intéressantes, en fonction du besoin.
>
--
Envoi via la liste pgsql-fr-generale (pgsql-fr-generale(at)postgresql(dot)org)
From: | Jehan-Guillaume de Rorthais <ioguix(at)free(dot)fr> |
---|---|
To: | Emmanuel BEZAGU <emmanuel(dot)bezagu(at)dgfip(dot)finances(dot)gouv(dot)fr> |
Cc: | Cédric Villemain <cedric(at)2ndQuadrant(dot)com>, Vik Fearing <vik(at)2ndquadrant(dot)fr>, pgsql-fr-generale(at)postgresql(dot)org |
Subject: | Re: replication synchrone |
Date: | 2016-06-21 12:03:55 |
Message-ID: | 20160621140355.30018a44@firost |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-fr-generale |
Le Tue, 21 Jun 2016 10:05:40 +0200,
Emmanuel BEZAGU <emmanuel(dot)bezagu(at)dgfip(dot)finances(dot)gouv(dot)fr> a écrit :
> Je vais exploré cette piste, je n'y avais pas pensé.
>
> Merci pour cette aide précieuse.
>
> Le 17/06/2016 à 17:39, Cédric Villemain a écrit :
> > On 17/06/2016 16:37, Emmanuel BEZAGU wrote:
> >> Effectivement, vu comme cela c'est nettement plus clair.
> > A noter qu'il existe également des options de réplication synchrone
> > «logique» (basée sur pgLogical et les Logical Slots PostgreSQL) qui sont
> > parfois plus intéressantes, en fonction du besoin.
Tu peux nous en dire plus sur cette piste Cédric ?
Quel est le status de pg_logical actuellement ? Comment l'installer et en
quelle version de PostgreSQL ? Comment est gérée une réplication synchrone avec
pg_logical ?
Et au pire, un lien qui me permettrait de répondre à ces questions par moi même
ne serait pas de refus.
++
--
Envoi via la liste pgsql-fr-generale (pgsql-fr-generale(at)postgresql(dot)org)
From: | Emmanuel BEZAGU <emmanuel(dot)bezagu(at)dgfip(dot)finances(dot)gouv(dot)fr> |
---|---|
To: | Jehan-Guillaume de Rorthais <ioguix(at)free(dot)fr> |
Cc: | Cédric Villemain <cedric(at)2ndQuadrant(dot)com>, Vik Fearing <vik(at)2ndquadrant(dot)fr>, pgsql-fr-generale(at)postgresql(dot)org |
Subject: | Re: replication synchrone |
Date: | 2016-06-21 12:42:18 |
Message-ID: | 31576_1466512941_5769362D_31576_105_1_7eb6ef0f-e2e4-077f-a97f-d760f40d493a@dgfip.finances.gouv.fr |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-fr-generale |
Nous sommes en train de monter un environnement de tests.
Nous sommes parti de ces pages :
- https://2ndquadrant.com/fr/resources/pglogical/
- https://2ndquadrant.com/fr/resources/pglogical/pglogical-docs/
Laissez-nous quelques jours et j'essaierai de synthétiser ce qu'il en
ressort. Nous partons sur une version 9.5 de PostgreSQL.
@+
Le 21/06/2016 à 14:03, Jehan-Guillaume de Rorthais a écrit :
> Le Tue, 21 Jun 2016 10:05:40 +0200,
> Emmanuel BEZAGU <emmanuel(dot)bezagu(at)dgfip(dot)finances(dot)gouv(dot)fr> a écrit :
>
>> Je vais exploré cette piste, je n'y avais pas pensé.
>>
>> Merci pour cette aide précieuse.
>>
>> Le 17/06/2016 à 17:39, Cédric Villemain a écrit :
>>> On 17/06/2016 16:37, Emmanuel BEZAGU wrote:
>>>> Effectivement, vu comme cela c'est nettement plus clair.
>>> A noter qu'il existe également des options de réplication synchrone
>>> «logique» (basée sur pgLogical et les Logical Slots PostgreSQL) qui sont
>>> parfois plus intéressantes, en fonction du besoin.
> Tu peux nous en dire plus sur cette piste Cédric ?
>
> Quel est le status de pg_logical actuellement ? Comment l'installer et en
> quelle version de PostgreSQL ? Comment est gérée une réplication synchrone avec
> pg_logical ?
>
> Et au pire, un lien qui me permettrait de répondre à ces questions par moi même
> ne serait pas de refus.
>
> ++
>
>
--
Envoi via la liste pgsql-fr-generale (pgsql-fr-generale(at)postgresql(dot)org)
From: | Cédric Villemain <cedric(at)2ndquadrant(dot)com> |
---|---|
To: | Jehan-Guillaume de Rorthais <ioguix(at)free(dot)fr>, Emmanuel BEZAGU <emmanuel(dot)bezagu(at)dgfip(dot)finances(dot)gouv(dot)fr> |
Cc: | Vik Fearing <vik(at)2ndquadrant(dot)fr>, pgsql-fr-generale(at)postgresql(dot)org |
Subject: | Re: replication synchrone |
Date: | 2016-06-21 14:04:46 |
Message-ID: | 5769497E.3000703@2ndQuadrant.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-fr-generale |
On 21/06/2016 14:03, Jehan-Guillaume de Rorthais wrote:
> Le Tue, 21 Jun 2016 10:05:40 +0200,
> Emmanuel BEZAGU <emmanuel(dot)bezagu(at)dgfip(dot)finances(dot)gouv(dot)fr> a écrit :
>
>> Je vais exploré cette piste, je n'y avais pas pensé.
>>
>> Merci pour cette aide précieuse.
>>
>> Le 17/06/2016 à 17:39, Cédric Villemain a écrit :
>>> On 17/06/2016 16:37, Emmanuel BEZAGU wrote:
>>>> Effectivement, vu comme cela c'est nettement plus clair.
>>> A noter qu'il existe également des options de réplication synchrone
>>> «logique» (basée sur pgLogical et les Logical Slots PostgreSQL) qui sont
>>> parfois plus intéressantes, en fonction du besoin.
>
> Tu peux nous en dire plus sur cette piste Cédric ?
En 9.4 nous avons ajouté :
/docs/9.4/static/logicaldecoding-synchronous.html
Cette interface permet aux clients de logical slot d'utiliser la
configuration synchronous_commit et donc de fournir du remote_apply
(depuis 9.4 donc).
Rien de spécifique à pgLogical la-dedans, si ce n'est que l'outil
utilise ce qui est offert par PostgreSQL.
A noter que cela ne fournit pas un Global Transaction Manager ausens
propre comme celui de postgresql-XL, ce qui est la seule solution pour
obtenir un cluster complètement consistent à tout moment.
Emmanuel, inutile de tester la visibilité totale de vos transactions de
manière synchrone, sans GTM vous trouverez toujours un cas limite. Je
vous suggère d'évaluer le seuil de synchronisation/visibilité dont vous
avez besoin, et vos besoins en performance. L'énorme avantage de
PostgreSQL dans ce contexte est d'offrir une granularité de gestion de
la réplication *par* transaction.
> Quel est le status de pg_logical actuellement ? Comment l'installer et en
> quelle version de PostgreSQL ? Comment est gérée une réplication synchrone avec
> pg_logical ?
Cf lien sur note site et la doc pglogical, dans l'ensemble rien de bien
compliqué à l'usage. C'est stable et utilisé en production.
> Et au pire, un lien qui me permettrait de répondre à ces questions par moi même
> ne serait pas de refus.
https://2ndquadrant.com/en/resources/pglogical/release-notes/
https://2ndquadrant.com/en/resources/pglogical/pglogical-installation-instructions/
--
Cédric Villemain +33 (0)6 20 30 22 52
http://2ndQuadrant.fr/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Envoi via la liste pgsql-fr-generale (pgsql-fr-generale(at)postgresql(dot)org)
From: | Jehan-Guillaume de Rorthais <ioguix(at)free(dot)fr> |
---|---|
To: | " Cédric Villemain" <cedric(at)2ndquadrant(dot)com> |
Cc: | Emmanuel BEZAGU <emmanuel(dot)bezagu(at)dgfip(dot)finances(dot)gouv(dot)fr>, Vik Fearing <vik(at)2ndquadrant(dot)fr>, pgsql-fr-generale(at)postgresql(dot)org |
Subject: | Re: replication synchrone |
Date: | 2016-06-21 15:24:23 |
Message-ID: | 20160621172423.71e81385@firost |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-fr-generale |
Le Tue, 21 Jun 2016 16:04:46 +0200,
"Cédric Villemain" <cedric(at)2ndquadrant(dot)com> a écrit :
> On 21/06/2016 14:03, Jehan-Guillaume de Rorthais wrote:
> > Le Tue, 21 Jun 2016 10:05:40 +0200,
> > Emmanuel BEZAGU <emmanuel(dot)bezagu(at)dgfip(dot)finances(dot)gouv(dot)fr> a écrit :
> >
> >> Je vais exploré cette piste, je n'y avais pas pensé.
> >>
> >> Merci pour cette aide précieuse.
> >>
> >> Le 17/06/2016 à 17:39, Cédric Villemain a écrit :
> >>> On 17/06/2016 16:37, Emmanuel BEZAGU wrote:
> >>>> Effectivement, vu comme cela c'est nettement plus clair.
> >>> A noter qu'il existe également des options de réplication synchrone
> >>> «logique» (basée sur pgLogical et les Logical Slots PostgreSQL) qui sont
> >>> parfois plus intéressantes, en fonction du besoin.
> >
> > Tu peux nous en dire plus sur cette piste Cédric ?
>
> En 9.4 nous avons ajouté :
> /docs/9.4/static/logicaldecoding-synchronous.html
>
> Cette interface permet aux clients de logical slot d'utiliser la
> configuration synchronous_commit et donc de fournir du remote_apply
> (depuis 9.4 donc).
> Rien de spécifique à pgLogical la-dedans, si ce n'est que l'outil
> utilise ce qui est offert par PostgreSQL.
>
> A noter que cela ne fournit pas un Global Transaction Manager ausens
> propre comme celui de postgresql-XL, ce qui est la seule solution pour
> obtenir un cluster complètement consistent à tout moment.
> Emmanuel, inutile de tester la visibilité totale de vos transactions de
> manière synchrone, sans GTM vous trouverez toujours un cas limite. Je
> vous suggère d'évaluer le seuil de synchronisation/visibilité dont vous
> avez besoin, et vos besoins en performance. L'énorme avantage de
> PostgreSQL dans ce contexte est d'offrir une granularité de gestion de
> la réplication *par* transaction.
>
> > Quel est le status de pg_logical actuellement ? Comment l'installer et en
> > quelle version de PostgreSQL ? Comment est gérée une réplication synchrone
> > avec pg_logical ?
>
> Cf lien sur note site et la doc pglogical, dans l'ensemble rien de bien
> compliqué à l'usage. C'est stable et utilisé en production.
>
> > Et au pire, un lien qui me permettrait de répondre à ces questions par moi
> > même ne serait pas de refus.
>
> https://2ndquadrant.com/en/resources/pglogical/release-notes/
>
> https://2ndquadrant.com/en/resources/pglogical/pglogical-installation-instructions/
Merci Cédric, ça me permet d'avoir au moins un petit verni sur ce projet.
Je m'y collerais plus sérieusement le moment venu.
++
--
Envoi via la liste pgsql-fr-generale (pgsql-fr-generale(at)postgresql(dot)org)