[prev in list] [next in list] [prev in thread] [next in thread] 

List:       freeradius-users
Subject:    mysql failover on freeradius8.1 solved
From:       Jeremy Kusnetz <JKusnetz () nrtc ! org>
Date:       2002-12-30 18:11:06
[Download RAW message or body]

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.



[prev in list] [next in list] [prev in thread] [next in thread]