You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
As the last step of migrating to Khepri (ie enabling the khepri_db feature flag) all Mnesia related files are deleted (https://github.com/rabbitmq/rabbitmq-server/blob/main/deps/rabbit/src/rabbit_khepri.erl#L1469-L1480) However the heuristic to find Mnesia related files is too eager, it deletes everything in the data dir recursively except for those which are known to be not Mnesia (ie msg_stores, coordination, quorum, stream and rabbitmq_metadata dirs are not deleted).
This is an issue for community plugins which want to migrate away from Mnesia into a new subdir. (They might not even use Khepri, or use Khepri but a different store id.) As an example (and the motivation of this ticket) the delayed message store is planned to store its leveldb data in a dmx subdir (https://github.com/rabbitmq/rabbitmq-delayed-message-exchange/pull/253/files#diff-64860364dca47a85f9e9fc932a30c53a07673f78e50ebc2a622e64bf78e91ce2R41-R42). After the delayed message plugin nicely migrated its messages to a new storage backend, the post-migration step wipes the newly created dmx dir. There is no clean callback that is called after this step that the plugin can implement to eg move the migrated data from a tmp dir to its final location.
Describe the solution you'd like
I don't have a strong idea for a solution. One option is that plugins can register a list of additional files and dirs (maybe an optional callback for the migration behaviour) that are not deleted in the post-migration step.
Describe alternatives you've considered
Alternative could be an optional migration callback that is executed after rabbit_khepri:khepri_db_migration_post_enable/0 that the plugins can implement to move the migrated data from a tmp dir to its final location.
A workaround could be that the community plugin stores its data under one of the dirs which are not deleted, but this is a hack. The plugin data does not belong there.
Additional context
No response
The text was updated successfully, but these errors were encountered:
A set of patterns under khepri.migration.delete_protected_path_patterns should do. Together with a way to exclude certain patterns in https://github.com/rabbitmq/khepri_mnesia_migration, in all likelihood.
Is your feature request related to a problem? Please describe.
As the last step of migrating to Khepri (ie enabling the
khepri_db
feature flag) all Mnesia related files are deleted (https://github.com/rabbitmq/rabbitmq-server/blob/main/deps/rabbit/src/rabbit_khepri.erl#L1469-L1480) However the heuristic to find Mnesia related files is too eager, it deletes everything in the data dir recursively except for those which are known to be not Mnesia (ie msg_stores, coordination, quorum, stream and rabbitmq_metadata dirs are not deleted).This is an issue for community plugins which want to migrate away from Mnesia into a new subdir. (They might not even use Khepri, or use Khepri but a different store id.) As an example (and the motivation of this ticket) the delayed message store is planned to store its leveldb data in a
dmx
subdir (https://github.com/rabbitmq/rabbitmq-delayed-message-exchange/pull/253/files#diff-64860364dca47a85f9e9fc932a30c53a07673f78e50ebc2a622e64bf78e91ce2R41-R42). After the delayed message plugin nicely migrated its messages to a new storage backend, the post-migration step wipes the newly createddmx
dir. There is no clean callback that is called after this step that the plugin can implement to eg move the migrated data from a tmp dir to its final location.Describe the solution you'd like
I don't have a strong idea for a solution. One option is that plugins can register a list of additional files and dirs (maybe an optional callback for the migration behaviour) that are not deleted in the post-migration step.
Describe alternatives you've considered
Alternative could be an optional migration callback that is executed after
rabbit_khepri:khepri_db_migration_post_enable/0
that the plugins can implement to move the migrated data from a tmp dir to its final location.A workaround could be that the community plugin stores its data under one of the dirs which are not deleted, but this is a hack. The plugin data does not belong there.
Additional context
No response
The text was updated successfully, but these errors were encountered: