[asterisk-dev] The New CDR system

Leif Madsen leif.madsen at asteriskdocs.org
Sun Apr 1 09:34:53 MST 2007


On Sunday 01 April 2007 09:58:41 Steve Totaro wrote:
> Leif Madsen wrote:
> > On Saturday 31 March 2007 17:37:30 zoachien at securax.org wrote:
> >> Steve Totaro wrote:
> >>> Vasil Kolev wrote:
> >>>> 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)
> >>>
> >>> 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.
> >
> > It doesn't need to be very complex, and most of this probably is handled
> > by having a multi-master replicated database setup (with PostgreSQL, this
> > basically means Slony-II or pgcluster).
> >
> > The only thing that would really need to be added would be the ability to
> > say, "hey, write to this database, but if its not available, write to the
> > secondary one". This is done in func_odbc by having more than one
> > writehandle which references two separate connections in res_odbc.
> >
> > Other than that, the rest of the "live backup" stuff is handled by the
> > database backend -- not by Asterisk as Steve was alluding to.
> >
> > Leif Madsen.
>
> Leif,
>
> I was alluding to no connectivity to the database whatsoever in which
> case, Asterisk would write to a rotating log file to be parsed later.
> It is kind of difficult for the database backend to handle anything if
> it not reachable.

Gotcha. That makes sense. Or I guess it could be stored in AstDB somehow as 
that is also available beyond a restart.

Leif Madsen.


More information about the asterisk-dev mailing list