Conflicting Transaction Sets following Complete Outage of InnoDB Cluster
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
MySQL Server |
Unknown
|
Unknown
|
|||
mysql-8.0 (Ubuntu) |
Fix Released
|
Critical
|
Unassigned |
Bug Description
[Impact]
The 8.0.18 version of mysql-8.0 has this upstream bug:
https:/
Note 8.0.17 did not display this bug.
After a complete outage dba.rebootClust
output: "ERROR: Conflicting transaction sets between 10.5.0.55:3306 and 10.5.0.52:3306 Dba.rebootClust
[Regression Potential]
TBD
[Fix]
[Test Case]
* Build an InnoDB cluster
- var cluster = dba.createClust
- cluster.
- cluster.
- cluster.
* Shut each node of the cluster down (reboot)
* Start mysql on each node
* (Maybe?) INSERT some random data into the same table on all cluster instances
* Run dba.rebootClust
The cs:~openstack-
[Workaround]
From upstream bug report,
"""
a) Shutdown the instance that contains the GTID subset (typically a secondary that was behind, or a primary that was ejected from the cluster)
b) Execute rebootClusterFr
c) Start the instance from step a)
d) Execute a cluster.rescan() to bring the instance back into the cluster
"""
Changed in mysql-8.0 (Ubuntu): | |
status: | New → Triaged |
importance: | Undecided → Critical |
tags: | added: regression-update |
Changed in mysql-8.0 (Ubuntu): | |
status: | Triaged → Fix Released |
A patch is not yet available for this issue from upstream, however it is confirmed by them with their own test case defined, and a workaround, both of which I've updated in the bug description. I've linked the upstream bug to hopefully give visibility when a patch does become available.