Re: Advice on running two database clusters on one server machine

On Sun, Jun 15, 2008 at 11:11 AM, Andreas Philipp
<andreas(dot)philipp(at)clinicauniversitariateleton(dot)edu(dot)co> wrote:
> Hi all,
>
> We are implementing a hospital information system and a human
> resources/payroll processing system on two identical dedicated servers with
> two Xeon Quad Core processors and 32 GB RAM each, both servers being attached
> via FC to a SAN, and both applications running on PostgreSQL 8.3 / CentOS 51.
>
> We are wondering about the advisability to distribute the databases between
> the two server machines, both machines acting as active production systems
> for one application each, and as warm standby servers for the other, using
> WAL shipping to a second database cluster running on another port on each of
> the two server machines.
>
> What would be the performance cost of doing so, rather than running all
> databases on one database cluster on one machine, and using the second
> machine as a warm standby server for all databases of the two applications?

Well, when both machines are working, your performance would be better
on two machines than on one. But after a failover, the warm standby
will be running two instances of postgresql, and that's sub-optimal.

> What other considerations should we take into account? We have no prior
> experience with PostgeSQL administration, having run our previous systems on
> Windows Servers and MS SQL Server.

Also, worry about the possibility of switching the wrong databases
when things are going wrong, etc with this type of setup.

However, the biggest concern is your FC-SAN setup. Some are very
fast. Some are quite pokey, and once you buy them, the manufacturer
will just laugh and point their fingers at linux, postgresql, or the
phase of the moon as the cause of your performance problem and do
nothing more.

If you haven't tested your FC-SAN setup with both servers running
comlex benchmarks (multiple bonnie++ instances, lots of dds, etc...)
and proven that it's fast, don't expect it to be.