On Thu, 2005-01-20 at 15:36 +0100, Hervé Piedvache wrote:
> Le Jeudi 20 Janvier 2005 15:24, Christopher Kings-Lynne a écrit :
> > > Is there any solution with PostgreSQL matching these needs ... ?
> >
> > You want: http://www.slony.info/
> >
> > > Do we have to backport our development to MySQL for this kind of problem
> > > ? Is there any other solution than a Cluster for our problem ?
> >
> > Well, Slony does replication which is basically what you want :)
> >
> > Only master->slave though, so you will need to have all inserts go via
> > the master server, but selects can come off any server.
>
> Sorry but I don't agree with this ... Slony is a replication solution ... I
> don't need replication ... what will I do when my database will grow up to 50
> Gb ... I'll need more than 50 Gb of RAM on each server ???
> This solution is not very realistic for me ...
Slony has some other issues with databases > 200GB in size as well
(well, it hates long running transactions -- and pg_dump is a regular
long running transaction)
However, you don't need RAM one each server for this, you simply need
enough disk space.
Have a Master which takes writes, a "replicator" which you can consider
to be a hot-backup of the master, have N slaves replicate off of the
otherwise untouched "replicator" machine.
For your next trick, have the application send read requests for Clients
A-C to slave 1, D-F to slave 2, ...
You need enough memory to hold the index sections for clients A-C on
slave 1. The rest of the index can remain on disk. It's available should
it be required (D-F box crashed, so your application is now feeding
those read requests to the A-C machine)...
Go to more slaves and smaller segments as you require. Use the absolute
cheapest hardware you can find for the slaves that gives reasonable
performance. They don't need to be reliable, so RAID 0 on IDE drives is
perfectly acceptable.
PostgreSQL can do the replication portion quite nicely. You need to
implement the "cluster" part in the application side.
--
