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@xxxxxxxxxxxxx> Hexaglobe
Attachment:
signature.asc
Description: This is a digitally signed message part