Amongst the plethora of MQTT questions, I am wondering what are some alternatives to MQTT for when all messages sent to a topic need to be kept, and in a queue for a new subscriber.
At my company, we have remote deployments that we manage, and we are wanting to use MQTT for local data collection. The idea would be that data would be sent to the local broker onsite (running on a Raspberry Pi, for example), and the broker would have an MQTT bridge with our CloudMQTT deployment. If connectivity would be lost, the messages would collect locally, and synchronize again when connectivity was re-established.
The set up is typical, like this:
For my example, on the left side would be many (around ~100) MQTT local brokers running at each location, and on the right would be the CloudMQTT server we pay for.
When I read the article MQTT Essentials Part 8: Retained Messages, this part was disappointing:
A retained message is a normal MQTT message with the retained flag set to true. The broker stores the last retained message and the corresponding QoS for that topic. Each client that subscribes to a topic pattern that matches the topic of the retained message receives the retained message immediately after they subscribe. The broker stores only one retained message per topic.
Essentially what this means is that there would have to constantly be a subscriber on the CloudMQTT server listening for all incoming events from all of our locations; otherwise, data might be lost.
MQTT seems built to only keep the most recent message; are there any other software packages that can do this local <=> remote syncing, but keep all messages?