On Thu, 2005-05-05 at 14:16 -0400, Jeff - wrote:
One of the biggest things for Slony is that you can install slony, set things up and it will bring the slave(s) "up to speed". You don't need to do an initial data dump (I think you still need to load the schema on the slaves, but not the data). That is a BIG win for us folks who can't take a machine down while pg_dump runs (and while it is restored on hte slave)
Why would you need to take anything down to run pg_dump? And surely bringing a slave up to speed using Slony would be much slower than dump/restore?
You don't need to take Postgres down to use pg_dump - it works just fine.
The problem with replication (with DBmirror at least) is that you have to create a backup in a very specific order to make sure your new backup ends up in sync and transactions are neither replicated more than once, or not replicated at all:
1. Stop client access to the database (so you don't create any more transactions to replicate)
2. Stop the replication script when the dbmirror tables are empty
3. pd_dump the master
4. pg_restore the slave
5. Restart client apps and replication (doesn't matter which order)
If you don't do this then there is a chance of missing or more likely duplicating transactions which can obviously cause problems.
Having said that - it would be fairly straight-forward to write a recover script that avoided these problems by taking note of the transaction sequence IDs in the replication tables. If I get a chance I'll look into doing that - doesn't feel like a huge job!
Pete
---------------------------(end of broadcast)--------------------------- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to majordomo@xxxxxxxxxxxxxx so that your message can get through to the mailing list cleanly
