CDR Records gone??

Hello,

Can you please tell what are the values you currently have for "Maximum date range" and "Keep CDR records for" settings under System Management - System Settings - Preferences?

THey are both set for 1 year as they have been since we installed this system back in 7.0 NN days a year ago.

We have the data in a backup taken just before then end of the 31st day, which has all the records that were purged.

we have the ability to put them back in the database, but not sure of a simple msyql import would mess us the system. Please send instructions as to importing that data back into the tables required.

My guess is that there is a bug in the system, or something during the updgrade which was on thursday evening changed a setting somewhere that is NOT reflected in the gui.??

So, I just figured out that "Keep records for" "1 year" means that once the database is that old it removes it and starts over... this is not acceptable for billing purposes. It appears that we brought this system up one year ago.

Seems to me that if "max records" or Keep CDRs setting is one year it should trim off the tail end by a month rather than just remove the whole thing. Good think I currently don't use the CDR records to bill customers.

I do, however, have customers who look at these things. so, please if there is a way to import the records back into the database.

I tried to replicate your settings and everything worked as it should for me. Only recordings older that one year were removed from CDR table.

Can you execute yum list pbxmw-* command on your system and show the output?

And about restoring items from backup. Can you tell in what form you have them stored (mysql dump, csv file, ...)?

Doug, it should trim the tail end and get rid of all the records older than the period specified - so something is wrong.

Could you please give us the backup to look at? Ideally you could give Volodya access to your system - please send access info to volodya at thirdlane.com

Let's understand how CDR records are implemented, we have our own reasons to export and import CDR records... , I'll figure out how allow Volodya access and email him, but please give us answers to the questions here:

the setting for MAX Date range was and is still set at 1 year
The setting for "Keep CDR records for" was 1 year, now is unlimited

How often does it trim records? or is there a setting for it to trim at (N-weeks,N-months)

Here is the output Velodya asked for: :

root@pbx ~ # yum list pbxmw-*
Loaded plugins: fastestmirror, priorities
Loading mirror speeds from cached hostfile
* base: mirror.trouble-free.net
* epel: mirror.cs.princeton.edu
* extras: repos-va.psychz.net
* thirdlane: mirror-us.thirdlane.com
* updates: mirror.team-cymru.org
189 packages excluded due to repository priority protections
Installed Packages
pbxmw-mt.noarch 8.0.3.9-11.el6 @thirdlane
Available Packages
pbxmw-st.noarch 8.0.3.9-11.el6 thirdlane
--------------------------------------------------------------------------------

Here are the type of backup we have for MySQL:

As for the backups we have MySQL dumps. I have isolated the INSERT statements
for the missing log entries and I'm planning to just pipe them into the MySQL
command.

We need to know if it's safe *in general* to delete/insert items from the cdr
table. We might want to implement our own custom log purging script for
instance.

Thanks,

yes, its best to stop asterisk before importing your CDR back in just to avoid any issues but otherwise you can simply import those rows and asterisk will be none the wiser when you start it back up.

I would stay away from doing any inserts or updates to any tables thirdlane uses and especially the ones written by Asterisk, including cdr - you can copy the tables if needed and build whatever reporting or analytics you need using the copy.

For cdr and queuelog we allow pointing Aserisk to one database server for writing cdr and queuelogs, and pointing Communications Manager to another server for reporting. This allows you to optimize access and also modify data in your reporting source if needed. The only reason we did not make this a default is that we did not want to force customers to have 2 mysql servers. My general advice - unless you keep your cdr and queue log tables "short", you should limit reporting that uses these tables directly.