Over the years, every now and again I get asked “what is the point of supporting QoS 1 or 2 in MQTT without full persistence?” I drew up this table a while back to help answer that question.
First a reminder of MQTT definitions of reliability of QoS:
- 0 – at most once (fire and forget)
- 1 – at least once
- 2 – once only
| Error Situation | No Persistence | Persistence | Communications errors: broken connection from whatever cause (intermittent signals e.g. over wireless, hardware problem, etc) | All QoSs apply with any persistence (will hold to their reliability criteria). | All QoSs apply with any persistence (will hold to their reliability criteria). |
|---|---|---|
| Power failure to remote host machine (bridge connection) | All QoSs apply with any persistence (will hold to their reliability criteria). | All QoSs apply with any persistence (will hold to their reliability criteria). |
| Power failure to local host machine | All in-progress messages lost. Retained messages and subscriptions lost | Shutdown persistence: all state since last restart lost. Full persistence: full protection for all QoSs, as long as all persistence store write caching is turned off, both in the operating system and in the hardware. Otherwise, data can still be lost |
| Filesystem corruption | All state lost | All state lost. Normal persistence will not help. Raid or other disk mirroring needed |
| Hard drive failure | All state lost | All state lost. Normal persistence will not help. Raid or other disk mirroring needed |
| Complete system destruction | All state lost | All state lost. Normal persistence will not help. Mirroring to another system needed |
| Destruction of location | All state lost | All state lost. Normal persistence will not help. Mirroring to system in remote location needed |
| End of the world or universe | All state lost | All state lost. Normal persistence will not help. Remote location needs to be on another planet or in another universe |
