Hello,
After updating to the newest version 4.7 is the redis database still needed?
Planning to run a new instance in another region connected to the main PostgreSQL DB but do I also need to connect the new instance to the main redis DB ?
Yes.
You may also want to consider colocating your data with your LNS for reasons of latency, reliability, and business.
2 Likes
Thank you for your quick response,
The main reason we would like to have one Central database is that devices can roaming on different Regions without being configured on each server separately. For example All EU devices are connected on EU server with the Gateway Bridge and ChirpStack for 868.
And US on a separate server running US Gateway Bridge and ChirpStack.
But both running on same Main Database on a specific Server.
Follow up question to this. After 4.7 the device session were moved to Postgres. Does this mean I do not require persistance anymore? Or are there any other keys which need to be persisted over restarts?
2 Likes
Good question.
It should still be used for the latest session keys for fast retrieval?
Redis persistence is certainly less critical now. Please note that there is still some (less critical) state stored in Redis. For example gateway and device metrics… So I would still recommend you backup Redis periodically as well.
4 Likes
to be sure, because in our case we think about switching from azure managed redis with persistence (premium) to the tier w/o persistence (standard). This means azure will restart redis for example once a month for security patches automatically and there is no easy way to use a backup after that (because you should pay for persistence 
).
is the main downside that in such a case ADR is not working correctly because history is missing? and missing details for debugging sensor connection issues e.g.? This would be ok if its only once in month in our case
The uplink history for ADR is stored in the device-session. However, the device <> gateway link (Class-B / C) is still stored in Redis. This link will be recovered as soon as a device sends a new uplink. As well the temp. state of pending mac-commands is (still) stored in Redis.
1 Like
what is the outcome of losing pending mac-command states? That a mac command is sent out to often (retry with next uplink) or it will be forgotten in such a case?
And “(still)” means that it is planned to be moved to DB as well and if so with which version? 
1 Like
In most cases this is recoverable, but I believe this could cause an issue for some mac-commands, in which case the device continues sending an ack until it receives a downlink (resulting again in an error). I do not have this on the roadmap, but it might be a good idea to move this state into the device-session. That way everything is at one place (and in PostgreSQL).
4 Likes
Does this only relate to mac-commands which need to be acked by the device (ConfirmedDown)? If we only have UnconfirmedDown frames we could drop our persistent Redis?
Correct. However, you still need Redis in any case. It is still being used for metrics + providing the live Events / LoRaWAN frames (using the Redis Stream feature).
You mean the Live Event/Frame view in the Chirpstack UI?
In our case its mainly about dropping the very expensive Redis persistence feature ( = Premium tier in Azure). its totally fine to use Redis, because we also use Redis as caching layer.
Yes, that is correct.
1 Like