On Fri, 2006-07-28 at 11:01 -0700, Jeff Frost wrote: > Mario, > > There's also Command Prompt's Mammoth replicator: > http://commandprompt.com/products/mammothreplicator/ I sent an email asking if they have an evaluation version of some sort... > Also, you could batch up PITR restores or even just dump restores if the > timing was acceptable and you could afford the replicated DB to be down during > those batch updates. Dump restores are what we're using now, but we're soon going to have to abandon that approach. The dump/restore cycle takes around 20 minutes, and we're expecting rapid growth of the database. The another problem is that Tomcat won't release connections to postgres unless you stop it. PIRT restores are not working for me. I did it like this: I issued pg_start_backup, then I 'tar cvf - pg_data/ | nc destination 9876'-ed the cluster directory, when that was done i did pg_stop_backup, after that I deleted pg_xlog directory, and put new WAL files (created after backup begun) in directory specified in restore.conf. I started postgres, everything went ok. Postgres replayed wal files, and system was ready. Then, when new WAL files arrived, I shut down postgres, put WAL files in place, restarted postgres, but it complained, and didn't replay newly created wal files. It only does so when I 'recreate' original filesystem backup. > Another option is using pgpool's replication. I considered that too, but that adds another layer between the clients and postgres itself, and it allows for only two servers, and I realy don't need failover cluster capabilities. Mike
