Transaction Coordinator Log Overview

The transaction coordinator log (tc_log) is used to coordinate transactions that affect multiple storage engines. There are currently two implementations of the transaction coordinator log:

• Binary log-based transaction coordinator log
• Memory-mapped file-based transaction coordinator log

Binary Log-Based Transaction Coordinator Log

This transaction coordinator uses the binary log, which is enabled by the log_bin option.

Memory-Mapped File-Based Transaction Coordinator Log

This transaction coordinator uses the memory-mapped file defined by the --log-tc server option.

Some facts about this log:

• The log consists of a memory-mapped file that is divided into pages of 8KB size.
• The usable size of the first page is smaller because of the log header. There is a PAGE control structure for each page.
• Each page (or rather its PAGE control structure) can be in one of the three states - active, syncing, pool.
• There could be only one page in the active or syncing state, but many in the pool state - pool is a fifo queue.
• The usual lifecycle of a page is pool->active->syncing->pool.
• The "active" page is a page where new xid's are logged.
• The page stays active as long as the syncing slot is taken.
• The "syncing" page is being synced to disk. no new xid can be added to it.
• When the syncing is done the page is moved to a pool and an active page becomes "syncing".

The result of such an architecture is a natural "commit grouping" - If commits are coming faster than the system can sync, they do not stall. Instead, all commits that came since the last sync are logged to the same "active" page, and they all are synced with the next - one - sync. Thus, thought individual commits are delayed, throughput is not decreasing.

When an xid is added to an active page, the thread of this xid waits for a page's condition until the page is synced. When a syncing slot becomes vacant one of these waiters is awakened to take care of syncing. It syncs the page and signals all waiters that the page is synced. The waiters are counted, and a page may never become active again until waiters==0, which means that is all waiters from the previous sync have noticed that the sync was completed.

Note that a page becomes "dirty" and has to be synced only when a new xid is added into it. Removing a xid from a page does not make it dirty - we don't sync xid removals to disk.