proxies and multiplexing

[Stuart Bishop]

On 17 June 2014 20:37, John Meinel <john at arbash-meinel.com> wrote:

> I don't know quite how that would work with postgres masters vs postgres
> slaves, but it does mean that postgres charm is involved in its own proxying
> (it knows when it is being proxied, and changes its behavior accordingly).
>
> I haven't quite worked through how all that interacts with your proposal
> that not all units of postgresql are equal. Nor how it interacts with the
> Azure model of only giving out one IP address for all the units of postgres.

This model looks very promising, thanks. It had not occurred to me
that the data doesn't have to flow slavishly along the relation path.
It solves the master/slave unit issue elegantly by not solving it at
all - each client unit still has a relation to each PostgreSQL unit
and can select which PostgreSQL unit to use based on its role, rather
than trying to stuff a new service in the middle and multiplex
everything through it.

The Azure model of shared IP addresses might actually make things
easier too. If I have 3 units in my proxy service, then they all share
a single IP address and connections get distributed evenly. With other
providers, the PostgreSQL charm is going to have to allocate the IP
addresses of the proxies as evenly as it can over the clients. But in
my case I think Azure will end up the same as any other provider, as
with databases we are dealing with private IP addresses rather than
exposing them with public IP addresses.


-- 
Stuart Bishop <stuart.bishop at canonical.com>