On Sunday April 13 2003 9:48, Steven Singer wrote:
> >
> > nothing wrong with that necessarily, unless you wanted to update the
> > master bookkeeping on every new xid as well, in which case it would
> > defeat my purpose in the master batch.
>
> Why do you need to update the master after every commit on the slave? If
> your storing the last seqid sent to the slave on that slave(you would
> have to update this during every transaction on the slave but I don't see
> this as a big deal) and you use that value as the authoratative value for
> deciding what next to send to the slave.
Agreed, I don't think you need to update the master after every commit on
the slave. On the contrary, I was simply making the observation that it
would not be useful to do so with respect to performance and traffic.
> You would have to periodically update the master to tell it that a
> tranaction can be removed form the replication_queue but this can be done
> periodically(every x transactions). If dbmirror goes down in between a
> commit on the slave and the master being updated then the transactions
> will stay on the master in the queue until dbmirror comes back up at
> which point it will see from the slave that the transactions have been
> sent and they don't need to be resent. Then the master can be updated so
> those rows can be cleaned from the queue.
Agreed, exactly.
Ed
