Locking and Concurrency ControlPresentation Transcript
<Insert Picture Here>
Locking and Concurrency Control
Morgan Tocker, MySQL Community Manager
Safe Harbor Statement
4 Years of MySQL Innovation
MySQL Cluster 7.3
MySQL Migration Wizard
MySQL Workbench 6.0
Windows installer & Tools MySQL 5.7 M y S Q L
MySQL Enterprise Monitor 2.3 & e r
M a n a g 3.0
MySQL Enterprise Backup
MySQL Workbench 5.2 & 6.0
MySQL Cluster 7.2
MySQL Cluster 7.1
O r a c l e C e r t i f i c a t i o n s Audit
1.Table Locks, Row Locks and MVCC
3.Deadlocks and Lock Waits Discussion
What is a deadlock?
• A situation when two sessions are trying to acquire
each-other’s respective locks.
• Neither can proceed until the other backs down.
• It’s no different to when two colleagues get in an
irrational argument and neither will back down :)
What is a lock wait?
• One step short of a deadlock.
• You keep trying to do something, but it’s not in the
budget this quarter?
• Not quite sure of the analogy here, but you are
free to retry.
• But.. a fair amount of the time it still won’t work
• InnoDB as a storage engine will detect deadlocks.
• Algorithm is Graph detection http://en.wikipedia.org/
wiki/Cycle_detection - happens virtually instantly.
• Kills the transaction that modified the least rows.
• All changes are rolled back - application developer
must now handle/retry.
• Deadlock is a concurrency issue.
• Same solutions as when you have colleagues
• Don’t make them work-together.
• Reduce concurrency / run known conflicting workers
in serial execution.
• Don’t make them work on big projects together.
• aka lower the stakes!
• Locks are held for the duration of a transaction:
• Put people who don’t work together only on small
projects as needed (smaller transactions).
• Reduce locking required for transactions (more
efficient queries, better indexing).
Preventing Deadlocks (cont.)
• Also, we should accept that some deadlocks are a
fact of life. Continuing co-worker analogy:
• Essential for business growth that people work
• Have to be prepared to handle disputes.
• MyISAM as a storage engine does not actually need
deadlock detection (table locking).
• Where does this leave concurrency?
Preventing Deadlocks (cont.)
• You actually want databases to be optimistic.
• That is set as few locks as possible, knowing that
sometimes oopses will happen.
• Alternative is more locks and less concurrency.
• Database only owns responsibility of alerting
• It may not reapply transaction, since state has
• Application owns responsibility of handling errors.
• Yet maybe 5% of applications do this :(
Lock Wait Timeout
• Will proceed immediately if it can acquire the lock.
• Since most transactions are less than 1 second, at
50 seconds seems unlikely retrying will work.
• May need to voluntarily rollback and try again or give
a user error.
“Requires a replay of the transaction”
The problems probably won’t happen often.
May be easier to kick back to the user:
“try again - no changes have been applied”.
Exception may be asynchronous workers?
• Usually you’ve made the promise of work without
opportunity to back-out.
The “ACID” Contract
• Atomicity - All or none.
• Consistency - Generic term to say all constraints etc
must be honoured (primary key, unique key).
• Isolation - Changes in one transaction to not
interfere with another transaction.
• Durability - When you said that the atomic
transaction was committed, you will honour it. Even
if the server were to crash.
• Most people know this one:
• Transfer $20 from Account A --> Account B.
• Multiple failure states...
• The money may be subtracted from A, but has
not reached B yet.
• Wrap your code between START TRANSACTION
and COMMIT and you get this solved for free.
• Not too much more to add on this one.
• InnoDB has foreign key constraints
• MySQL does not feature CHECK constraints where
another database may allow more domain specific
data validation here as well.
• Actually a very expensive feature for a database to
implement (may require lots of locking, stale data
kept around etc.)
• Many databases make this somewhat tunable.
• There are four levels of isolation describing what
potential unsafe conditions are possible.
• READ-UNCOMMITTED - No isolation
• READ-COMMITTED - Can see other session’s
• REPEATABLE-READ - Won’t see other session’s
committed rows once your session starts (default).
• SERIALIZABLE - Reads actually lock. Can’t modify
any data another session has changed.
• This one’s actually tunable as well.
• InnoDB will not lie by default.
• It means on COMMIT everything should survive a
power loss not be stuck in a buffer in memory.
• Wrap every logical unit of work in START
TRANSACTION and COMMIT.
• Expect failure because failure is a database allowing
• LOCK WAIT TIMEOUT = Retry “may” be possible.
• DEADLOCK = Everything must be retried.
<Insert Picture Here>
Mutexes, Latches & Semaphores
• Common names given to database “internal locking”.
• Today we are not going to differentiate between
• Not unique to databases, required to provide “thread
safety” in multi-threaded programs.
• InnoDB buffer pool is full
• Free space needs to be created in order to be able to
load your desired page into memory.
• In between freeing and loading, someone else fills
• When a page becomes too full, it may need to split
data into other pages.
• It is possible that there could be a thread deadlock if
two pages left and right of each-other reach this
condition at once.
• Can’t decide who should proceed first.
Internal Locking (cont.)
• When mutexes have high contention other tasks are
• Which means that CPUs can appear idle, but nothing
Fixes in newer versions
• Responsibility to fix is on MySQL Engineering Team.
• High Priority for Us.
• Some DBAs will have peripheral knowledge - know
situations when it’s time to upgrade.
Time to Upgrade?
• Kernel mutex split (5.6)
• Lock open mutex split (5.6)
• Buffer pool mutex contention reduced w/8 buffer
pool instances (5.6)
• Multiple rollback segments (5.5)
• Log-sys mutex split (5.5)
• Flush-list mutex split (5.5)
More mentioned at: