Redis Persistence Modes
Redis persistence 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 retain stored state across an XMQ restart while Redis remains available; they differ in when XMQ acknowledges publishes and how Redis persists writes to disk.
Redis is a separate service. XMQ changes Redis persistence settings when a mode is applied, then saves them to the Redis configuration file. Redis itself does not restart. These settings apply to the entire Redis server, including every database and every application using it, not only XMQ or the database number in its URI. Use a Redis instance dedicated to XMQ if other applications need different persistence settings.
| Mode | Redis settings | Behavior |
|---|---|---|
| Persistent | appendonly no | XMQ uses a 10 ms write-behind window. A publisher may receive its acknowledgement before Redis stores the corresponding record. TheMax queued writes default is 1000. When this queue fills, publishers pause until Redis catches up. After a Redis restart, recovery depends on RDB snapshots; without RDB, Redis restart loses its data. |
| Durable | appendonly yes, appendfsync always | XMQ waits for Redis to confirm a local AOF fsync before it sends a successful publish acknowledgement. The interface uses a zero queued-write limit for this mode. |
Redis must permit CONFIG SET and CONFIG REWRITE. XMQ checks that Redis can accept and save the requested settings; if this fails, the mode change is rejected.
Failure guarantees
| Failure | Persistent | Durable |
|---|---|---|
| XMQ process restart | Records already stored in Redis remain available. Writes still queued in XMQ can be lost, bounded by Max queued writes. | A successful acknowledgement waits for local Redis AOF fsync. If no acknowledgement was received, retry according to the MQTT QoS flow; an ambiguous outcome can result in a duplicate. |
| Redis process restart, disk intact | Recovery depends on Redis RDB snapshots because AOF is disabled. | Redis recovers the AOF, including writes confirmed by the local fsync barrier. |
| Redis host or disk loss | Redis data on that host may be lost. | Redis data on that host may be lost. XMQ does not wait for a replica fsync and does not provide replica failover guarantees. |
Durable mode depends on the operating system, filesystem, controller and drive honoring fsync. It protects locally fsynced Redis data against an ordinary Redis process restart while its storage remains intact; it is not a substitute for backups or a tested high-availability design. Persistent mode's queue limit is a count bound, not a fixed time bound when Redis is slow.
If Redis is unavailable when XMQ starts, XMQ logs the connection failure and can continue using in-memory storage. In that state, session and message persistence is unavailable; check the broker log and Redis connection.
Switching modes
Choose Persistent or Durable on the Persistence screen and apply the change. XMQ validates Redis access, updates and saves Redis settings, saves XMQ settings, and restarts the MQTT service. MQTT clients disconnect during the broker restart; Redis itself does not restart. Because Redis settings are server-wide, consider other databases and applications on the same Redis server before switching.