Clustering fails on clean environment
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
MySQL InnoDB Cluster Charm |
Invalid
|
Critical
|
Unassigned | ||
snap-mysql-shell |
Fix Released
|
Critical
|
David Ames |
Bug Description
Clustering doesn't always work on a clean environment. This was deployed using this charm on a clean environment (OpenStack): cs:~openstack-
LOGS
====
unit-mysql-
unit-mysql-
unit-mysql-
unit-mysql-
unit-mysql-
WARNING: A GTID set check of the MySQL instance at '10.5.0.19:3306' determined that it
contains transactions that do not originate from the cluster, which must be
discarded before it can join the cluster.
10.5.0.19:3306 has the following errant GTIDs that do not exist in the cluster:
e12d3fa8-
WARNING: Discarding these extra GTID events can either be done manually or by completely
overwriting the state of 10.5.0.19:3306 with a physical snapshot from an
existing cluster member. To use this method by default, set the
'recoveryMethod' option to 'clone'.
====
Attached is the juju crash-dump
Changed in charm-mysql-innodb-cluster: | |
status: | Triaged → Invalid |
Changed in snap-mysql-shell: | |
status: | New → Triaged |
importance: | Undecided → Critical |
assignee: | nobody → David Ames (thedac) |
TRIAGE:
This may be a trailing java script style setting for "recoveryMethod" [0] rather than the pythonic "recovery_method."
Look for any other possible java script camel capitalized variables or settings and change them to pythonic underscore separated "_".
[0] https:/ /github. com/openstack/ charm-mysql- innodb- cluster/ blob/master/ src/lib/ charm/openstack innodb_ cluster. py#L650
/mysql_