Redo log
- 2. The following is intended to outline our general product direction. It is intended for information purposes only, and may not be incorporated into any contract. It is not a commitment to deliver any material, code, or functionality, and should not be relied upon in making purchasing decisions. The development, release, timing, and pricing of any features or functionality described for Oracle's products may change and remains at the sole discretion of Oracle Corporation. Safe Harbor Slide
- 3. Mini transactions When they are used ? InnoDB stores all data in 16kB pages (default size) and all changes to these pages go through usage of mini transactions. This means that mini transactions are used very, very often. Single user transaction consists of multiple mini transactions. Commit of transaction itself requires a new mini transaction (which modifies undo log pages). What they are for ? • Allow to do atomic changes to multiple pages • Postpone writes of re-modified pages to disk • Write only log of changes applied to pages
- 4. Mini transaction commit in MySQL 5.7 Reserve place and space in the redo log Write log records to the log buffer Mark modified pages, add them to flush lists and release latches 1 2 3 ACQUIRE / DO WORK / RELEASE Mutex exchange: log_sys → log_flush_order caused performance issue when first thread started to wait for the log_flush_order mutex, holding the log_sys mutex.
- 5. New design in 8.0.5+ Reserve place and space in the redo log Write log records to the log buffer Mark modified pages, add them to flush lists and release latches1 2a 3a Report written2b Report done3b
- 6. Comparison of mtr_commit in 5.7 vs in 8.0.5
- 7. 1. The LSN sequence defines time line for recovery. 2. Stages of mini transaction commit are executed concurrently and threads may interleave. 3. Threads concurrently report finished operations to a new lock-free data structure. 4. The data structure tracks up to which LSN all operations are reported as finished (per stage). Tracking concurrent operations
- 8. Limited window for pending operations (L) Pending tasks (in progress) Wait (unlikely) All past tasks done Tracking concurrent operations 1.Window of pending operations is limited (to L bytes of the LSN sequence (1 MB)) 2.Before adding dirty page to flush list, wait until its oldest_lsn fits the current window. 3.This guarantees that checkpoint_lsn could be written at oldest_lsn - L
- 9. Relaxed order of pages in flush list
- 10. /* Create a new “light task” */ your_start_time = time_sequence.next_time(planned_time_interval); /* Wait until it's permitted to start the execution (unlikely to wait). */ tasks_done.wait_until_in_current_window(your_start_time); /* Do your work */ foo(); /* Report it's done. */ tasks_done.report_task_done(your_start_time, your_start_time + planned_time_interval); Generalized algorithm (extracted)
- 11. 1 2 3 S This step is just to have an option to: “stop the world” which is very uncommon Sharded RW-latch for mtr_commit
- 12. New strategy for writing to disk: 1. Sooner log is written, sooner transaction's commit can finish. 2. We keep an eager loop of writes to OS buffer. 3. We keep an eager loop of fsyncs. However: 4. We avoid rewriting log blocks - we write only full log blocks unless none is ready. 5. We preserve write-ahead strategy to avoid read-on-write issue. Redo threads
- 13. Waiting for redo written / flushed New strategy to wait for redo written / flushed • Select finer grained event (in 5.7 there was only 1 event for that) • Granularity adjusted to the expected granularity of writes (per log block) • Optionally use spin delay first (if CPU is not busy) • Users waiting in block for which write started, when it was only partially filled, could experience false wake-ups.
- 14. Waking up waiting threads
- 16. CPU usage is monitored not to use spin delay when server is almost idle, and not to use spin delay when we don't have enough CPU power for useful things. Average time between consecutive requests to write or flush redo is monitored to detect situation in which requests are really not often and spin delay is not required. In such cases we also start sleeps with higher timeout. This helps to avoid wasting CPU in cases where log threads don't need to be so eager. Consuming unused CPU to improve TPS 1 2
- 17. Dedicated solution (5.7-alike) for low-concurrent workloads to avoid need for spinning and consuming CPU and still deliver top TPS for that # of connections. Changes to redo format. Dynamic resize of the redo log on disk, no more wrapping within single file. Checkpoints stored within each log file. No longer logfile0 is special. Changes to redo log incoming soon 1 2
- 18. Thank You Paweł Olchawa Senior Software Developer Oracle / MySQL / InnoDB