Michal Kuratczyk

Retested a year later: I believe we can close this. As far as I can tell, these days, if `khepri_db` isn't enabled, then it is not started. Therefore, a failed...

The actual behaviour is correct (at least I couldn't trigger a problem). The idea for what could go wrong was: 1. queue `foo` exists in Mnesia 2. migration is triggered...

This PR remediates this problem in a different way. Quorum queues can still be declared with a lower number of members than configured, but the members will be added when...

Update: starting with 3.11.4, `max-age` retention is evaluated every hour.

Currently, recovering 1 million 1kb messages in a single queue takes 6-7 seconds for me. I can't even monitor this process with the Management stats, so I think we can...

one final note: this was tested with Ra 2.6.3 (not included in any released versions yet), which includes (another) significant improvement for long queue recovery: https://github.com/rabbitmq/ra/pull/385

Update after almost a year of development. Tests performed on the [`khepri` branch](https://github.com/rabbitmq/rabbitmq-server/commit/623b3443af368b6af0a1b656ad365fdafcfc761a) with `khepri_db` FF disabled/enabled. 1. `perf-test -p -e amq.topic -t topic -qp q-%d -qpf 1 -qpt 10000...

Diana pointed out this is not a valid test. `perf-test` default to transient queues, which are not supported in 4.0. After adding `-ad false -f persistent`, Mnesia takes 245s and...

Restested a year later. The peak is below 900MB. Sill higher than Mnesia (600MB), but the import is significantly faster (90s for Khepri, 174s for Mnesia), so I think that's...

We realize there are use cases, they just don't make the problem any simpler. :) Development environments are the easiest case unless you have some special requirements. What's the benefit...