Turbo>All these have a different endpoint to access them. If the master dies,
AWS will promote one of the replicas as master automatically
Turbo>Meaning, the app can no longer access the DB!
Is application using some sort of a connection pool?
In case connection pool is used (e.g. HikariCP), the sequence would be:
1) pgjdbc is configured with a full set of connection URLs, targetServerType=master (default value is "any")
2) Application asks for a connection, HikariCP creates one, pgjdbc connects, picks a master host and stays with it forever
3) Failure happens. The connection gets broken in the background
4) Application asks a connection, HikariCP performs connection validation, it identifies the failure and recreates the connection
5) At this point pgjdbc reevaluates the list of current servers, identifies current master and connects to it.
pgjdbc caches the state of master/slave for 10 seconds by default (it is configured via hostRecheckSeconds)
This enables failover.
Of course the queries that were in-flight would fail, however the application should be able to continue.
The key point is to use a connection pool + connection validation.
Dave>The driver doesn't do load balancing
Typically you don't see much masters at the same time, however there can be multiple slaves.
In case targetServerType=slave or preferSlave, pgjdbc can load-balance across slaves in case loadBalanceHosts=true (it is false by default)
Vladimir
