On Thu, May 29, 2008 at 3:05 PM, Robert Hodges
<robert.hodges@continuent.com> wrote:
> Third, you can't stop with just this feature. (This is the BUT part of the
> post.) The use cases not covered by this feature area actually pretty
> large. Here are a few that concern me:
>
> 1.) Partial replication.
> 2.) WAN replication.
> 3.) Bi-directional replication. (Yes, this is evil but there are problems
> where it is indispensable.)
> 4.) Upgrade support. Aside from database upgrade (how would this ever
> really work between versions?), it would not support zero-downtime app
> upgrades, which depend on bi-directional replication tricks.
> 5.) Heterogeneous replication.
> 6.) Finally, performance scaling using scale-out over large numbers of
> replicas. I think it's possible to get tunnel vision on this—it's not a big
> requirement in the PG community because people don't use PG in the first
> place when they want to do this. They use MySQL, which has very good
> replication for performance scaling, though it's rather weak for
> availability.
These type of things are what Slony is for. Slony is trigger based.
This makes it more complex than log shipping style replication, but
provides lots of functionality.
wal shipping based replication is maybe the fastest possible
solution...you are already paying the overhead so it comes virtually
for free from the point of view of the master.
mysql replication is imo nearly worthless from backup standpoint.
merlin
