| Bug #42757 | Redundant use of LOCK_log in MYSQL_BIN_LOG::write(Log_event*) | ||
|---|---|---|---|
| Submitted: | 11 Feb 2009 12:01 | Modified: | 15 Feb 2010 11:34 |
| Reporter: | Mats Kindahl | Email Updates: | |
| Status: | Closed | Impact on me: | |
| Category: | MySQL Server: Replication | Severity: | S3 (Non-critical) |
| Version: | OS: | Any | |
| Assigned to: | Mats Kindahl | CPU Architecture: | Any |
[16 Mar 2009 13:40]
Mats Kindahl
Patches are attached to WL#4832, since this bug is a subset of what that worklog fixes.
[16 Jan 2010 7:08]
Mats Kindahl
The unnecessary locking of the LOCK_log mutex done when not writing to the binlog file has been fixed as part of WL#2687. The second part, to write all events to the cache before locking the file and writing the data there, is strictly speaking not necessary to fix this bug, but will be fixed as part of WL#4832. Closing bug.
[18 Jan 2010 13:30]
Jon Stephens
Need to know 3-part version number(s) for the changelog entry.
[19 Jan 2010 14:01]
Alfranio Tavares Correia Junior
Hi Jon, It was pushed to 5.6.0 and 6.0.14.
[24 Jan 2010 20:47]
Jon Stephens
DOcumented in the 5.6.0 and 6.0.14 changelogs as follows:
When writing events to the binary log, transactional events (that is,
events that operate on transactional tables) are written to a
thread-specific transaction cache, which is then written to the binary log
on commit. In order to handle non-transactional events, there was a lock
taken on the binary log when entering the function
MYSQL_BIN_LOG::write(Log_event*), even when the event was written to the
transaction cache instead of the binary log, causing a major bottleneck in
replication performance.
Set NDI status, waiting for merge to 5.1. (?)
[15 Feb 2010 11:34]
Jon Stephens
Discussed with Mats -- no further merges expected. Closed.
[8 Mar 2010 0:40]
Paul DuBois
Moved 5.6.0 changelog entry to 5.5.3.
Description: When writing events to the binary log, transactional events (that is events that operate on transactional tables) are written to a thread-specific transaction cache, which is then written to the binary log on commit. In order to handle non-transactional events, there is a lock taken on the binary log (the mutex is LOCK_log) when entering the function MYSQL_BIN_LOG::write(Log_event*). The mutex LOCK_log is taken even in the case that the event is written to the transaction cache instead of the binary log. This is a considerable bottleneck in replication performance. How to repeat: Read the code in log.cc, there is a comment added by Guilhem which reads: /* TODO as Mats suggested, for all the cases above where we write to trans_log, it sounds unnecessary to lock LOCK_log. We should rather test first if we want to write to trans_log, and if not, lock LOCK_log. */ Suggested fix: 1. Do not take the lock on LOCK_log if there is no write to the binary log *file*. 2. Change the logic so that all statements are written to a memory cache (e.g., the transaction cache) before being written to the real binary log. The second issue will allow the performance increase described in WL#4007 to work even for non-transactional events.