When you completely blow away the asterisk database (astdb) you actually remove the ability for freepbx to know what it’s doing, eg it references AMPUSER to know how long a call should ring for and what device to call. You should never randomly delete the entire astdb on a production system. The only way to fix this is to go and one by one resubmit and save all extensions. You’ll also have errors in conferences and parking.
So what is the right way to cleanup astdb when its grown to several MB? …in our case, we exported a live system, restored on a fresh install with all trunks disabled and no endpoints registered and the CLI still showed activity for hours.
Is there a way to avoid bringing a possibly bad astdb on a restore?
thank you.
If you know sql syntax then
rasterisk -x ‘database query (your sql query)’
first identify the family with the problem keys and values, then
delete from astdb where . . . .
unfortunately I do not know, nor do I think I can find them. I was looking over a database show and couldnt really folllow it. We will likely rebuild everything. Hopefully it doesnt happen again.
thanks for all the help you’ve provided. It is very much appreciated.
The bits you ‘can’t follow’ are likely the problem, most of the database is relatively easy humanly readable AMPUSER is the FreePBX user Family,
Others are likely
blacklist
CALLTRACE
CF
CONFERENCE
CustomDevstate
CW
DAYNIGHT
DEVICE
DISA
dundi
IAX
pbx
QPENALTY
RECCONF
RG
RINGGROUP
SIP
TC
Perhaps just re-import the AMPUSER and possibly DEVICE family from your backup after recreating the file
1 Like
most looks like plain english, but I havent gone through all of it. It stops changing size after a few hours of no traffic and the size at that point is over 8MB. Either the file also stores some type of history and stats or there is a lot stale/bad data in there since the original freepbx load creates a 400kb file.
The majority seems to be the lower part which is the call information.
I will save the file and see what to do with the info after manually recreating the system.
thank you.
sqlite3 databases dont shrink on their own you have to "VACUUM’ them.
I just tried the vacuum command on the “new” astdb file and it reduced it a few hundred kb. I will later try it on the 8MB file (just for science as I doubt we will be returning to that).
thanks!
for i in $(rasterisk -x 'database show'| cut -d '/' -f2| sort -u|grep -v result);do echo -n "$i : rows = "; rasterisk -x 'database show'|grep $i|wc -l ;done
might be diagnostic for a problematic database
I ran the command on the “clean” astdb (the one that auto recreated itself when i moved the original 8MB problematic one. I cant tell if this one still has the same problems since we moved all the inbound calls to a different machine. This one now only does outbound temporarily.
the results are the following
AMPUSER : rows = 4672
CALLTRACE : rows = 11
CONFERENCE : rows = 1989
CustomDevstate : rows = 62
CW : rows = 44
DEVICE : rows = 224
DND : rows = 227
LASTDIAL : rows = 2
pbx : rows = 1
registrar : rows = 85
RINGGROUP : rows = 2
subscription_persistence : rows = 72
TC : rows = 13
the number of devices seems right. Number of registered (registrar?) seems correct too. The rest I wouldnt know. We do not use conference rooms. That I do know.
thank you.
It would be interesting to compare that with the “broken” one.
rasterisk -x 'database show CONFERENCE'
will show the conferences that were created.
As soon as I get a fully functional PBX back up and running I will return to the previous astdb, run the command and let you know. I also want to try the vacuum command on the that astdb.
that command displays the following
rasterisk -x ‘database show CONFERENCE’
/CONFERENCE/87001/adminpin :
/CONFERENCE/87001/exten : 87001
/CONFERENCE/87001/joinmsg :
/CONFERENCE/87001/language :
/CONFERENCE/87001/music :
/CONFERENCE/87001/options :
/CONFERENCE/87001/timeout : 21600
/CONFERENCE/87001/userpin :
/CONFERENCE/87001/users : 0
/CONFERENCE/87002/adminpin :
/CONFERENCE/87002/exten : 87002
/CONFERENCE/87002/joinmsg :
/CONFERENCE/87002/language :
/CONFERENCE/87002/music :
/CONFERENCE/87002/options :
/CONFERENCE/87002/timeout : 21600
/CONFERENCE/87002/userpin :
/CONFERENCE/87002/users : 0
/CONFERENCE/87010/adminpin :
/CONFERENCE/87010/exten : 87010
/CONFERENCE/87010/joinmsg :
/CONFERENCE/87010/language :
/CONFERENCE/87010/music :
/CONFERENCE/87010/options :
/CONFERENCE/87010/timeout : 21600
/CONFERENCE/87010/userpin :
/CONFERENCE/87010/users : 0
/CONFERENCE/87011/adminpin :
/CONFERENCE/87011/exten : 87011
/CONFERENCE/87011/joinmsg :
/CONFERENCE/87011/language :
/CONFERENCE/87011/music :
/CONFERENCE/87011/options :
/CONFERENCE/87011/timeout : 21600
…
…
…
1989 results found.
could this be related to Asternic and/or FOP2 and call recording/monitoring/queues? For a few hours after renaming the astdb file calls were coming in but nobody could pick them up. Could these have been created then?
thank you.
I dont use asternic, I dont believe it is FOP2
if you dont need or use conferences
database deltree CONFERENCE
I just checked with the asternic people and they said its not related to them. It seems related to this.
Though this machine was installed about 3 months ago with the latest code and this claims to have been fixed in 2017.
I checked on the FreePBX GUI and in the conferences application there are over 700 conference rooms, though we only have a couple hundred extensions (most never used yet, just created).
1 Like
Having conferences on your system isn’t causing the task processor to queue up. Neither is a large amount of data in asterisk database. I really believe you are on a wild goose chase with this and only making your system worse.
1 Like
At this point its just a learning experience and maybe making sure we avoid the problem in the future. I am already rebuilding another machine (different hardware but again virtual) I hope the problem doesnt come back.
thank you.
PS.- The conferences on the system should not have been there though. Though unrelated it might still be a bug.
1 Like
Andrew - can you give any indication what the taskprocessors in question actually do?
This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.