[asterisk-users] Pointers to replace astdb

[Tilghman Lesher]

On Monday 08 September 2008 23:00:50 Steve Edwards wrote:
> On Mon, 8 Sep 2008, Tilghman Lesher wrote:
> > On Monday 08 September 2008 12:43:53 Nguyen wrote:
> >> Hi listers,
> >>
> >> We want to implement one call center with asterisk. The idea is it
> >> should be scalable, with openser as an dispatcher and bunch of asterisk
> >> servers to do ACD, Queues, Agents things... Easy to say :(
> >>
> >> Look closely to the current asterisk, we do see some problem:
> >>
> >> - SIP registrations was stored in astdb.
> >> - And queue members also was stored in astdb.
> >> - ...
> >>
> >> asterisk was built as standalone PBX, so it's understandable.
> >>
> >> Is it time to replace astdb with something like MySQL, so all asterisk
> >> boxes in cluster can have identical access to all the informations,
> >> devstates, etc...?
> >>
> >> Our first thought is replacing the astdb implementation, currently with
> >> DB1, with MySQL. app_dbodbc is a hint, but there are still many things
> >> to consider: concurrency access from many box to same row, performance
> >> issues, ...
> >>
> >> We need your pointers here. Where are the caveats? Is it the correct way
> >> to start add clustering capabilities to asterisk?
> >>
> >> Your replies are much appreciated,
> >
> > There are some very major issues with trying to replace astdb with any
> > other backend.  One possibility which has been floated is to replace the
> > DB1 implementation with sqlite, as the backend is still a Berkeley
> > database, while having the advantages of a SQL interface layer.  An
> > implementation has been coded, though we've held off on committing such a
> > change until we have the ability to convert an old db1-based database to
> > a sqlite-based database.
> >
> > I would highly recommend, though, that you do not attempt to replace db1
> > with MySQL for this purpose.  There are some higher level databases where
> > it may make good sense to go with MySQL as your backend (such as for
> > Realtime database maintenance), but astdb is most certainly not one of
> > them.
>
> Why?

Because.

(I really hate one word questions.)

If you've ever seen what happens when MySQL is unable to write to disk or when
MySQL tables become corrupted, or any of the other things that can and do go
wrong with MySQL databases, the answer is fairly obvious:  because it will
majorly hose every app built on top of it.

Compare that with DB1 or sqlite, and you'll find that such problems are
avoided in every way possible.  I have NEVER come across a corrupted DB1
database, though I've seen more than my fair share of corrupted MySQL
tables and MySQL instances that inexplicably freeze when something goes
wrong.

-- 
Tilghman