Postgresql replication: londiste vs. slony
Has anyone had much experience using londiste? It is an alternative to slony for postgres replication. I have been beating my head against the wall trying to get slony to work the way I need it and was looking for any easier way.
londis开发者_Go百科te seems like a good alternative, but I wanted to see if anyone has any pros/cons before I commit to a switch.
I have used both and for my requirements Londiste is a good option.
We have a simple set up where a subset of tables is replicated from a staging server to live by large batch updates and insert and also intraday smaller updates running on postgres 8.4 and Centos 5.5 and skytools 2 and we also use it as the queue component for event based actions. Previously I have used Slony from the 1.* series so I can't comment on more recent versions.
Some Pros for Londiste
- Simple to set up
- Generally simple to administer
- Haven't had any issues with robustness of replication in 8 months of production use
- Also can be used as a generic queing system outside of replication and it is quite simple to write your own consumer
Some Cons
- Documentation is pretty scant
- You need to be careful when implementing ddl changes
- It won't stop you from making changes in the slave
- Can't be used for cascading replication or failover/switchover use case
I will limit my comment on Slony to my experience that it was complex to set up and administer and the version I used did not compare favourably on tolerance to network issues with Londiste but could have been used for cascading replication and switchover use cases.
As mentioned before, Londiste is simpler to use, indeed. And as of version 3, released in March 2012, Londiste supports cascading replication and failover/switchover, as well as a bunch of other new cool features.
精彩评论