[asterisk-dev] The New CDR system

[Steve Totaro]

Vasil Kolev wrote:
> В чт, 2007-03-29 в 12:48 -0600, Steve Murphy написа:
>   
>> FYI--
>>
>> I've been collecting all the CDR related bugs. I have a branch,
>> team/murf/bug8221-1.4, where I've been testing out fixes to problems
>> reported.
>> I'm about to clean it up and commit it to 1.4 and trunk.
>>
>> If there's one thing I've concluded, it's that there are some problems
>> with the CDR system, and something different is in order.
>>     
> ....
>   
>> Hate it? Love it? Have suggestions? 
>>
>> murf
>>     
>
> A question that nobody seems to have touched yet on this (and maybe the
> reason is that this is not the right discussion :) ), what about a way
> to specify a backup storage for the CDR data? For example your DB dies,
> and suddenly you can't log it - how does it sound to have another way to
> keep the data and to send it to the primary storage when it becomes
> available?
> (let's face it, everything crashes once in a while, no matter how
> foolproof and redundant it's made)
>
> This might be better implemented in the CDR recording drivers
> themselves, but for some reason a generic layer which can be used to
> define "Send CDRs over pgsql to server1, if fails - pgsql to server2, if
> that fails - record on disk
> in /var/spool/asterisk/cdr/cdr.$TIMESTAMP.$PID" (the pickup of the files
> from the disk is left as an exercise to the sysadmin). This will make it
> a lot harder to lose information :).
>
> As I see it, the logic shouldn't be hard to be designed and implemented,
> although I still haven't dug in the CDR system of asterisk, having been
> busy with some other parts. What do you think of this?
>   
>   
Isn't that what DB clustering (Single Quorum) and RAID are for? 

I suppose a default to write to a rotating log file like queue_log as 
well as DB clustering would be even safe.

Thanks,
Steve

Thanks,
Steve