Details
-
Task
-
Status: Needs Feedback (View Workflow)
-
Major
-
Resolution: Unresolved
-
None
Description
MySQL #WL10310 optimizes the redo log(unlock and write concurrently). Does MariaDB plan to optimize redo log?
Attachments
Issue Links
- relates to
-
MDEV-14425 Change the InnoDB redo log format to reduce write amplification
-
- Closed
-
-
MDEV-14462 Confusing error message: ib_logfiles are too small for innodb_thread_concurrency=0
-
- Closed
-
-
MDEV-27774 Reduce scalability bottlenecks in mtr_t::commit()
-
- Closed
-
-
MDEV-33515 log_sys.lsn_lock causes excessive context switching
-
- Closed
-
-
MDEV-21925 Redo log mutex competition is serious
-
- Closed
-
- links to
I am not convinced that a lock-free algorithm is always better than one that uses mutexes. It could lead to lots of busy work (wasted CPU cycles in polling loops).
In
MDEV-14425, we plan to modify the InnoDB redo log file format in a way that minimizes the work done while holding a mutex (encrypting data and computing checksums). The new file format would also be compatible with any physical block size, with anything between the smallest write size of persistent memory (64 bytes?) to the optimal write size on an SSD (supposedly at least up to 4096 bytes).MDEV-14462mentions another idea to try: on mtr_t::commit(), do not write log, but pass the work to a dedicated log writer task. We would have to validate this idea by prototyping; I cannot guarantee that it would help much, especially afterMDEV-14425has been implemented.MDEV-12353andMDEV-21724redefined the redo log record format in MariaDB 10.5.2. Because of the mutex contention that we have beforeMDEV-14425has been implemented, even a small change to the redo log volume makes a large difference.