Hi, https://jira.mariadb.org/browse/MDEV-24378 is a major problem for us for 10.4.17. No bugfix currently. Please do not clean 10.4.13. Not sure we can do anything about this other than to not upgrade until that bug is sorted. Kind Regards, Jaco Reproducible: Always
Side note: we've got about 10 hosts with the problem, two of which we've downgraded already and the problem went away, so this is a confirmed regression. Adding wissi as it has been suggested I communicate with him regarding this.
Same with 10.2 branch, 10.2.36 crashes on galera, I need to stick to 10.2.32-r3 for the time being.
New versions out, should be fixed: https://mariadb.com/kb/en/mariadb-10237-release-notes/ https://mariadb.com/kb/en/mariadb-10328-release-notes/ https://mariadb.com/kb/en/mariadb-10418-release-notes/ https://mariadb.com/kb/en/mariadb-1059-release-notes/
I am not seeing MDEV-24378 mentioned in new the releases and the bug is still opened/has not commit linked. Did you mean MDEV-23851 from https://bugs.gentoo.org/741624#c14?
(In reply to Thomas Deutschmann from comment #4) > I am not seeing MDEV-24378 mentioned in new the releases and the bug is > still opened/has not commit linked. > > Did you mean MDEV-23851 from https://bugs.gentoo.org/741624#c14? MDEV-23851 should be fixed according to the changelog, but the last comment in MDEV-24378 mentions MDEV-24275 which should also be fixed.
(In reply to Tomáš Mózes from comment #5) > MDEV-23851 should be fixed according to the changelog, but the last comment > in MDEV-24378 mentions MDEV-24275 which should also be fixed. Looking at the discussion in MDEV-24378 and then at MDEV-24275 it indeed does look like these could be related at the very least. We're going to stick on our usual process so 10.4.13 will remain installed, once .18 goes stable that will start getting installed on a server by server basis over time. We've hard-masked 10.4.17 from our side. So all I'm asking is please don't tree clean 10.4.13 until 10.4.18 has been marked stable for a month or so please.
Btw, thanks Whissi for the very fast bump, just testing 10.2.37 / 10.4.18. Adding myself to Jaco, please keep 10.2.32-r3, 10.3.23-r3 and 10.4.13-r3. I know they are vulnerable, but they don't crash...
(In reply to Jaco Kroon from comment #6) > Looking at the discussion in MDEV-24378 and then at MDEV-24275 it indeed > does look like these could be related at the very least. We're going to > stick on our usual process so 10.4.13 will remain installed, once .18 goes > stable that will start getting installed on a server by server basis over > time. We've hard-masked 10.4.17 from our side. Since you reported the issue it would be appreciated if you could test the new version before we stabilize...
(In reply to Thomas Deutschmann from comment #8) > Since you reported the issue it would be appreciated if you could test the > new version before we stabilize... Sure, I've got two hosts where I could do that which exhibited the problem fairly regularly (ie, once in two days or so). I've deployed to the less mission critical one for the moment. If that's OK till next week I'll update the other. All the other hosts it's either loss of mission critical data if this happens, or major customer impact.
Looks good so far. We've upgraded a couple of other nodes in the meantime as well whenever we encounter a 10.4.17 that crashes. Got one major long query running on a replicated cluster currently, this trivially locks some tables up for 20h/node, if that passes (it crashed on the 10.4.17 node after 16h) I would consider this good to go.
Finding: 10.4.18 performance >> 10.4.17 (finished same query in under 5 hours). And doesn't crash. Performance even better than 10.4.13, but that's within the it could be hardware variance margin region. Since 10.4.13 is considered insecure (I've got one use case where the relevant vulnerabilities are relevant), so perhaps it's worthwhile to consider fast tracking stable on 10.4.18 and dropping 10.4.17. I am aware other subslots are relevant, but I can't comment on those. Anyway, I leave this in your hands now.
Thank you for your feedback. Yes, I'll probably schedule stabilization already for next week.
(In reply to Thomas Deutschmann from comment #12) > Thank you for your feedback. > > Yes, I'll probably schedule stabilization already for next week. Hi Thomas, Doesn't look like this happened, mind if I convert this bug into a stable req for 10.4.18? Presumably need to action same for 10.3.28 and 10.2.37? Kind Regards, Jaco
Thank you for the feedback. I already started stabilization in bug 774096.
According to the comments in https://jira.mariadb.org/browse/MDEV-24378 it should be fixed: "Comments: I have been using 10.5.8 ... the problem has been resolved after upgrading to 10.5.9"
Based on the fact that a stable has been done (or is in progress still for other arches), can we close this?
Sure.
