The problem with general approaches is they are just that - general. That may or may not relate to you at all. So the most important thing is to understand or be prepared to learn as much as you can about the underlying system and software - in your case Postgres and some flavor of *nix.
I, like Siva, have tested replication on SQL Server using transactional replication.
The first thing I did was try to understand what the best model was for our needs. The first "bug" I found was my developer had chosen the wrong replication model.
- Setup the replication method several times. Remove it several times.
- Use a realitic amount of data. Then use a large / unrealistic amount of data - say 5 years worth. See any problems?
- Performance can degrade on both the Primary and Replicated DBs so make sure you can setup something similiar to production and see how it works.
- Make sure you can restore from your transactional db in a way that is acceptable. How much data, if any, can you loose?
- What happens when there are communication problems (read network problems) between the two?
I learned a lot of important information from testing replication like:
- Our current DB recovery mode was completely useless with replication. The transaction log would grow and fill the 500GB HD in a few days.
- Several of our DB queries became deadlocked or too slow when the replication process would run and our software was actively being used.
- As I said above we started out with the wrong replication method.
There are so many variables when you start thinking about it. The more you know the better. I suggest finding as much documentation on Postgres replication as you can.