| Summary: | RabbitMQ can't upgrade from 3.x to 4.x without running a data migration on 3.13 | ||
|---|---|---|---|
| Product: | Koha | Reporter: | Victor Grousset/tuxayo <victor> |
| Component: | Installation and upgrade (command-line installer) | Assignee: | Bugs List <koha-bugs> |
| Status: | NEW --- | QA Contact: | Testopia <testopia> |
| Severity: | major | ||
| Priority: | P5 - low | CC: | aleisha, dcook, jonathan.druart, tomascohen |
| Version: | Main | ||
| Hardware: | All | ||
| OS: | All | ||
| GIT URL: | Initiative type: | --- | |
| Sponsorship status: | --- | Comma delimited list of Sponsors: | |
| Crowdfunding goal: | 0 | Patch complexity: | --- |
| Documentation contact: | Documentation submission: | ||
| Text to go in the release notes: | Version(s) released in: | ||
| Circulation function: | |||
|
Description
Victor Grousset/tuxayo
2025-03-12 08:45:05 UTC
(In reply to Victor Grousset/tuxayo from comment #0) > Reported to Debian as it affects their next release which will do a jump > from 3.10 to 4.0: > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1100165#10 > > Which can't work: https://www.rabbitmq.com/docs/upgrade > «You can only upgrade to RabbitMQ 4.0 from RabbitMQ 3.13.» That's fun... > For us: is there still data in RabbitMQ when stopping a Koha instance and > upgrading it? I recall reading that the DB was basically mirroring the > message queue data during a discussion about the actual need for a dedicated > message queue. Does it mean the koha-common package can wipe the RabbitMQ > data which will allow it to start without issue? The DB stores the jobs, and the Koha app passes messages to background workers via RabbitMQ. If the background worker starts up and can't get a connection to RabbitMQ, it'll query the DB directly for the jobs. What this means is that if you stopped koha-common, nuked RabbitMQ, re-installed RabbitMQ, and started koha-common, you could have data loss if there were any messages in RabbitMQ that hadn't been processed. A dedicated sysadmin who knows to look out for the RabbitMQ issue could perform a RabbitMQ reinstall without a problem. But for someone without sysadmin support... there could be problems depending when the upgrade is performed. =- I'm trying to think of workarounds that tried to determine if there was any pending messages and re-queue or otherwise deal with those messages... but it would probably be messy. > A dedicated sysadmin who knows to look out for the RabbitMQ issue could perform a RabbitMQ reinstall without a problem
They would have to find a package somewhere for the latest 3.X just for the upgrade. Still quite the hassle >_<
(In reply to Victor Grousset/tuxayo from comment #3) > > A dedicated sysadmin who knows to look out for the RabbitMQ issue could perform a RabbitMQ reinstall without a problem > > They would have to find a package somewhere for the latest 3.X just for the > upgrade. Still quite the hassle >_< Sure, but it's not uncommon. I think Keycloak requires stepped upgrades for certain versions. PostgreSQL too for really old versions. We try to make things seamless for people, but I think there needs to be limits too. *** Bug 39868 has been marked as a duplicate of this bug. *** Is this still valid? https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1104149#10 "I wasn't able to reproduce, so probably it does work now?" It seems these turn out to be different problems. See 39868 bug comment 4 On the Debian side, there isn't much they can do without causing other issues. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1100165#44 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1100165#51 At least there are some strategies: > Heavy RabbitMQ users that cannot reset their /var/lib/rabbitmq/mnesia > database could maybe use upstream docker image to attempt a rolling > upgrade. Otherwise, users are advised to simply drain all queues and > make clients point to a new cluster if that's possible. At least the Debian release notes should warn about this: > writing about it in the Trixie release notes I don't know about Ubuntu. And whether that's enough anyway. Should we put a note on the release notes of Bug 41077? Wait, that wouldn't work since there is no patch. Same if we put something in the release notes here. Any ideas? (In reply to David Cook from comment #1) > tuxayo: > > For us: is there still data in RabbitMQ when stopping a Koha instance and > > upgrading it? [...] > > [...] > What this means is that if you stopped koha-common, nuked RabbitMQ, > re-installed RabbitMQ, and started koha-common, you could have data loss if > there were any messages in RabbitMQ that hadn't been processed. Is it something that regularly happens? (have messages in RabbitMQ that haven't been processed) With the reasonable assumption that people don't upgrade Koha in the middle of a day with librarians doing things that use the queue/workers. Or is it something that totally happens? Maybe the assumption is wrong or there is another source of messages that is unavoidable. |