(RADIATOR) MySQL Database went away

[Jose Borges Ferreira]

Hi there!

I have similar need but had a different design:

1) One instance for auth and other for acct is the correct way to go when
you have some load.
2) Have a accounting table per month. Simply use  AccountingTable
accounting_%Y%m combined with a cronjob to create the table every month.
3) Use INSERT DELAYED, instead of regular INSERT ( AddQuery    INSERT
DELAYED INTO accounting_%Y%m ... )
4) Use a DB replica for read only queries. Insert delayed doesn't give you
any advantage if you read allot from that table. Read mysql manual for more
information,


For "selecting" information from the database you can use UNION or VIEWs.


With this setup on 2 quite old dual-PIII 933 GHz with 1GB RAM as DataBase
and 2 dual PIII-733 512MB RAM as front ends i can have about 25 auth/sec and
15 acct/s sustained for 10 hours a day.


José Borges Ferreira

On 3/28/06, Martin Wallner <Martin.Wallner at eunet.co.at> wrote:
>
> Mishair,
>
> I fear you have to use two instances of RADIUS, one bound on the
> Accounting Port and one on the Authenticating Port.
>
> The reason, why you got stuck is, that accounting and authentication
> requests got stuck on the same database connection. Index (rebuild or build)
> tries to be as atomic as possible, so the requests start to queue up towards
> the database...
>
> When you doing two instances of RADIUS, you have one connection from the
> authenticator process to the database (which is generally a nice read-only
> select), and a second one, where the accounting will be handled.
>
> Additionally there are some more ways to time out the database and write
> overflowing Accounting requests (as plain log) to a local disk, which you
> can then integrate in the database by parsing the file (there is such a
> program in the goodies section)....
>
> On a (personal) sidenote: AuthBy SQL-Authentication is good and fun and
> easy to setup, and it performs up to a distinct size of Users (which
> generate a given amount of Accounting Requests on the NAS), but it tends to
> loose performance quickly, when the userbase grows larger and reaches
> sometimes then the 'critical mass', where it starts to get REALLY SLOW  (and
> yes, with the right kind of machine running the DB it does perform, but you
> have to tweak it, pamper it and be very very careful with it...) ... IMHO
> Authentication via LDAP and Accounting on SQL (and then use 2 different
> threads for it) is the way to  get things done easy and 'as out of the box
> as possible'...
>
> =mw=
>
>
>
> ________________________________
>
>         From: owner-radiator at open.com.au [mailto:
> owner-radiator at open.com.au] On Behalf Of Mishari Al-Faris
>         Sent: Dienstag, 28. März 2006 12:52
>         To: radiator at open.com.au
>         Subject: (RADIATOR) MySQL Database went away
>
>
>         Hello All,
>
>         We have 2 Radiators talking to a 3rd server running MySQL to store
> Accounting and Authlog information. Today we saw that our Accounting table
> has grown pretty large and tried to INDEX the table, it had around 11
> million records. This caused the MySQL server to get loaded, however the
> problem was after a little while both our Radius servers stopped processing
> Authentication Requests. When we were first trouble shooting the problem and
> tried restarting radiator it would process a few requests then stop again.
> Only when we killed the INDEX process on the MySQL server did the 2
> radiators continue processing requests.
>
>         Can this behavior be corrected? please direct us in the right
> path. Because we wish that the Radiators do not stop processing requests if
> the Acct/Authlog DB becomes slow or unavailable.
>
>         Many thanks and regards,
>
>
>
> --
> Archive at http://www.open.com.au/archives/radiator/
> Announcements on radiator-announce at open.com.au
> To unsubscribe, email 'majordomo at open.com.au' with
> 'unsubscribe radiator' in the body of the message.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.open.com.au/pipermail/radiator/attachments/20060331/a71dddbc/attachment.html>