| Bug #74683 | Ignorable events do not work and are not tested | ||
|---|---|---|---|
| Submitted: | 4 Nov 2014 14:17 | Modified: | 2 Mar 2015 12:56 |
| Reporter: | Sven Sandberg | Email Updates: | |
| Status: | Closed | Impact on me: | |
| Category: | MySQL Server: Replication | Severity: | S2 (Serious) |
| Version: | 5.6 | OS: | Any |
| Assigned to: | CPU Architecture: | Any | |
[12 Feb 2015 12:27]
Laurynas Biveinis
$ git show -s ca7bd0a
commit ca7bd0a7f490a3e679483ee67791212865ce1470
Author: Daogang.qu <bill.qu@oracle.com>
Date: Sun Nov 16 16:16:13 2014 +0800
Bug#19949915 IGNORABLE EVENTS DO NOT WORK AND ARE NOT TESTED
In 5.6, Ignorable log events were introduced. These events have
the flag LOG_EVENT_IGNORABLE_F flag (0x80) set in the flags field.
When the server (specifically, the replication receiver and applier
threads) sees an event with a type code it does not recognize, the
server is supposed to check if this flag is set. If the flag is not
set, the server generates an error and stops; if the flag is set,
the server ignores the event. The purpose is to allow future server
versions to introduce new event types that the slave can ignore
(such as informational event types). However, this does not work,
since the slave applyer thread explicitly checks if the type code
is in the range of known event types, and reports an error, before
it goes further and checks if the event is ignorable.
To fix the problem, the slave applyer thread does not check if this
is a known event type any more. And we also remove unnecessary check
for PREVIOUS_GTIDS_LOG_EVENT, then we can replicate from 5.7 with
WL#7592 and disabled gtid_mode to 5.6 with disabled gtid_mode without
introducing a new type code for PREVIOUS_GTIDS_LOG_EVENT in 5.7.
[12 Feb 2015 12:28]
Laurynas Biveinis
Is the bug status up to date?
[2 Mar 2015 12:56]
David Moss
The following was added to the 5.6.23 and 5.7.6 changelogs with commit 5345: Ignorable log events were introduced in MySQL 5.6, but were found to not be functioning correctly. This has now been fixed.
[2 Mar 2015 13:15]
David Moss
Posted by developer: The following was added to the 5.6.23 and 5.7.6 changelogs with commit 5345: Ignorable log events were introduced in MySQL 5.6, but were found to not be functioning correctly. This has now been fixed.
Description: In 5.6, Ignorable log events were introduced. These events have the flag LOG_EVENT_IGNORABLE_F flag (0x80) set in the flags field. When the server (specifically, the replication receiver and applier threads) sees an event with a type code it does not recognize, the server is supposed to check if this flag is set. If the flag is not set, the server generates an error and stops; if the flag is set, the server ignores the event. The purpose is to allow future server versions to introduce new event types that the slave can ignore (such as informational event types). However, this does not work (and seems it never worked): the server explicitly checks if the type code is in the range of known event types, and reports an error, before it goes further and checks if the event is ignorable. Also, it seems that there is no test case that covers this. There should be a test case that 'simulates' an event with an unknown type code, e.g., by overwriting the event type in one event in the relay log with a big number. How to repeat: Read the code (cf suggested fix) This is also the reason for BUG#19949096. Suggested fix: == modified file 'sql/log_event.cc' --- sql/log_event.cc revid:sayantan.dutta@oracle.com-20140911092111-28h56ffurfiunzkm +++ sql/log_event.cc 2014-11-04 14:13:50 +0000 @@ -1446,7 +1446,6 @@ Log_event* Log_event::read_log_event(con /* Check the integrity */ if (event_len < EVENT_LEN_OFFSET || - buf[EVENT_TYPE_OFFSET] >= ENUM_END_EVENT || (uint) event_len != uint4korr(buf+EVENT_LEN_OFFSET)) { DBUG_PRINT("error", ("event_len=%u EVENT_LEN_OFFSET=%d "