On 17 June 2014 20:37, John Meinel <[email protected]> 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 <[email protected]> -- Juju mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
