On Monday April 14 2003 12:20, Andrew Sullivan wrote:
> On Fri, Apr 11, 2003 at 06:34:53PM -0400, Jan Wieck wrote:
> > A) You apply those changes in the order you read them out of the master
> > on the slave. This requires that you do it all in one big transaction
> > on
> >
> > B) You read all the changes across all tables, but regroup them into
> > their correct order and original transaction boundaries for playback on
> >
> > B2) You read all the changes across all tables simultaneously via
> > cursors. Worst case you need as many cursors as you have tables and
> > it's
>
> What I am confused about is why one needs to apply now-superseded
> transactions on the slave at all. Don't you just want a
> (serializable, mind) snapshot of the master to be applied to the
> slave?
I'd say, yes, if the process of creating such a snapshot is not overly
intensive or lengthy. IMO, this is one potentially significant drawback of
the dbmirror approach in general. The upside to dbmirror is that its
pretty straight-forward, works pretty well for certain situations, it's
open source, and it's free.
I know rserv/erServer are reported to use the snapshot approach. But rserv
didn't work at all for me without mods and looks very much like an
abandoned prototype for eRServer. ERServer, its successor, is done in part
by Vadim M. who if I'm not mistaken did an excellent job with MVCC. But,
at least as of Feb 28, 2003, eRServer was $10,000 minimum, closed source,
doesn't replicate DDL either, doesn't release trial versions, and has no
plans to support Redhat 8.0. For us, that was more than enough incentive
to investigate the alternatives.
I think that'd be a great improvement for dbmirror, along with DDL
replication.
Opinions on a better *currently available* option?
Ed