You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Nov 18, 2017. It is now read-only.
I have setup a postgresql cluster (with one master node and one slave/standby node) using Governor. I want to use HA proxy in front of my cluster.
I think in this case HA proxy itself could be a single point of failure.
So to avoid this problem if I use multiple nodes for the HA proxy. Then not sure how client will handle the connection in case of failure of IP of HA proxy to which client is currently connected.
(Or we can say how client/client_app will switch over between different available IP's of HA proxy).
The text was updated successfully, but these errors were encountered:
I believe you would have a VIP on the primary HA proxy server, if the primary where to fail the VIP would be brought up on the second HA proxy server. That way the application only has to know about one IP/Hostname.
@doanerock Thanks for your reply. Sorry I was little caught up with something so not able to reply. As I am exposing PostgreSQL as a service to Cloud Foundry, I don't want to have access as a VIP. As, I guess, having a VIP will make the database publicly accessible. Isn't it? Is there any other way we can achieve this?
Just because you use a VIP does not make it publicly accessible. It is all in how you set it up, just like another IP. While a VIP can be transferred between machines as needed.
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
I have setup a postgresql cluster (with one master node and one slave/standby node) using Governor. I want to use HA proxy in front of my cluster.
I think in this case HA proxy itself could be a single point of failure.
So to avoid this problem if I use multiple nodes for the HA proxy. Then not sure how client will handle the connection in case of failure of IP of HA proxy to which client is currently connected.
(Or we can say how client/client_app will switch over between different available IP's of HA proxy).
The text was updated successfully, but these errors were encountered: