[RADIATOR] NoSQL databases support

Jim Tyrrell jim at scusting.com
Wed Oct 19 02:37:47 CDT 2011


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:*radiator-bounces at open.com.au 
>>>> [mailto:radiator-bounces at open.com.au] *On Behalf Of *Mike Puchol
>>>> *Sent:* 17 October 2011 10:17
>>>> *To:* radiator at open.com.au
>>>> *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
>>>> radiator at open.com.au
>>>> http://www.open.com.au/mailman/listinfo/radiator
>>> _______________________________________________
>>> radiator mailing list
>>> radiator at open.com.au
>>> http://www.open.com.au/mailman/listinfo/radiator
>>
>> _______________________________________________
>> radiator mailing list
>> radiator at open.com.au
>> http://www.open.com.au/mailman/listinfo/radiator
>>
>>



More information about the radiator mailing list