On Wed, 13 Jun 2007, Ben wrote:
> Why would that be a problem if each is configured to listen on different
> addresses?
I'm not sure if you can even get bind() to work like that portably, but
ultimately it doesn't matter anyway. The benefit of how the current lock
scheme keeps people from screwing up and running the server twice
outweighs the value of satisfying the odd case you're asking for here even
if it were technically possible to do.
> But maybe a better question to ask would be how people are doing
> failover in the case where you have two servers, each handling a
> seperate set of data and acting as backup for each other.
A sample might be:
Server 1: Primary for DB#1 on 5432, secondary for DB#2 on 5433
Server 2: Primary for DB#2 on 5433, secondary for DB#1 on 5432
Then you would always know to reach DB#1 on port 5432 and DB#2 on port
5433, regardless of which IP address was active. Once you've got that in
place, have incoming connects go to two virtual IP address that normally
map to the two servers, but which collapses to the same underlying address
in the case of a failure. Then you can use any number of IP-based
failover schemes to implement that.
If you wanted to only expose port 5432 as being the public one, but with
two addresses, you might remap the port via the capabilities of the
virtual interface. In that case, you could actually keep both servers
running their primary on 5432, but then you'd be stuck with issues like
making sure the port number was changed every time you moved the entire
primary config to the secondary. It's just a easier to manage in several
aspects if you fix the port numbers per cluster, rather than always have
5432 be the active one and the IP address determining which cluster you
get to.
You'd need to give some more OS and general network setup information to
get any more specific or clever than that.
--
* Greg Smith gsmith@gregsmith.com http://www.gregsmith.com Baltimore, MD
