Thread: changing the /tmp/ lock file?
I'm trying to impliment an automatic failover system, and am running into the problem that when I try to start multiple postgres clusters on the same box, postgres will not start if /tmp/.s.PGSQL.5432.lock exists. Can I change the file it's looking for via an option? Nothing seemed obvious from a quick review of the docs, short of (presumably) changing the port number, which I don't want to do.
Ben <bench@silentmedia.com> writes:
> I'm trying to impliment an automatic failover system, and am running into
> the problem that when I try to start multiple postgres clusters on the
> same box, postgres will not start if /tmp/.s.PGSQL.5432.lock exists. Can I
> change the file it's looking for via an option? Nothing seemed obvious
> from a quick review of the docs, short of (presumably) changing the port
> number, which I don't want to do.
That lock file exists specifically to keep you from doing that (ie,
having more than one postmaster listening on the same port). Trying
to defeat the lock is not a good idea.
regards, tom lane
On Wed, 13 Jun 2007, Ben wrote: > when I try to start multiple postgres clusters on the same box, postgres > will not start if /tmp/.s.PGSQL.5432.lock exists. There can only be one program listening on a specific port at a time. If you want multiple clusters on the same box, each of them has to be given their own port number. -- * Greg Smith gsmith@gregsmith.com http://www.gregsmith.com Baltimore, MD
Why would that be a problem if each is configured to listen on different addresses? 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. I fully expect things to go slower during failover periods, but in my case, that's better than doubling my hardware. On Wed, 13 Jun 2007, Tom Lane wrote: > Ben <bench@silentmedia.com> writes: >> I'm trying to impliment an automatic failover system, and am running into >> the problem that when I try to start multiple postgres clusters on the >> same box, postgres will not start if /tmp/.s.PGSQL.5432.lock exists. Can I >> change the file it's looking for via an option? Nothing seemed obvious >> from a quick review of the docs, short of (presumably) changing the port >> number, which I don't want to do. > > That lock file exists specifically to keep you from doing that (ie, > having more than one postmaster listening on the same port). Trying > to defeat the lock is not a good idea. > > regards, tom lane >
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
Ben <bench@silentmedia.com> writes:
> Why would that be a problem if each is configured to listen on different
> addresses?
Because if they're all on the same port number, they're all trying to
use the same Unix socket.
Now, if you are mostly interested in communicating with them over IP,
you could use unix_socket_directory to force their socket files into
different places. This'll be a PITA for local use of Unix socket
connections, but if that's what you want ...
regards, tom lane
On 6/13/07, Ben <bench@silentmedia.com> wrote:
> Why would that be a problem if each is configured to listen on different
> addresses?
>
> 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. I fully expect things to go
> slower during failover periods, but in my case, that's better than
> doubling my hardware.
Why not running them on different ports and proxy the incoming ports
via iptables or something like that based on the current situation on
your backends?
--
regards,
Robin
On Thu, 14 Jun 2007, Robin Ericsson wrote: > Why not running them on different ports and proxy the incoming ports > via iptables or something like that based on the current situation on > your backends? Because I figured it would be less hacky to have each postgres cluster listen on the address I want it to listen on, rather then listening on everything and then patching it up with iptables. But I see now that's not the case.
On Thu, Jun 14, 2007 at 09:53:42AM -0700, Ben wrote: > Because I figured it would be less hacky to have each postgres cluster > listen on the address I want it to listen on, rather then listening on > everything and then patching it up with iptables. But I see now that's not > the case. It is possible, you just have to realise that just like every postmaster has to listen on a different IP, they also all need to listen to a different socket directory. Have a nice day, -- Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/ > From each according to his ability. To each according to his ability to litigate.