On Saturday April 12 2003 2:06, Steven Singer wrote:
>
> How you query things on the master and when you commit things on the
> slave aren't all that related. As far as I can tell your batch version
> of the query using the temporary table will give you the same ordering of
> the updates as the current dbmirror implementation. As your reading
> the result of the second query(that gives data to make the SQL statements
> to send to the slave) you can decide when to do a comit on teh slave.
> Reading the discussion it sounds like your talking about sending this
> batch of 1000 transactions to teh slave in 1 transaction. Why not issue
> a commit on the slave everytime the xid changes? From the slaves point
> of view the behaviour is the smae as in teh current dbmirror(the original
> transactions are preserved with an approximation of the ordering based on
> the last update/insert in each transaction)
Agreed. I can take little/no credit for originality. Just tried to batch
your algorithm.
> I still don't see why you would want to only do 1 commit per group on the
> slave though.
No, no, I don't have that in mind. Seems I've miscommunicated that idea a
bit. What I would like is to commit on the slave whenever I feel like it,
in batches or 1 or 10 or 100 or 203 transactions, and to retrieve
transactions from the master in whatever batchsize I wish as well.
Committing after every new xid on the slave is one among many options,
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.
Ed
