Excellent ! That solution solve my problem. We can deploy the Slony subscriber on the protected zone.

Thank-you for your feedbacks.

Regards,

Ludovic Toinel


> Le 10 nov. 2015 à 15:36, Steve Singer <ssinger at ca.afilias.info> a écrit :
> 
>> On 11/10/2015 08:49 AM, TOINEL, Ludovic wrote:
>> Is there a way to have subscribers with no direct SQL access to the provider ?
>> 
>> The provider write the data on the subscribers directly.
> 
> To repeat what Stephane said
> 
> The slon daemon doesn't need to run on the same server as the replica database.
> 
> You can put the slon dameons for both the replicas and the orign on the origin node (or some other node that can access all nodes).  That way the replica database server doesn't need to open network connections anywhere.
> 
> The slon for the replica (which you are running on the originr or somewhere similar) can connect to both the replica and origin database servers.
> 
> 
> 
> 
>> -----Message d'origine-----
>> De : slony1-general-bounces at lists.slony.info [mailto:slony1-general-bounces at lists.slony.info] De la part de Stéphane Schildknecht
>> Envoyé : mardi 10 novembre 2015 14:45
>> À : slony1-general at lists.slony.info
>> Objet : Re: [Slony1-general] Network connection from slaves to the master
>> 
>>> On 10/11/2015 14:03, TOINEL, Ludovic wrote:
>>> Thanks Andrew,
>>> 
>>> We are not allowed to have network connection from the slaves to the master (for security constraints).
>> 
>> You really should think about a VPN between nodes. It would simplify your architecture.
>> 
>> But, in theory, subscriber nodes could be on a DMZ. They can be accessed by daemons, but you don't need them to access providers.
>> Your daemons would run on a node that can access every other node.
>> 
>> 
>> BTW, there are no real master and slaves in Slony. There are nodes, which can be subscribers (receiving modifications readonly), and providers (read/write).
>> And you can have a subscriber of a set that is provider of another.
>> 
>>  Only master can communicate with slaves.
>>> We need database on slaves with mix replicates tables and read/write tables.
>>> 
>>> The solution could be maybe that solution using a slony master has an Hot standby of a master protected somewhere ?
>>> 
>>> [slony slaves] <-----> [slony master - Standby node] <----(log
>>> shipping)--|firewall|-- [master protected somewhere]
>>> 
>>> Do you think this solution can work with slony ?
>>> 
>>> Regards,
>>> 
>>> Ludovic Toinel
>>> 
>>> -----Message d'origine-----
>>> De : slony1-general-bounces at lists.slony.info
>>> [mailto:slony1-general-bounces at lists.slony.info] De la part de Andrew
>>> Sullivan Envoyé : mardi 10 novembre 2015 12:26 À :
>>> slony1-general at lists.slony.info Objet : Re: [Slony1-general] Network
>>> connection from slaves to the master
>>> 
>>>> On Tue, Nov 10, 2015 at 09:51:29AM +0000, TOINEL, Ludovic wrote:
>>>> The network allows only flows from master to slaves.
>>>> 
>>>> Is there any option that I missed to do that ?
>>> 
>>> Not really.  In principle you could do this with the log shipping mode, but I don't recall whether doing that on the master was not possible or just a really bad idea.  (You could do this with the built-in standby mechanisms of Postgres, though.
>>> 
>>> I do wonder why you have it set up this way, however.  Why do you control the flows this way?
>>> 
>>> A
>>> 
>>> --
>>> Andrew Sullivan
>>> ajs at crankycanuck.ca
>> 
>> 
>> --
>> Stéphane Schildknecht
>> Contact régional PostgreSQL pour l'Europe francophone Loxodata - Conseil, expertise et formations
>> 06.17.11.37.42
>> _______________________________________________
>> Slony1-general mailing list
>> Slony1-general at lists.slony.info
>> http://lists.slony.info/mailman/listinfo/slony1-general
>> _______________________________________________
>> Slony1-general mailing list
>> Slony1-general at lists.slony.info
>> http://lists.slony.info/mailman/listinfo/slony1-general
> 
This message contains information that may be privileged or confidential and is the property of the Capgemini Group. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message.