[Questions] Khepri features disable after import ?

[deeway]

Community Support Policy

• I have read RabbitMQ's Community Support Policy
• I run RabbitMQ 4.x, the only series currently covered by community support
• I promise to provide all relevant information (versions, logs from all nodes, rabbitmq-diagnostics output, detailed reproduction steps)

RabbitMQ version used

4.1.4

Erlang version used

27.3.x

Operating system (distribution) used

Ubuntu 24.04

How is RabbitMQ deployed?

Debian package

rabbitmq-diagnostics status output

See https://www.rabbitmq.com/docs/cli to learn how to use rabbitmq-diagnostics

Status of node rabbit@svqal1202 ... Runtime

OS PID: 2283259
OS: Linux
Uptime (seconds): 226794
Is under maintenance?: false
RabbitMQ version: 4.1.4
RabbitMQ release series support status: see https://www.rabbitmq.com/release-information
Node name: rabbit@svqal1202
Erlang configuration: Erlang/OTP 27 [erts-15.2.7.3] [source] [64-bit] [smp:240:2] [ds:240:2:10] [async-threads:1] [jit:ns]
Crypto library: OpenSSL 3.0.13 30 Jan 2024
Erlang processes: 780 used, 1048576 limit
Scheduler run queue: 1
Cluster heartbeat timeout (net_ticktime): 60

Plugins

Enabled plugin file: /etc/rabbitmq/enabled_plugins
Enabled plugins:

• rabbitmq_management
• rabbitmq_management_agent
• rabbitmq_web_dispatch
• amqp_client
• cowboy
• oauth2_client
• jose

Data directory

Node data directory: /rabbitmq_data/khepri/rabbit@svqal1202
Raft data directory: /rabbitmq_data/khepri/rabbit@svqal1202/quorum/rabbit@svqal1202

Config files

• /etc/rabbitmq/advanced.config
• /etc/rabbitmq/rabbitmq.conf

Log file(s)

• /rabbitmq_data/logs/[email protected]

Alarms

(none)

Tags

(none)

Memory

Total memory used: 0.3212 gb
Calculation strategy: rss
Memory high watermark setting: 0.6 of available memory, computed to: 3.668 gb

allocated_unused: 0.2463 gb (55.82 %)
other_system: 0.13 gb (29.46 %)
other_proc: 0.0233 gb (5.27 %)
code: 0.0231 gb (5.23 %)
metrics: 0.0068 gb (1.53 %)
quorum_queue_procs: 0.0049 gb (1.12 %)
plugins: 0.0027 gb (0.62 %)
quorum_ets: 0.0023 gb (0.52 %)
mgmt_db: 0.002 gb (0.45 %)
mnesia: 0.0015 gb (0.34 %)
msg_index: 0.0012 gb (0.26 %)
atom: 0.0011 gb (0.25 %)
binary: 0.0002 gb (0.06 %)
metadata_store: 0.0 gb (0.01 %)
connection_other: 0.0 gb (0.01 %)
queue_procs: 0.0 gb (0.01 %)
metadata_store_ets: 0.0 gb (0.0 %)
quorum_queue_dlx_procs: 0.0 gb (0.0 %)
stream_queue_procs: 0.0 gb (0.0 %)
stream_queue_replica_reader_procs: 0.0 gb (0.0 %)
connection_readers: 0.0 gb (0.0 %)
connection_writers: 0.0 gb (0.0 %)
connection_channels: 0.0 gb (0.0 %)
stream_queue_coordinator_procs: 0.0 gb (0.0 %)
reserved_unallocated: 0.0 gb (0.0 %)
other_ets: -0.0042 gb (-0.96 %)

File Descriptors

Total: 0, limit: 32671

Free Disk Space

Low free disk space watermark: 0.05 gb
Free disk space: 49.8161 gb

Totals

Connection count: 0
Queue count: 78
Virtual host count: 1

Listeners

Interface: 0.0.0.0, port: 15672, protocol: http, purpose: HTTP API
Interface: [::], port: 25672, protocol: clustering, purpose: inter-node and CLI tool communication
Interface: 0.0.0.0, port: 5672, protocol: amqp, purpose: AMQP 0-9-1 and AMQP 1.0

Logs from node 1 (with sensitive values edited out)

See https://www.rabbitmq.com/docs/logging to learn how to collect logs

2025-11-03 08:20:53.194860+00:00 [warning] <0.10092828.0> Deprecated features: `management_metrics_collection`: Feature `management_metrics_collection` is deprecated. 2025-11-03 08:20:53.194860+00:00 [warning] <0.10092828.0> By default, this feature can still be used for now. 2025-11-03 08:20:53.194860+00:00 [warning] <0.10092828.0> Its use will not be permitted by default in a future minor RabbitMQ version and the feature will be removed from a future major RabbitMQ version; actual versions to be determined. 2025-11-03 08:20:53.194860+00:00 [warning] <0.10092828.0> To continue using this feature when it is not permitted by default, set the following parameter in your configuration: 2025-11-03 08:20:53.194860+00:00 [warning] <0.10092828.0> "deprecated_features.permit.management_metrics_collection = true" 2025-11-03 08:20:53.194860+00:00 [warning] <0.10092828.0> To test RabbitMQ as if the feature was removed, set this in your configuration: 2025-11-03 08:20:53.194860+00:00 [warning] <0.10092828.0> "deprecated_features.permit.management_metrics_collection = false"

Logs from node 2 (if applicable, with sensitive values edited out)

See https://www.rabbitmq.com/docs/logging to learn how to collect logs

# PASTE LOG HERE, BETWEEN BACKTICKS

Logs from node 3 (if applicable, with sensitive values edited out)

See https://www.rabbitmq.com/docs/logging to learn how to collect logs

# PASTE LOG HERE, BETWEEN BACKTICKS

rabbitmq.conf

See https://www.rabbitmq.com/docs/configure#config-location to learn how to find rabbitmq.conf file location

######################################## # 🐇 Configuration de base ########################################

########################################

🌐 Réseau

########################################

Port AMQP standard

listeners.tcp.default = 5672

########################################

🧩 Plugins

########################################

Activer le plugin de gestion

management.listener.port = 15672
management.listener.ip = 0.0.0.0

########################################

🧩 SSL

########################################

#listeners.ssl.default = 5671
#ssl_options.cacertfile = /etc/rabbitmq/ssl/cacert.pem
#ssl_options.certfile = /etc/rabbitmq/ssl/cert.pem
#ssl_options.keyfile = /etc/rabbitmq/ssl/key.pem
ssl_options.verify = verify_none
#ssl_options.fail_if_no_peer_cert = true

########################################

🔐 Sécurité

########################################

Utilisateur par défaut (à changer en prod)

#default_user = admin
#default_pass = admin

Global log level

log.file.level = info

Category-specific levels

#log.file.formatter.level_format=
log.exchange = true
log.exchange.level = warning
#log.queue.level = warning
#log.queuei.file = true

Console output settings (useful for containers)

log.console = true
log.console.level = warning

Steps to deploy RabbitMQ cluster

No cluster / standalone mode

Steps to reproduce the behavior in question

Make an export from old rabbitmq (3.9)
Make an import on new rabbitmq (4.1) with khepri features enabled

advanced.config

See https://www.rabbitmq.com/docs/configure#config-location to learn how to find advanced.config file location

[ {rabbit, [ {database, khepri} ]} ].

Application code

# PASTE CODE HERE, BETWEEN BACKTICKS

Kubernetes deployment file

# Relevant parts of K8S deployment that demonstrate how RabbitMQ is deployed
# PASTE YAML HERE, BETWEEN BACKTICKS

What problem are you trying to solve?

Follow this link :https://www.rabbitmq.com/docs/definitions#export-and-transform-definitions

I don't understand, on my last discussion : #14862, khepri features was enabled and after an import/export i saw "khepri_db" fetaures to disabled state ??

today :
root@svqal1202:/rabbitmq_data/logs# rabbitmq-diagnostics metadata_store_status
Status of metadata store on node rabbit@svqal1202 ...
lqqqqqqqqqqqqqqqqk
x Metadata Store x
tqqqqqqqqqqqqqqqqu
x mnesia x
mqqqqqqqqqqqqqqqqj

My last actions from friday were to move data folder to another disk and import definitions from an old rabbitmq server to this one.

thanks for your help

[mkuratczyk]

It's not possible to disable Khepri once it was enabled. By moving the data around, you must have effectively reset the node (you lost the data and the node you are running now is basically a fresh node, which has never had Khepri enabled)

[deeway]

Even if the configuration files were set to use khepri ?
i revert all my configuration and restart a fresh install on rabbitmq 4.2. I'll keep you in touch.

[mkuratczyk]

The decision whether to use Mnesia or Khepri is based on the feature flags, not the configuration file.
Again - it's not possible to disable Khepri, once it was enabled. Therefore, since you somehow have Mnesia enabled now,
this means you effectively lost your previous node/state. This is a new node/cluster which just happens to have the same name as the old one.

In the startup logs, you'll probably find DB: virgin node -> run peer discovery which means this node believes it's a fresh deployment. You moved the files somewhere, where RabbitMQ didn't look for them. No files from the previous run -> fresh deployment (and therefore the default metadata store, unless feature flags say otherwise).

[deeway]

Maybe a hint, when i follow the step on this tutorial : https://myupbeat.wordpress.com/2014/02/07/chaging-rabbitmq-mnesia-database-location/ in order to change the data folder location, i used the cli "rabbitmqctl reset" command.
Reset will revert all changes on a node/cluster ?

found this explanation on another webpage :
"rabbitmqctl stop_app
rabbitmqctl reset
rabbitmqctl start_app

You must stop the server to use this command, restarting once complete. The broker drops all virtual hosts, queues, exchanges, and non-administrative users. RabbitMQ attempts to gracefully exit without damaging an existing cluster or broker, returning to a virgin state"

I don't remember if i check with the metadata_store_status after rebooting the service :/

[mkuratczyk]

rabbitmqctl reset completely erases all data

[deeway]

This explains it, i learn a lot of things during this last week, it's a great pleasure to discuss about this topic with you. Thanks to share your time and answer to my questions

[deeway]

Installation and import on a fresh 4.2 server is ok
khepri is still enabled
i have my old configuration without any json modification after import
I moved data and log folder inside a second disk (without reset command this time :) )

All good, i learned from my fails.

[michaelklishin]

Note that the Clustering guide's manual clustering doc section was updated to not use rabbitmqctl reset any more because it is NOT required in 4.1.0 and later versions with Khepri.