← Back to team overview

maria-developers team mailing list archive

Re: Ideas for improving MariaDB/MySQL replication

 

MARK CALLAGHAN <mdcallag@xxxxxxxxx> writes:

> As a further optimization, I want a callback that is called after the
> binlog entries are written for a transaction and before the wait for
> group commit on the fsync is done. That callback will be used to
> release row locks (optionally) held by the transaction.

I was thinking about this idea of releasing row locks early. Specifically
about two scenarios: 1) releasing row locks early before having fully decided
whether to commit or roll back a transaction; 2) releasing row locks early
before changes in the transaction are made visible to other transactions.

For issue 1: Transaction A releases row locks at end of
innodb_xa_prepare(). Transaction B starts modifying rows touched by
transaction A (eg. UPDATE t SET a=a+1). Transaction A then needs to rollback
due to eg. failure during binlog write/fsync. Will transaction B now end up
with the wrong value for a?

For issue 2: Transaction A inserts a row and releases locks early before
making the row visible to other transactions. Transaction B inserts the same
row. Will we get a duplicate key in the database (corruption) due to
uniqueness check in transaction B not seeing the row from A? Or will we get a
bogus uniqueness violation in transaction B if A rolls back?

Have you already found an answer for issues such as these?

One way to avoid these kind of issues seems to me to be

A. Do not release row locks until changes made by the transaction have been
   made visible.

B. Do not make changes visible until we are fully decided to commit the
   transaction.

So basically, what I am asking is if you are doing A+B, or if you found a way
to release row locks even earlier. Or put another way, exactly how early are
you able to release row locks?

---

What I currently have is two callbacks for the engine:

 - One that is called after engine prepare() fsync, and before binlog
   write/fsync.

 - One that is called after binlog write/fsync, and before engine
   commit() fsync.

These callbacks are guaranteed to be called in the same order that
transactions are written to the binlog.

So we can probably release row locks in the second callback. The question is
if we can release earlier, in the first callback? And if not, do I need to add
a callback that is called after the binlog is successfully written, but before
it is fsync'ed to disk?

 - Kristian.



Follow ups

References