-
Notifications
You must be signed in to change notification settings - Fork 3.9k
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
Per-vhost message store #567
Comments
|
What if we enable per vhost message stores for new vhosts only, and recommend to shovel messages for migration? |
I'm afraid that's not gonna fly with hosted RabbitMQ providers, and at least some Cloud Foundry users. It would be great to automatically migrate messages on boot (if we can). |
Initial research: |
Migration mechanism proposal:
|
@hairyhum given that upgrades perform a backup of the node data dir, that sounds reasonable. |
Before #567 all binding recover functions were executed once on node restart. Executing table_filter can be expensive with high number of vhosts and bindings and effectively should be called only once. Moved to a separate function, which should be called from the global recovery function (`rabbit_vhost:recover/0`)
Before #567 all binding recover functions were executed once on node restart. Executing table_filter can be expensive with high number of vhosts and bindings and effectively should be called only once. Moved to a separate function, which should be called from the global recovery function (`rabbit_vhost:recover/0`) (cherry picked from commit e5f4cbd)
This idea has been floating around since at least late 2012: we should use separate message stores for different vhosts, e.g. two (for persistent, transient messages) per vhost.
Some of the benefits are:
Downsides:
The text was updated successfully, but these errors were encountered: