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.
John
=:->
