-
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.
Frazer Clement authoredAdd 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