Details
-
New Feature
-
Status: Open (View Workflow)
-
Minor
-
Resolution: Unresolved
-
None
Description
MDEV-19749 implements MDL fast lanes, which is roughly speaking multi-instance MDL locks. They allow better scalability.
Initial implementation divided locks into heavyweight and lightweight categories. Lightweight locks can be served via fast lanes whereas heavyweight locks disable fast lanes.
It works very well until certain statements are executed. Once these come into play, scalability is back to pre-fast lanes levels.
OTOH there're statements that are still compatible with certain lightweight locks and in theory these lightweight locks can be served via fast lanes.
For example BACKUP STAGE START is fully compatible with all DDL AND DML. It means the latter can be served via fast lanes and experience improved scalability even when certain backup stages are running.
InnoDB should be able to use fast lanes for almost whole duration of backup, the only exception is BACKUP STAGE BLOCK COMMIT, which should be quite short anyway.
LOCK TABLES ... READ should allow use of fast lanes for SELECT statements and some stages of lengthy ALTER TABLE can allow use of fast lanes for DQL/DML.
It can be relatively simple to implement if fast lane "closers" counter is replaced with multiple "closers" counters for each lock type. This still needs research though.
This is just a raw idea. It is to be seen if it is worth implementing if we get complaints about this fast lanes limitation.
Attachments
Issue Links
- split from
-
MDEV-19749 MDL scalability regression after backup locks
-
- Closed
-