[asterisk-users] Write Asterisk CDR MySQL records to multiple servers

Eric Chamberlain eric at rf.com
Thu Sep 11 15:47:19 CDT 2008


On Sep 10, 2008, at 7:11 PM, Tilghman Lesher wrote:

> On Wednesday 10 September 2008 19:55:15 Eric Chamberlain wrote:
>> On Sep 10, 2008, at 2:01 PM, Tilghman Lesher wrote:
>>> On Wednesday 10 September 2008 13:22:51 Ricardo Melendez wrote:
>>>> Hi to all, I actually have an asterisk server configured to write
>>>> CDR mysql
>>>> records in the same machine (localhost), but I want to write this
>>>> records
>>>> to another machine also in mysql  at the same time, It is possible?
>>>> It
>>>> means that I want save the records in both machines.
>>>
>>> You can either use MySQL replication or you can use 2 different CDR
>>> drivers at
>>> the same time, such as ODBC, with the Mysql-ODBC-Connector and the
>>> MySQL CDR
>>> driver.  Also, in 1.6, cdr_adaptive_odbc allows you to specify
>>> multiple CDR
>>> backends within the same configuration file.
>>
>> Are there any sample config's explaining how to setup
>> cdr_adaptive_odbc?  Is cdr_adaptive_odbc used with cdr.conf?   
>> cdr.conf
>> makes no mention of how to use cdr_adaptive_odbc, yet
>> cdr_adaptive_odbc.com doesn't explain how to set things like  
>> usegmtime
>> or loguniqueid.
>
> I thought that the sample cdr_adaptive_odbc.conf was rather clear, but
> apparently not.  The point of this module is to allow you log  
> whatever you
> like in terms of the CDR variables.  Do you want to log uniqueid?   
> Then simply
> ensure that your table has that column.  If you don't want the  
> column, ensure
> that it does not exist in the table structure.  If you'd like to  
> call uniqueid
> something else in your table, simply provide an alias in the  
> configuration
> file that maps the standard CDR field name (uniqueid) to whatever  
> column
> name you like.  Perhaps you'd like some extra CDR values logged that  
> aren't
> in the standard repertoire of CDR variables (some that come to mind  
> are
> certain values used for LCR:  route, per_minute_cost, and  
> per_minute_price).
> Simply set those CDR variables in your dialplan, i.e.  
> Set(CDR(route)=27),
> ensure that a corresponding column exists in your table, and  
> cdr_adaptive_odbc
> will do the rest.
>
> I do agree that I have overlooked gmtime as a possible setting for  
> datetime
> fields in cdr_adaptive_odbc, and that's probably something that I  
> need to add.
> However, I think that the method by which specifying which columns  
> you'd like
> to have is certainly much more intuitive than the old "These are  
> your columns.
> You must have them, or all CDRs will fail" approach.  Hopefully, you  
> will also
> see what I think is a rather innovative approach to CDRs and wonder  
> how you
> ever got along without it.  In fact, the adaptive approach has been  
> now ported
> to most of the other CDR drivers, including mysql, postgres, and  
> sqlite, and
> another developer (who is more familiar with that API) is working on  
> TDS
> support.
>

Thanks for the explanation, it is clear now.  The confusing part for a  
first time ODBC user is weeding all the old unneeded cruft.

Does cdr_adaptive_odbc have any support for spooling records while a  
database connection may be down?

--
Eric Chamberlain










More information about the asterisk-users mailing list