1. MySQL/InnoDB изнутри:
узкие места
Александр Крижановский

2. Узкие Места (о чем пойдет речь)
● InnoDB в MySQL (5.5, 5.6), Percona Server, MariaDB
● MySQL 5.6.11 т.к. 5.6 продолжает оптимизироваться (5.6.2,
5.6.4, ...)
● Репликация Galera и стандартная асинхронная репликация
● Узкие места:
● вытеснение страниц из buffer pool
● kernel mutex
● однопоточная репликация

3. Buffer Pool
MySQL, Percona Server, MariaDB
● Собственный кэш БД с 16KB страницами
● Вытеснение страниц по LRU
● Асинхронное (background) или синхронное вытеснение
(блокируется поток запроса)
● Страница может быть в
● flush_list – список грязных страниц (нехватка места в redo log)
● LRU_list – список страниц, к которым был доступ (нехватка
места в buffer pool)

4. Потоки Вытеснения из Buffer Pool
MySQL 5.1, 5.5 (MariaDB 5.5, Percona Server 5.5)
● flush_list — master_thread (может быть пробужен потоком запроса)
● LRU_list — потоки запросов
MySQL 5.6 (MariaDB 10.0, Percona Server 5.6)
● flush_list — master_thread (checkpoint), поток page_cleaner
● LRU_list — поток page_cleaner

5. LRU (Least Recently Used)
● В кэше только страницы, к которым недавно обращались
● Частота обращений не учитывается (нет истории)
=> При сканировании ведет себя очень плохо

6. CAR/CART
● Clock with Adaptive Replacement (CAR)
● CAR with Temporal filtering (CART)

7. Kernel Mutex в MySQL 5.1 и 5.5
(Percona Server 5.5, MariaDB 5.5)
● Locking
● record lock: создание, взятие/снятие, поиск конфликтующих
локов, операции с хэшем локов, ...
● table lock: создание, взятие/поиск конфликтов, ...
● Рекурсивный поиск дедлоков
● Transaction commit/rollback
● создание транзакции (аллокация памяти, Bug# 54982)
● MVCC views
● создание read view (аллокация памяти, Bug# 49169)

8. lock_sys->mutex и trx_sys->mutex в MySQL 5.6
(Percona Server 5.6, MariaDB 10.0)
● Locking:
● все тоже самое, но с lock_sys->mutex
● Transaction commit/rollback & MVCC views:
● RO транзакции не учавствуют в MVCC snapshot
● 2 списка транзакций: trx_sys->rw_trx_list и trx_sys->ro_trx_list
● При создании read view (аллокация памяти) берется
trx_sys->mutex
● при создании транзакции мьютекс уже не берется

9. Репликация Galera (Database State Machine)
и Локи
● Database State
Machine:
детерминированность
переходов по
состояниям разных нод
кластера
● На rollback также
задействован
kernel_mutex

10. Репликация Galera: сертификация
● 3 транзакции с
одним primary key
● 4 rollback'а на
всех нодах

11. Гранулярность Латчей
для Record и Table Locks
● Отдельные латчи для Table и Record локов
● N латчей для таблиц и M латчей для строк
● Латчи хранятся в хэш-таблице с индексом по:
● блоку (lock_rec_hash(space, page_no)) для record lock'ов (record
lock'и сами хранятся в хэше, индексируемом блоком => один
латч будет защищать один и тот же набор локов)
● по tablespace (innodb_file_per_table)

12. Многопоточная Репликация: MySQL 5.6
● Per-database concurrency
● slave-parallel-workers — число slave потоков (не имеет смысл
ставить больше, чем число баз данных)
● GTID (Global Transaction Identifiers)
● tuple <SERVER_UUID, GNO> : GNO = 1,2,3,..
● Был еще и Google GTID для MySQL 5.0 и 5.1

13. Многопоточная Репликация: Galera
● wsrep_slave_threads — число slave потоков
● apply_cb() выполняется после сертификации, которая:
● захватывает монитор (local ordering)
● проверяет global seqno транзакции
● проверяет зависимость транзакций по primary keys
● wsrep_apply_cb() → wsrep_apply_rbr() → ev->apply_event()

14. Многопоточная Асинхронная Репликация
● Нужны global transaction ID для async replication
● Поток slave_sql вместо исполнения эвентов, кладет их в очередь,
разделяемую worker'ами
● Worker'ы конвертируют эвент в Galera writeset и передают его
Galera Replicator'у

15. Спасибо!
ak@natsys-lab.com