Hi Alan Thanks. We are also stuck with an SQL-based DB at the moment because this links to a CRM system which links to a billing system which links to…. Etc. So a backend Galera cluster makes sense (although Redis does make MUCH more sense). WAN bandwidth between the two sites is not an issue (dark fibre) so the answer for now is probably to have the RADIUS servers as main and backup and then have everything in one place. The highest number will ever get to that need IP allocation all-at-once is about 8,000 clients (that is in the event of site failure all clients rehoming to the second site) so we’re not going to be hitting any limited in terms of system performance. Looks like I need to build HAProxy or ProxySQL to hide the multi-master and then direct both my NASes through one RADIUS server for now. (Any preferences for HAProxy vs ProxySQL?) Thanks! David On 28/09/2026, 15:19, "Alan DeKok" <alan.dekok@inkbridge.io> wrote: On Sep 28, 2026, at 6:44 AM, David Lake via Freeradius-Users <freeradius-users@lists.freeradius.org<mailto:freeradius-users@lists.freeradius.org>> wrote:
I’ve read quite a lot saying that one node in the Galera cluster should be for all writes and then read from all three nodes. For example:
The issue overall is that multi-master database writes are problematic. Database store data, and don't know how to merge conflicting writes. In contrast, applications know how to merge conflicting writes. For example the RADIUS server knows the meaning of accounting data. So if it gets an accounting packet, it can correctly merge that data into a pre-existing row. SQL databases can't do this automatically. Which is why if you need multi-master SQL, you can shard the data on a key. Each key then maps to only one SQL DB, so there's only one master, and multi-master issues are avoided.
Do you think this is the best thing to do or should I direct the NAS to one FreeRadius as main and the other as backup?
I wish I could split the IP pools more sensibly between the two sites (I have a LOT of /32 routes!) but at the moment, I can’t…
We've had good luck with splitting IP pools. But if you can't do that, use a clustered Redis solution. We've also had good luck with that. i.e. don't use two SQL databases. They're "clustered" in that you can talk to both of them, but if the docs say you should use only one master, then it's not really a cluster. In contrast, a Redis cluster solution will do sharding behind the scenes. When FreeRADIUS tries to write an IP address, the cluster protocol will tell FreeRADIUS which server to use. This all happens automatically. We've managed to get 100K IPs per second out of a 6 node redis cluster. And that isn't the limit of what Redis can do. Given your limitations on IPs, your only real choice is a centralized IP assignment system. This could be multiple RADIUS servers talking to the same cluster, or the NASes sending all of their packets to one RADIUS server. Alan DeKok.