On 08/20/2014 02:55 PM, Petr Spacek wrote:
On 20.8.2014 10:58, Dmitri Pal wrote:
On 08/19/2014 07:55 PM, Joshua J. Kugler wrote:
A replica must connect to the master for initial setup; after that,
the master
pushes to the replica.
j
On Tuesday, August 19, 2014 09:26:11 Ludwig Krispenz wrote
On 20.8.2014 10:58, Dmitri Pal wrote:
On 08/19/2014 07:55 PM, Joshua J. Kugler wrote:
A replica must connect to the master for initial setup; after that, the master
pushes to the replica.
j
On Tuesday, August 19, 2014 09:26:11 Ludwig Krispenz wrote:
What's wrong with your scenario B: master(s
On 08/19/2014 07:55 PM, Joshua J. Kugler wrote:
A replica must connect to the master for initial setup; after that, the master
pushes to the replica.
j
On Tuesday, August 19, 2014 09:26:11 Ludwig Krispenz wrote:
What's wrong with your scenario B: master(s) in internal network, they
can contact
A replica must connect to the master for initial setup; after that, the master
pushes to the replica.
j
On Tuesday, August 19, 2014 09:26:11 Ludwig Krispenz wrote:
> What's wrong with your scenario B: master(s) in internal network, they
> can contact consumers in DMZ and remote rack and replicat
What's wrong with your scenario B: master(s) in internal network, they
can contact consumers in DMZ and remote rack and replicate to them.
What do you mean by "to contact for setup" ?
Ludwig
On 08/19/2014 03:12 AM, Joshua J. Kugler wrote:
So, we have a need for replication, but the existing pu
So, we have a need for replication, but the existing push-only methodology
doesn't work for us. I suppose our problems could be attributed to over-
zealous network rules, but it is what it is. :) I'd love to change our network
policy, but we aren't in charge of network policy, and there is no way
