Skip to content
  • Daogang.qu's avatar
    ca7bd0a7
    Bug#19949915 IGNORABLE EVENTS DO NOT WORK AND ARE NOT TESTED · ca7bd0a7
    Daogang.qu authored
    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.
    ca7bd0a7
    Bug#19949915 IGNORABLE EVENTS DO NOT WORK AND ARE NOT TESTED
    Daogang.qu authored
    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.
Loading