Message Persistence: Persistent and Durable modes

XMQ stores persistent client sessions, subscriptions, retained messages, and undelivered QoS 1 and QoS 2 messages in Redis. The Persistence screen offers two modes. Both preserve stored state across an XMQ restart while Redis remains available; they differ in when XMQ acknowledges a publish and how Redis writes its data to disk.

Redis is a separate service. XMQ changes its runtime persistence settings when applying a mode, then saves those settings to the Redis configuration file. Redis itself does not restart. These settings apply to the entire Redis server, including every database and application using that server, not only XMQ or the database number in XMQ's URI. Use a Redis instance dedicated to XMQ if other workloads need different persistence settings. Redis must allowCONFIG SET and CONFIG REWRITE; applying the mode is rejected if Redis cannot accept or save the requested configuration.

Persistent mode: XMQ uses a 10 ms write-behind window and disables Redis AOF to avoid its added write latency. max_queued_writes defaults to 1000 and bounds queued delivery writes; when the queue fills, publishers pause until Redis catches up. A publisher can receive its acknowledgement before Redis stores the corresponding record. Recovery after a Redis restart depends on RDB snapshots; with RDB disabled, Redis restart loses its data.

Durable mode: XMQ enables AOF with appendfsync always and waits for Redis to confirm a local AOF fsync before sending successful publish acknowledgements. This protects acknowledged writes against an ordinary Redis process restart while its disk and AOF remain intact. It does not protect against loss or corruption of the Redis host, disk, or storage controller; this mode does not wait for another Redis instance to persist a replica copy.

What happens on failure

Durable mode's guarantee depends on the operating system, filesystem, controller, and drive honoring fsync. A failure before XMQ returns a successful MQTT acknowledgement is not a confirmed delivery; clients should retry as their QoS flow requires. Because the outcome can be ambiguous, retries can produce duplicates. Redis persistence is not a substitute for backups or a tested high-availability design.

Switching modes

Choose Persistent or Durable on the XMQ Persistence screen and apply the change. XMQ checks that Redis is writable and can save its configuration, updates Redis's AOF settings, saves XMQ's settings, and restarts the MQTT service. MQTT clients disconnect during that broker restart. Redis does not restart. Persistent setsappendonly no; Durable sets appendonly yes andappendfsync always. If Redis is shared, this switch changes its persistence behavior for all its clients.

In Persistent mode, a full max_queued_writes window pauses publishers until Redis catches up. The default is 1000. At 60,000 messages per second, 1000 messages represent about 17 ms of incoming traffic; this is a rough rate conversion, not a guaranteed time bound when Redis slows down. A value of zero is reserved for Durable mode in the interface.

Performance

Persistent mode is intended for the low-latency write-behind path. Durable mode adds a local fsync barrier to successful acknowledgements, so its throughput and latency depend on the Redis disk and workload. We accepted thePoint-To-Point-60K-persistence performance testwithout a performance regression for the tested configuration; that result does not guarantee the same numbers on other Redis hosts or storage devices.

Redis availability

If Redis is unavailable when XMQ starts, XMQ logs the error and can continue with in-memory storage. In that state, session and message persistence is unavailable. Check the broker log and Redis connection before relying on persistence.