Challenges with Streams on Clusters with RAM node

[Raguckas86]

Hi Community,

When you are creating a stream and If you have five nodes cluster when one of the five nodes is witness node/Ram node.
You obviously don't want that steam would be landing on RAM node. How you can prevent this of happening?

Is there any other architectural challenges that you have noticed?

[acogoluegnes]

A stream will always persist its data to disk, whatever the type of node. RAM/disk node is only about metadata (definition of exchanges, queues, bindings, users, etc.) Note there is no real reason to use RAM nodes, you should stick to disk nodes for the whole cluster most of the time.

[Raguckas86]

I have very limited 3rd site so to hold quorum in a 5 node clusters I'm running these nodes as a RAM node to have more efficiently there. For that reason I don't want any RabbitMQ object to land on this witness/ram node. So long story short. I can't run all my witnesses nodes as disk nodes. So is there any chance that when I'm creating a stream it won't land and it won't create replicas on my witness node?

[acogoluegnes]

You can use the x-initial-cluster-size queue argument when creating the stream with AMQP or initial-cluster-size with the stream protocol to control how many rabbit nodes the initial stream cluster should span. Unfortunately this does not guarantee that the stream will not have a member on your "witness" node.

[Raguckas86]

Thanks, I need to redesign my clusters then :)