[RADIATOR] NoSQL databases support

Wed Oct 19 11:04:35 CDT 2011

I think it is being deprecated.  I use it though. If the code gets removed, i'll just patch it myself for my purpose.  it's a good idea. it saves the exact sql query that failed, rather than the accounting data that would need to be parsed separately. one issue I found with it, is that the code uses the sql service itself to quote the sql string, so if the sql service is down, it will fail to quote the string, therefore fail with the dump to file process.  I patched it to still dump the sql string even if the quote query fails. so you can simply dump this file into the sql server (mysql db -u user -ppass <file) since it contains the exact sql queries.

As for your LNS crashing, not fun when that happens.  When it does, you loose all the Stop packets for all current sessions on that LNS, included all the usage data that of all the current sessions.  Not good in a usage billing environment although I don't agree with usage billing myself, I do track usage just for fun.  I maintain a 'whois online' sql table that is constantly updated with Alive packets so if an LNS crashes, most of that usage is there in that table and can be used to inject Stop packets on behalf of the crashed LNS, so the usage is recovered, and a 'Stop' packet is logged and shows the nas failure.

To each his own though, as the saying goes.

Michael

On 11-10-19 03:37 AM, Jim Tyrrell wrote:
> 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
>>>
>>>
>
>
>