Details
-
Type:
Bug
-
Status: Closed
-
Priority:
Major
-
Resolution: Fixed
-
Affects Version/s: 10.0.15, 5.5.42
-
Fix Version/s: 5.5.43
-
Component/s: Replication
-
Labels:
Description
Thanks to Jonas Oreland who found this in the code:
>> > @@ -7387,6 +7434,10 @@
>> MYSQL_BIN_LOG::trx_group_commit_leader(group_commit_entry *leader)
>> >
>> > DEBUG_SYNC(leader->thd, "commit_before_get_LOCK_commit_ordered");
>> > mysql_mutex_lock(&LOCK_commit_ordered);
>> > + /**
>> > + * TODO(jonaso): Check with Kristian,
>> > + * if we rotate:d above, this offset is "wrong"
>> > + */
>> > last_commit_pos_offset= commit_offset;
>>
>> Agree, good catch, I think.
>> If we rotate, we already update last_commit_pos_file and _offset. So the code
>> needs to remember if it rotated, and skip the errorneous offset update in this
>> case.
This happens during group commit, if we rotate the binlog as part of the group
commit due to max binlog file size reached.
Gliffy Diagrams
Attachments
Activity
- All
- Comments
- Work Log
- History
- Activity
- Transitions
http://lists.askmonty.org/pipermail/commits/2015-February/007463.html
BTW, this bug only affects non-transactional commits.