I thought that the option to fail to a local file was being deprecated, but looks like I was thinking of SQLRecoveryFile but AcctFailedLogFileName does the job.
The MySQL accounting can add quite a bit of processing to Radiator I believe, so I prefer Radius focus on authentication and accounting for optimal performance. The DB logging can be done as and when. An LNS with 100,000 users crashing seems to put quite a bit of load on the Radius servers. :) Jim. On 18/10/2011 18:37, Michael wrote: > > Hi Jim, > > I log my accounting directly into MySQL systems. radiator supports > failover sql hosts, so you can fail over to multiple sql systems and > have these systems configured to slave to each other. > > But besides that redundancy, radiator also supports the option to fail > to a file on the local disk if sql activity fails, and that can be > imported if the time comes. so, you still don't loose data. > > Essentially 2 levels of redundancy. You could use just one, or both. > > > Michael > > > On 11-10-18 11:25 AM, Jim Tyrrell wrote: >> I use MySQL for monthly accounting with approx 100 million rows per >> month and 12 months retention and its very usable, less than 1 second to >> pull back a users records for the month. I don't have Radiator log >> directly to the MySQL though, I have it log the accounting to a file and >> have a script continually running and importing that file into the >> database which means we don't lose data if the server is offline, or >> impact Radiator performance if the DB has performance issues. >> >> The MySQL log server hardware isn't anything special, so I'm sure you >> could scale to far bigger databases than ours with some decent CPU, RAM >> and storage. >> >> Jim. >> >> >> >> On 17/10/2011 18:35, Michael wrote: >>> I use monthly tables for sql accounting. works good for me. >>> >>> ie. AccountingTable `acct_%f%g` for the AuthSQL >>> >>> So, as the month changes, radiator starts to insert into a different >>> table. Of course, you have to have these tables created before the >>> month starts. A quick script and a cron job handles this to make >>> sure the tables are created a few months ahead of time. Also makes >>> it easy to rotate out and archive old data (ie. old sql tables). >>> >>> >>> Michael >>> >>> >>> >>> >>> On 11-10-17 05:43 AM, Leigh Porter wrote: >>>> I agree that any SQL solution for storing accounting and logs is >>>> somewhat crazy when you get a little busy. We store up to one weeks >>>> accounting logs in an SQL database for billing and customer care >>>> but all other logs (i.e. data retention for law enforcement) are >>>> stored as gzip text files in a hierarchical directory tree on a NFS >>>> mount. It makes searching a bit time consuming, but scripts do all >>>> the work for us. >>>> >>>> I’ll have a look at Mongo though as it would be handy to be able to >>>> index say the IP addresses.. >>>> >>>> -- >>>> >>>> Leigh Porter >>>> >>>> *From:*[email protected] >>>> [mailto:[email protected]] *On Behalf Of *Mike Puchol >>>> *Sent:* 17 October 2011 10:17 >>>> *To:* [email protected] >>>> *Subject:* [RADIATOR] NoSQL databases support >>>> >>>> Greetings, >>>> >>>> I have started looking into NoSQL solutions (mentioned in a recent >>>> thread) for storage of accounting data& other logging details, as >>>> storing them in SQL is wasting space and ending up with huge tables >>>> that take eons to sift through. >>>> >>>> My choice so far is MongoDB, and here is some info on Perl >>>> driver& tools to support it: >>>> >>>> http://www.mongodb.org/display/DOCS/Perl+Language+Center >>>> >>>> I'd like to share experiences with anyone trying to go this route too. >>>> >>>> Cheers, >>>> >>>> Mike >>>> >>>> >>>> ______________________________________________________________________ >>>> This email has been scanned by the MessageLabs Email Security System. >>>> For more information please visit http://www.messagelabs.com/email >>>> ______________________________________________________________________ >>>> >>>> >>>> _______________________________________________ >>>> radiator mailing list >>>> [email protected] >>>> http://www.open.com.au/mailman/listinfo/radiator >>> _______________________________________________ >>> radiator mailing list >>> [email protected] >>> http://www.open.com.au/mailman/listinfo/radiator >> >> _______________________________________________ >> radiator mailing list >> [email protected] >> http://www.open.com.au/mailman/listinfo/radiator >> >> _______________________________________________ radiator mailing list [email protected] http://www.open.com.au/mailman/listinfo/radiator
