Amir Tal wrote:
After additional debugging the fault seems to be with a rouge backup process running on DB host, causing it to be slow to un-responsive for 10-20 minutes.
Stop that. The database used by the RADIUS server should ONLY be used by the RADIUS server.
This is easy to fix, but I'm looking for a way to make a fail-safe solution.
Don't shut down the database while the RADIUS server is using it.
There can always be occasions where DB connection is momentarily slow due to some other issue like network or storage,
Then the DB isn't that important, is it? I've never understood why people do that with critical systems. They're critical, but NON-critical traffic takes them down. The solution for them is to BUTCHER the critical system, rather than separating it from the non-critical systems.
Since SQL is used here only for accounting data, is there a way to set the radius to accept all users (or reject all) in case DB is not-available,
You do know that accounting is not authentication? Saying "accept all users for accounting" makes no sense.
possibly keeping a buffer of accounting data to be written when DB access is restored?
Stop that. FIX THE SYSTEM SO IT WORKS.
I am currently considering two possible solitions:
No. BOTH solutions are wrong. Fix your SQL database so that it doesn't go down. Fix the network so that it doesn't starve the RADIUS-SQL connection. ADDING complexity to the system means it is LESS stable than before. Alan DeKok.