CQv2 vs CQv1 - way to verify?

48 views
Skip to first unread message

Tina

unread,
Apr 19, 2024, 5:36:13 PMApr 19
to rabbitm...@googlegroups.com
We're upgrading our RMQ to the latest patch release of 3.12, and likely to 3.13.  We have existing classic queues and have configured the setting in rabbitmq.conf (via the RabbitMQCluster definition in k8s) to set its default version to 2, which will apparently apply to all new queues.  The question then becomes verifying the queue version for existing queues.  Is there a way to query or verify for such?

Things tried, all of which just show the queue type as "classic":
- rabbitmqctl list_queues
- rabbitmqctl export_definitions
- curling api/definitions
- curling api/queues

Tina


jo...@cloudamqp.com

unread,
Apr 19, 2024, 11:08:46 PMApr 19
to rabbitmq-users
In 3.13.x they should all show using the HTTP API.
If you want to be super sure, check that there are no .idx files and that the file .queue_name contains "INDEX : v2". Example:

/var/lib/rabbitmq/mnesia/rabbit@server-name-01/msg_stores/vhosts/VHOSTHASH/queues/QUEUEHASH$ cat .queue_name
VHOST: vhostname1
QUEUE: queuename1
INDEX: v2

/Johan

Tina Coleman

unread,
Apr 20, 2024, 9:16:21 AMApr 20
to rabbitmq-users
Confirmed, thank you: in 3.13.x, queues retrieved via the HTTP API have a storage_version attribute with values of either 1 or 2.

I tested with a set of queues generated via a topology operator.  Info about them is available through HTTP API, including the storage_version attribute, but of the ~30 queues established, only the one where I'd set the version explicitly as an argument as v2 had a ".queue_name" file and none had ".idx" files.  So leading folks toward the HTTP API as their indicator.



Reply all
Reply to author
Forward
0 new messages