Details
Description
When deploying mariadb via openstack-ansible in the CI we get timeout sometimes.
i did ran the test on a private cloud and i can reproduce the issue most time i run the deployment tooling.
here is the issue we saw in the CI.
https://zuul.opendev.org/t/openstack/build/fed013733f9f415bb2d1118a26287bab/log/job-output.txt#10054
I'm available to do some more testing and provide trace and other info is needed, you can reach me on IRC.
Thanks
Attachments
Issue Links
- causes
-
MDEV-27789 mysql_upgrade / mariadb-upgrade in 10.6.6 is putting password in host argument
-
- Closed
-
- includes
-
MDEV-27279
mariadb_upgrade add --check-if-upgrade-is-needed / restrict tests to major version
-
- Closed
-
-
-
- Stalled
-
- relates to
-
-
- Closed
-
-
MDEV-30499 mariadb in-server upgrade
-
- Open
-
- split to
-
-
- Open
-
Activity
> 2) Debian upgrade runs mysql_upgrade non-deterministically. It was already described in MDEV-14622 and it is still the case. Below is a proof-log of 10.5=>10.6 upgrade (official releases) I performed today on Debian 9. As you see after the package upgrade ends, sys schema wasn't created, general log is empty, which indicates mysql_upgrade wasn't even started. I have to run it manually to finalize the upgrade. When I did exactly the same on, say, Ubuntu 20.04, sys schema was there and the general log was full of mysql_upgrade stuff. I can't say whether the same happens every time on a certain debian/ubuntu flavor or it is sporadic, but it is definitely possible to end up with not upgraded schema.
elenst did you noticed this behavior with other Debian/Ubuntu versions? I can confirm it on Debian 9 but I am not able to reproduce it with something else than Debian 9.
Elena Stepanova did you noticed this behavior with other Debian/Ubuntu versions?
I can't say one way or another. If I did, I wouldn't necessarily register it because I find it irrelevant. Unless somebody knows about a specific bug fixed in all other versions so that the fix has magically made this code behave deterministically, relying on better/more lucky timing of certain versions over others isn't wise.
The argumentation in the comments of this Jira is basically pros and cons for implementing MDEV-30499. After thinking about this long and hard, I still stand by the arguments I listed in https://jira.mariadb.org/browse/MDEV-27068?focusedCommentId=206749&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-206749 and think it would be best if mariadbd server itself took care of the upgrade without relying on external scripts or users to run mariadb-upgrade. Such a dependency is simply too brittle.
We have several other causes where you specify an option several times and it does more, like --version, --big --big (in mtr) etc.
As this is something that one should never ever do in normal circumstances (because it leads to other (documented) troubles), adding a new flag is overkill.
--force --force is also good from the point that it is backward compatible with older versions, so one can use this without having to check if the mysql_upgrade supports it or not.
The option is documented in both mysql_upgrade and the KB, as it should be.