John Allgood wrote:
Here is a summary about the cluster suite from redhat. All 9 databases will be on the primary server the secondary server I have is the failover. They don't actually share the partitions at the same time. When you have some type of failure the backup server takes over. Once you setup the hardware and install the clustering software. You then setup a service "ie postgres" and then you tell it what harddrive you will be using. /dev/sde1 and the clustering software takes care of starting and stopping the postgres database.
Okay, I misunderstood your hardware. So you actually only have 1 machine, with a second machine as a potential rollover. But all transactions occur on the same hardware, even if is a separate "database". I was thinking these were alternate machines.
So my first question is why are you partitioning into a separate database, and then updating the master one at night. Since everything is restricted to the same machine, why not just have everything performed on the master?
However, sticking with your arrangement, it would seem that you might be able to get some extra performance if each database is on it's own raid, since you are fairly likely to have 2 transactions occuring at the same time, that don't affect eachother (since you wouldn't have any foreign keys, etc on 2 separate databases.)
But I think the basic OS RAID1, pg_xlog RAID10, database RAID10 is still a good separation of disks. And probably would help you maximize your throughput.
I can't say too much about how the Cluster failover stuff will work with postgres. But as long as one is completely shutdown before the next is started, and they are both running binary compatible versions of postgres, it seems like it would be fine. Not much different from having a second machine that is sitting turned off, which you turn on when the first one fails.
Description: OpenPGP digital signature