> 4. I'd like to have our updates go to the master and selects go to > the clients. Is that possible? You can use pgpool to achieve this (http://pgpool.projects.postgresql.org/ ).
On Tuesday 30 May 2006 21:13, Brendan Duddridge <brendan@clickspace.com> wrote: > Hi, > > I apologize if this is the wrong list to post these questions. >
There is a Slony list, but I'm sure there's some overlap
> 1. Does Slony replicate table statistics to the slaves?
No.
> 2. Do you still have to vacuum analyze the slaves?
Yes. All a subscriber basically is, is an otherwise normal PostgreSQL database that a Slony process happens to write data into.
> 3. Are selects replicated or just inserts, updates, and deletes?
Replication actions are scheduled on a row-level basis, via trigger, for each row inserted, updated, or deleted. Those actions are executed in an intelligent manner on the subscribers. Additional events, such as DDL modification scripts, can also be scheduled.
However, to answer the question, just inserts, updates, and deletes.
> 4. I'd like to have our updates go to the master and selects go to > the clients. Is that possible?
Yep ... while keeping in mind that it is an asynchronous replication system, and the subscribers will not generally be in perfect sync with the master. You will need separate database connections since the setup doesn't appear as a single cluster or anything like that.
> 5. What happens if an update tries to go to the slave? Does it > automatically get routed to the master?
Tables on the subscribers are modified to prevent write ops. The subscriber table otherwise has no knowledge of the master. Operations are therefore not re-routable.
I would strongly suggest setting up a test replication setup to learn exactly how Slony works before deciding on a particular architecture.
-- "When a politician says he wants you to serve a cause greater than your own self-interest, the cause he has is mind is his own reelection."
---------------------------(end of broadcast)--------------------------- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to majordomo@postgresql.org so that your message can get through to the mailing list cleanly
