#innodb
Posts
-
Digging into MariaDB's Source 10: InnoDB Part 1 — Pages, the Buffer Pool and B-trees
We go below the handler and read, in the source, the three containers InnoDB keeps data in. The 16KB page with its FIL header, page header, records and page directory; the buffer pool that keeps pages in memory (buf_page_get_gen, the old part of the LRU list, dirty pages and the page cleaner); the clustered-index B-tree that is the table itself (search_leaf, page splits); and the mini-transaction mtr_t that bundles page latches with redo. We open an .ibd file with od and read page headers, look inside the buffer pool through information_schema, grow a table to count B-tree height and splits, and use gdb to watch SELECT and INSERT reach the B-tree.
-
Digging into MariaDB's Source 11: InnoDB Part 2 — Transactions, MVCC, Undo and Locks
We follow, in the source of the reference commit, how one COMMIT travels from the server layer's ha_commit_trans() to InnoDB's trx_t::commit(), how REPEATABLE READ shows you old values through a ReadView and the undo chain, how purge cleans up versions nobody can see any more, and how row locks, gap locks, lock waits and deadlock detection work. Two-session examples show the snapshot, a lock wait, a deadlock and the history list length with our own eyes.
-
Digging into MariaDB's Source 12: Two Logs — the Redo Log, the Binlog and Crash Recovery, and Wrapping Up
What it means for data to be on disk when COMMIT returns. We follow InnoDB's redo log (log_sys, LSNs, mtr_t::commit, log_write_up_to) and the spot where innodb_flush_log_at_trx_commit splits, the checkpoint and the layout of ib_logfile0, crash recovery after kill -9 that rolls forward with redo and back with undo, the server-level binlog and its events, and the two-phase and group commit that tie the two logs together by XID. Using DBUG crash points we kill the server in both gaps of the two-phase commit and watch what recovery does, then wrap up all twelve parts of the series.