Hi,
Replying to all the questions at once :
- The application was developped in PHP. It's mostly a B2B
application for exchanging digital content (video) over the internet.
Since we also provide some hosted scripts for the customer oriented
websites using our plateform, there are a lot of requests on the
database.
- Each connexion involves some read and write queries to the
database, though we may be able to separate the database in two. (Many
of the write queries are mostly used for accounting/statistics and
session tracking (there are already 5 http server machines in the farm,
so session is in database). If you exclude statistics and session
tracking, there are very few writes in the database.
- For slony, i installed it a few weeks ago to give it a try.
Installation was painful. I had to run the script many times to get it
and to modify the script every time, to avoid asking the script to do
the work twice. After installation was done, i had a heavy load average
on the slave machine. (Heavier than on the master).
Franck
On Fri, 2005-10-21 at 09:54 -0500, Scott Marlowe wrote:
> On Fri, 2005-10-21 at 11:01, Franck Coppola wrote:
> > Hi,
> >
> > We have a postgresql database which we would like to clusterize. By
> > clusterize, i mean be able to use multiple servers to read and write in
> > the database. Simple replication is not enough. (However if you have any
> > suggestion for replication which are fit for production environements, i
> > would be interested too : i don't feel very confident with slony).
> >
> > Are there any tools to do this ? (I would prefer opensource, but if
> > there is a well proven and affordable commercial app to do it, why
> > not).
>
> You are saying that you want multiple servers for read and write, but
> you're not saying why you want it. Since what you're trying to do
> dictates what tools you should use to do it, it might help us to answer
> your question if you tell us what parameters of your problem have led
> you to decide on this particular requirement. It may well be that there
> are the right tools to do this, but I can't really say, because I don't
> have enough info.
>
> So, what, exactly, are you going to be doing with this system in terms
> of transactional throughput, distributed input, things like that? What
> percentage of your database traffic is input versus output? Is this
> OLTP, or more OLAP? Would read only replicants of your db help your
> users? etc...
--
Franck Coppola <fcoppola@hexaglobe.com>
Hexaglobe