[asterisk-dev] The New CDR system
stotaro at totarotechnologies.com
Sat Mar 31 14:22:02 MST 2007
Vasil Kolev wrote:
> В чт, 2007-03-29 в 12:48 -0600, Steve Murphy написа:
>> 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
>> 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?
> 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
> (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.
More information about the asterisk-dev