-
Notifications
You must be signed in to change notification settings - Fork 15
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
mysql-router-k8s: bootstrap failure #345
mysql-router-k8s: bootstrap failure #345
Comments
Waiting for canonical/data-platform-libs#108 before investigating |
It looks like the connection to MySQL server was quite unreliable My interpretation of the logs for the failed unit:
Router fails here when checking if an old router user+metadata needs to be cleaned up:
Router has succeeded in cleaning up the old router user & metadata (since it's failing a line later):
While MySQL server was recovering, I'm guessing it overrode/reverted the changes mysql-router made to the router metadata (but not the router user) I believe the cause of this issue is the same as here: #260 (comment) MySQL server is providing connection information to MySQL Router when it is not ready to serve traffic (i.e. not in a quorum) Router, when it sees the connection information, assumes that the cluster is available and that any operators router performs will be persisted. Router deletes the router user & router cluster metadata, assuming that if one of those changes goes through, both changes will go through (it deletes the user after the metadata as a safe guard). However, during server's recovery process, the user deletion goes through but the metadata deletion is reverted—causing router to fail to bootstrap |
Instead of relying on the existence of old router user to cleanup router from cluster metadata, force bootstrap so that the metadata does not need to be cleaned up. Fixes canonical/mysql-k8s-operator#345. The issue was that the router charm would delete the user & router metadata, but that only the user deletion would go through. Then, on the router charm's next hook, the bootstrap failed because the metadata was not cleaned up.
Instead of relying on the existence of old router user to cleanup router from cluster metadata, force bootstrap so that the metadata does not need to be cleaned up. Fixes canonical/mysql-k8s-operator#345. The issue was that the router charm would delete the user & router metadata, but that only the user deletion would go through. Then, on the router charm's next hook, the bootstrap failed because the metadata was not cleaned up. Additional context: https://chat.canonical.com/canonical/pl/temrphcp3in5xqftkaxgowqtkr
Instead of relying on the existence of old router user to cleanup router from cluster metadata, force bootstrap so that the metadata does not need to be cleaned up. Fixes canonical/mysql-k8s-operator#345. The issue was that the router charm would delete the user & router metadata, but that only the user deletion would go through. Then, on the router charm's next hook, the bootstrap failed because the metadata was not cleaned up. Ported from canonical/mysql-router-k8s-operator#187
Instead of relying on the existence of old router user to cleanup router from cluster metadata, force bootstrap so that the metadata does not need to be cleaned up. Fixes canonical/mysql-k8s-operator#345. The issue was that the router charm would delete the user & router metadata, but that only the user deletion would go through. Then, on the router charm's next hook, the bootstrap failed because the metadata was not cleaned up. Ported from canonical/mysql-router-k8s-operator#187
Instead of relying on the existence of old router user to cleanup router from cluster metadata, force bootstrap so that the metadata does not need to be cleaned up. Fixes canonical/mysql-k8s-operator#345. The issue was that the router charm would delete the user & router metadata, but that only the user deletion would go through. Then, on the router charm's next hook, the bootstrap failed because the metadata was not cleaned up. Ported from canonical/mysql-router-k8s-operator#187
Steps to reproduce
Failed multi-node test run from Canonical Solutions QA team.
Multi-node microstack deployment on baremetal with deployment in many-mysql mode - mysql per service.
Majority of mysql apps deploy and scale correctly however on mysql-router-k8s instance failed to bootstrap.
Expected behavior
All mysql-router-k8s units bootstrap correctly.
Actual behavior
Failure of single mysql-router-k8s unit.
Versions
Operating system: 22.04
Juju CLI: 3.2.3
Juju agent: 3.2.3
mysql-k8s charm revision: 99
mysql-router-k8s charm revision: 69
microk8s: 1.26-strict/stable
Log output
Logs from the failed deployment are linked from:
https://bugs.launchpad.net/snap-openstack/+bug/2042906
direct link:
https://oil-jenkins.canonical.com/artifacts/628e5903-4772-4a3e-9b0a-80cc04d3c6d3/index.html
Additional context
https://bugs.launchpad.net/snap-openstack/+bug/2042906
The text was updated successfully, but these errors were encountered: