Skip to content
  • Frazer Clement's avatar
    584403d1
    WL7639 Ndb Active Active Manageability improvements · 584403d1
    Frazer Clement authored
    Add ndb_slave_last_conflict_epoch status variable
    
    The ndb_slave_last_conflict_epoch status variable records the last slave
    epoch which included conflict handling activity.
    
    It is set when a MySQLD slave is applying binlogs to a cluster, and
    detects a conflict.
    
    It is set once the conflict causing transaction has been committed into
    the slave cluster.
    
    It is set to the slave cluster epoch assigned to the committed conflict 
    causing transaction.
    
    The intention is that in an asymmetric active-active setup (e.g. 
    NDB$EPOCH), this will indicate when the PRIMARY cluster last experienced
    a conflict.
    
    If this variable is <= the MaximumReplicatedEpoch then from the Primary 
    cluster's point of view there are no in-flight realignment operations, 
    and therefore no outstanding realignment dependencies.
    
    This can be a valuable state to be aware of when considering role
    switchovers or failure handling steps required.
    
    A new testcase is added to verify the behaviour of this new status
    variable.
    584403d1
    WL7639 Ndb Active Active Manageability improvements
    Frazer Clement authored
    Add ndb_slave_last_conflict_epoch status variable
    
    The ndb_slave_last_conflict_epoch status variable records the last slave
    epoch which included conflict handling activity.
    
    It is set when a MySQLD slave is applying binlogs to a cluster, and
    detects a conflict.
    
    It is set once the conflict causing transaction has been committed into
    the slave cluster.
    
    It is set to the slave cluster epoch assigned to the committed conflict 
    causing transaction.
    
    The intention is that in an asymmetric active-active setup (e.g. 
    NDB$EPOCH), this will indicate when the PRIMARY cluster last experienced
    a conflict.
    
    If this variable is <= the MaximumReplicatedEpoch then from the Primary 
    cluster's point of view there are no in-flight realignment operations, 
    and therefore no outstanding realignment dependencies.
    
    This can be a valuable state to be aware of when considering role
    switchovers or failure handling steps required.
    
    A new testcase is added to verify the behaviour of this new status
    variable.
Loading