Обсуждение: Clustering for performance and fail over

Hi, Stan,

We're in the early stages of testing a new Postgres (7.3) cluster.  For
background, our database is about 14gb on disk, and we see about a
transaction a second (out of about 120 queries/sec.)  Our application
is a large dynamic Apache-based web system, written in Perl.  Our main
database machine is a quad P4 Xeon (1.8ghz) with 4gb of RAM, running
Linux 2.4.mumble; poorly formed queries and bad disk layout (we're
working on it) mean that during times of peak traffic we'd see load
sometimes up over 15.

For fail-over, we've been running the contrib/dbmirror single-master
replication for about six months (in production) with no ill effects.
We do reporting and db backup off of the slave machine, and it works
great.  However, we project steady, linear growth in usage, and thus
needed to find extra performance -- and it's not easy to get a higher
performing shared-memory multiprocessor, to say nothing of cost.

As our system is pure Perl, we decided to replace the standard Perl
database access layer with a custom, multiplexing, handle cache.  It's
been running for about a week now and distributing the load flawlessly.
  A bonus is that proxying the queries has allowed us to being to
collect more interesting timing and usage statistics, and we're finally
starting to hunt down and mercilessly improve our nastiest queries.

There are some refinements to the dbmirror that we're currently working
on, but for now, everything is working flawlessly.

'jfb

C++: an octopus made by nailing extra legs onto a dog.

On Wed, Oct 22, 2003 at 10:30:24AM -0400, Stan Leung wrote:
> I am interested in know if anyone has set up clustering for performance and fail over using PostgreSQL.  We are
currentlyusing Oracle for a distribution application and would like to use PostgreSQL with multiple application and
databaseservers.   

Yes, we've done failover stuff using a shared storage, heartbeat, etc.
several times. For performance I prefer to divide the data to different
failover clustered database systems because concurrent writing creates
some huge technical overhead in many cases.

Michael
--
Michael Meskes
Email: Michael at Fam-Meskes dot De
ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: meskes@jabber.org
Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL!