Last week I posted about a problem with mysql configurable failover with freeradius 8.1
I think I solved my problem, but the solution may point to a bug on how database connections are handled. Initially I had failover set in the authorize section, but not the accounting section. Since mysql replication only work one direction, I didn't want accounting data going to the slave. The problem with this though is at first I could authenticate, but accounting data was contiually being sent to radius. Since I didn't have a failover for that, all the database handles soon seemed to fill up, and radius would no longer respond even to authorization requests. I started getting this in debug: rlm_sql (sql1): Ignoring unconnected handle rlm_sql (sql1): Ignoring unconnected handle rlm_sql (sql1): Ignoring unconnected handle rlm_sql (sql1): Ignoring unconnected handle rlm_sql (sql1): Ignoring unconnected handle rlm_sql (sql1): Ignoring unconnected handle rlm_sql (sql1): Ignoring unconnected handle rlm_sql (sql1): Ignoring unconnected handle rlm_sql (sql1): Ignoring unconnected handle rlm_sql (sql1): Ignoring unconnected handle rlm_sql (sql1): There are no DB handles to use! modcall[accounting]: module "sql1" returns fail modcall: group accounting returns fail Finished request 30 Going to the next request My solution was to create another radacct table on my secondary sql server so I could setup failover for accounting. Now things seem to be working nicely. I just need to come up with a way of migrating any accounting data going to the slave back to the master. But should radius act this way? Should lack of database handles for accounting, prevent authorization from being able to fail over to the next sql server? As a matter of fact, radius no longer seems to respond at all to authorization requests, it seems to lock up once all the database handles are gone. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
