RE: sql returns fail for some stop requests
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. (all unclosed sessions are within this time frame) This is easy to fix, but I'm looking for a way to make a fail-safe solution. There can always be occasions where DB connection is momentarily slow due to some other issue like network or storage, 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, possibly keeping a buffer of accounting data to be written when DB access is restored? I am currently considering two possible solitions: Create a fail over for sql to allow login if sql is n/a, Similar to: redundant { sql ok } and/or use buffered-sql to catch these queries and update them in sql at later time. Is it possible to use buffered-sql and still perform simultaneous use checks based on same DB? Thanks for all replies, Amir.
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.
On 24 Jul 2012, at 14:24, Alan DeKok wrote:
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.
Use SQL replication to transfer the records to another system and backup from that. Do not perform intensive queries on a live system. It also sounds like you might be using MyISAM for radacct, if you are convert it to InnoDB ASAP. Yes you can use buffered SQL to protection against temporary DB outages. But only for Accounting. Don't try this on 2.1x branch, use 3.0 if you want something that actually works reliably... Yes you can use redundant to fail open or closed, but its simpler to just: sql { fail = 1 } if (fail) { update control { Auth-Type := 'Accept' } } or if (fail) { reject } -Arran
On 24 Jul 2012, at 18:18, Arran Cudbard-Bell wrote:
On 24 Jul 2012, at 14:24, Alan DeKok wrote:
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.
Use SQL replication to transfer the records to another system and backup from that. Do not perform intensive queries on a live system. It also sounds like you might be using MyISAM for radacct, if you are convert it to InnoDB ASAP.
Yes you can use buffered SQL to protection against temporary DB outages. But only for Accounting. Don't try this on 2.1x branch, use 3.0 if you want something that actually works reliably...
Yes you can use redundant to fail open or closed, but its simpler to just:
Um and redundant { sql ok } Wouldn't work...
participants (3)
-
Alan DeKok -
Amir Tal -
Arran Cudbard-Bell