It is close, but has limitations that will be problematic for our environment, such as:
Replicator will not replicate the schema. You must restore your schema to th e slaves from the master before you begin replication. Replicator can only replicate one database. If you have multiple databases y ou can either initialize clusters for each database or move all databases into a si ngle database using schemas/namespaces. It is possible to add and drop columns to replicated tables within Replicato r. This type of change to your table structure will require a full sync and therefore is best done in batch or after hours. Thanks for the reply, Keaton On 3/25/08 2:18 PM, "Richard Broersma" <[EMAIL PROTECTED]> wrote: > On Tue, Mar 25, 2008 at 1:11 PM, Keaton Adams <[EMAIL PROTECTED]> wrote: >> Our organization is looking for a hot-standby option for PostgreSQL that >> uses the WAL (transaction) data to keep the standby current and also allows >> the standby to be read-only accessible for reporting. We have implemented >> WAL shipping through a set of scripts we developed and that works well to >> have a standby DB on the ready in case we need to fail over, but we are >> looking to increase the value of the standby server by making it available >> for queries. Because of the complexities of our environment using a >> table/trigger based replication method such as Slony won't work well. >> >> It would be great if there was a solution (Open Source or Commercial) that >> worked in a similar manner as Oracle Active Data Guard: >> >> Does anyone know of such a solution for PostgreSQL? > > I think this does what you want. > > http://commandprompt.com/products/mammothreplicator/
