On Saturday April 12 2003 9:54, Jim C. Nasby wrote:
> On Fri, Apr 11, 2003 at 07:32:15PM -0600, Ed L. wrote:
> > I appreciate your pointing that out. It is pretty undesirable for data
> > to appear on the slave in an order different from the one in which it
> > appears on the master. I guess that's another downside to batching.
> > I'm not sure this approach can do any better than approximating the
> > order since there is no knowledge of the commit order.
>
> I know this will probably require more work than you'd like, but it
> seems like it might be very useful/important for the replication queue
> to have definitive information about when commits occur.
Yes, just hard/impossible to get commit data. There is work in progress on
a log-based replication.
1
> BTW, I don't know how this would apply to pgsql, but both DB2 and Oracle
> handle replication via the transaction logs. AFAICT they don't keep
> seperate replication tables or anything; they just ship whole
> transaction logs off to the slaves (a bit of a simplification, but my
> point is that all the data the slaves get is in the form of the
> transaction logs that are normally kept by the master anyway).
Yes, sounds like such an approach might be more robust in some ways. Its
just not ready, and it may be a release or two before it shows up, last I
heard. Dbmirror, in my view, is reasonably close, free and open, and ready
to go until something better comes along.
Ed
