0

I'm currently planning a more fault tolerant setup for my organizations Mail setup. We currently have two machines available in different datacenters, that we're planning to use for this, one being a physical host, the other being an lxc "VM".

The plan is to make the Physical host our primary Mailserver (lets call it server1) and the VM (lets call that server2) the secondary via DNS, so that when server1 goes down, server2 could take over until we've got the other one up and running again.

As with lxc I can't do fancy stuff like using DRBD or even GlusterFS due to permission issues, my choices for replicating data are rather limited.

As I personally like dbmail I've thought about using that with Postgres behind it to take care of storage. So basically I'm thinking of having dbmail with its own postgres running on server1, as well as another dbmail and another postgres on server2.

The question is: What options are there to keep those two postgres servers in sync without fancy stuff like drbd or a distributed filesystem, so that, when server1 goes down, server2 just continues where server1 stopped.

juwi
  • 573
  • 1
  • 5
  • 14

2 Answers2

1

The built-in replication in the database, either via the 9.0 and later Streaming Replication feature or the older Log-Shipping approach, are aimed at this sort of problem. Keeping two filesystem level snapshots of a database in sync is a hard problem anyway. Get replication working, and if your master fails you'll have to manually trigger the standby server and then change the DNS address to point to it. The clients talking to the database will need to be kicked so they reconnect too; TCP/IP timeouts can be pretty long sometimes. Getting the details perfect on all this takes work, but no high availability solution is every simple. Hardware can fail in a lot of strange ways.

You can expect some data might be lost on a crash--committed on the master, then it goes down before replicating it. In PostgreSQL 9.1 it might seem you can make that possibility go away with synchronous replication. But that really won't do what you want either; no commits will happen unless at least two servers are working once you've turned that on.

This all presumes that all of the interesting state information is inside the database, that there's none of it local to each dbmail. Presumably you know that's not a problem here.

Greg Smith
  • 969
  • 5
  • 7
0

Having different setups on primary and secondary servers of a fault tolerant system is almost always a bad idea.

I can see an option where you'd be running PostgreSQL replication and standard Linux clustering software (heartbeat, etc) to switch over roles. You'd have to manage the IP address as well, and not put the secondary into your mail DNS.

ch2500
  • 806
  • 6
  • 9
  • I suppose, by managing IP Adresses you mean CARP. This is basically not an option, which is why I wanted to maneuver around that. – juwi Feb 17 '12 at 16:58