|
I want to setup replication system on postgresql like #1 MASTER SERVER and two replicated servers: #2 SERVER in realtime (for load balancing), #3 SERVER delayed with some time offset (for example 2 days) to prevent application and human mistakes on data update/delete Someone got some experience with that kind of setup? What are real life disadvantages and problems with that solution? |
|||
|
|
|
If you are considering PostgreSQL 9.0 with Hot Standby, set up the archive so that the archive files only become available to the slave after a certain time. For example, you could have a little shell script that hardlinks the files from an incoming archive directory to an outgoing one based on file timestamps. Make sure you preserve the order. (Naturally, don't activate streaming replication if you do this.) |
|||
|
|
|
I haven't looked into the built-in replication in Postgres 9, but if you're using Slony-I with log shipping, you can just wait to apply the logs files 'til after they're a given age. We use a perl script under cron that connects to the master server and pulls the log files, then applies them. It should be nothing to pull stuff to the replica to queue, and then go through and apply them, stopping when you hit the ones that are too new. |
|||
|
|
