Postgresql replication: londiste vs. slony -
has had experience using londiste? alternative slony postgres replication. have been beating head against wall trying slony work way need , looking easier way.
londiste seems alternative, wanted see if has pros/cons before commit switch.
i have used both , requirements londiste option.
have simple set subset of tables replicated staging server live large batch updates , insert , intraday smaller updates running on postgres 8.4 , centos 5.5 , skytools 2 , use queue component event based actions. have used slony 1.* series can't comment on more recent versions.
some pros londiste
- simple set up
- generally simple administer
- haven't had issues robustness of replication in 8 months of production use
- also can used generic queing system outside of replication , quite simple write own consumer
some cons
- documentation pretty scant
- you need careful when implementing ddl changes
- it won't stop making changes in slave
- can't used cascading replication or failover/switchover use case
i limit comment on slony experience complex set , administer , version used did not compare favourably on tolerance network issues londiste have been used cascading replication , switchover use cases.
Comments
Post a Comment