asterisk users - Mar 2008 - replace astdb with a cluster-capable sql database engine

I've been searching the Internet for information
regarding the replacement of astdb with a modern sql
engine.

There are several reasons one would like to do this.
First of all, external applications have a hard time
reading/writing to the now-old astdb format.
Also (and this is what interests me most), the sql
astdb could easily be clustered throughout several
servers (I'm looking for a master-master MySQL
2-server cluster solution).

Asterisk has brought up Realtime which is very
powerful but, correct me if I'm wrong, it still
requires astdb internally. In other words, if I call
Set(DB) in the dialplan then it will always be using
astdb regardless of realtime.

Some projects like Callweaver have forked from
Asterisk 1.2 and replaced astdb with sqlite.

I'm wondering if Asterisk has plans to allow the user
to choose the astdb backend: standard db1, sqlite,
MySQL (which I would use with nbcluster for my
clustering purposes), Postgresql with Slony-II,
PGcluster, etc.

Or is it already possible?

There has been some talk on this before:
http://lists.digium.com/pipermail/asterisk-dev/2004-December/007846.html

Also, the func_odbc feature seems to be very powerful:
http://www.asteriskpbx.org/func_odbc
but:
1) would there be potential issues with db handles on
a very busy asterisk system after a relatively long
run time?
2) would there be a way to "map" the odbc function(s)
to the DB functions (Set(DB), read and write, DBdel,
etc) so that rewriting the whole dialplan would not be
necessary? (that's the whole point of defining a
different astdb "backend")

If there are known
problems/issues/projects/alternatives then please let
me know.

Thanks




     
____________________________________________________________________________________
Be a better friend, newshound, and 
know-it-all with Yahoo! Mobile.  Try it now. 
http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ

Vieri,

What values are you looking to move from astdb?

I have used realtime to store values for call features and other
functions in the dial plan. I'm curious what you are looking to do.

On Sat, Mar 8, 2008 at 12:01 PM, Vieri <rentorbuy at yahoo.com>
wrote:
> I've been searching the Internet for information
>  regarding the replacement of astdb with a modern sql
>  engine.
>
>  There are several reasons one would like to do this.
>  First of all, external applications have a hard time
>  reading/writing to the now-old astdb format.
>  Also (and this is what interests me most), the sql
>  astdb could easily be clustered throughout several
>  servers (I'm looking for a master-master MySQL
>  2-server cluster solution).
>
>  Asterisk has brought up Realtime which is very
>  powerful but, correct me if I'm wrong, it still
>  requires astdb internally. In other words, if I call
>  Set(DB) in the dialplan then it will always be using
>  astdb regardless of realtime.
>
>  Some projects like Callweaver have forked from
>  Asterisk 1.2 and replaced astdb with sqlite.
>
>  I'm wondering if Asterisk has plans to allow the user
>  to choose the astdb backend: standard db1, sqlite,
>  MySQL (which I would use with nbcluster for my
>  clustering purposes), Postgresql with Slony-II,
>  PGcluster, etc.
>
>  Or is it already possible?
>
>  There has been some talk on this before:
>  http://lists.digium.com/pipermail/asterisk-dev/2004-December/007846.html
>
>  Also, the func_odbc feature seems to be very powerful:
>  http://www.asteriskpbx.org/func_odbc
>  but:
>  1) would there be potential issues with db handles on
>  a very busy asterisk system after a relatively long
>  run time?
>  2) would there be a way to "map" the odbc function(s)
>  to the DB functions (Set(DB), read and write, DBdel,
>  etc) so that rewriting the whole dialplan would not be
>  necessary? (that's the whole point of defining a
>  different astdb "backend")
>
>  If there are known
>  problems/issues/projects/alternatives then please let
>  me know.
>
>  Thanks
>
>
>
>
>      
____________________________________________________________________________________
>  Be a better friend, newshound, and
>  know-it-all with Yahoo! Mobile.  Try it now. 
http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ
>
>
>  _______________________________________________
>  -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>
>  asterisk-users mailing list
>  To UNSUBSCRIBE or update options visit:
>    http://lists.digium.com/mailman/listinfo/asterisk-users
>


-- 
*****************************
Bruce Reeves, dCAp
EUS Networks
Office: 212-624-5943
Web: www.euscorp.com
****************************

On 3/8/08, Vieri <rentorbuy at yahoo.com> wrote:
> I've been searching the Internet for information
>  regarding the replacement of astdb with a modern sql
>  engine.
>
>  There are several reasons one would like to do this.
>  First of all, external applications have a hard time
>  reading/writing to the now-old astdb format.
>  Also (and this is what interests me most), the sql
>  astdb could easily be clustered throughout several
>  servers (I'm looking for a master-master MySQL
>  2-server cluster solution).
>
>  Asterisk has brought up Realtime which is very
>  powerful but, correct me if I'm wrong, it still
>  requires astdb internally. In other words, if I call
>  Set(DB) in the dialplan then it will always be using
>  astdb regardless of realtime.
>
>  Some projects like Callweaver have forked from
>  Asterisk 1.2 and replaced astdb with sqlite.
>
>  I'm wondering if Asterisk has plans to allow the user
>  to choose the astdb backend: standard db1, sqlite,
>  MySQL (which I would use with nbcluster for my
>  clustering purposes), Postgresql with Slony-II,
>  PGcluster, etc.
>
>  Or is it already possible?
>
>  There has been some talk on this before:
>  http://lists.digium.com/pipermail/asterisk-dev/2004-December/007846.html
>
>  Also, the func_odbc feature seems to be very powerful:
>  http://www.asteriskpbx.org/func_odbc
>  but:
>  1) would there be potential issues with db handles on
>  a very busy asterisk system after a relatively long
>  run time?
>  2) would there be a way to "map" the odbc function(s)
>  to the DB functions (Set(DB), read and write, DBdel,
>  etc) so that rewriting the whole dialplan would not be
>  necessary? (that's the whole point of defining a
>  different astdb "backend")
>
>  If there are known
>  problems/issues/projects/alternatives then please let
>  me know.

There are really not much dependencies in asterisk to AstDB. As i
recall - some SIP registration data is stored in AstDB, and persistent
queue members (but you can replace that with Realtime queue members).

For your own custom data you can use Realtime engine - it has INSERT
and DELETE support in 1.6, and it's easily backportable to 1.4 (if
you're interested i can give you working patches). All you have to do
is declare realtime class in extconfig.conf, and then use
Set(REALTIME(....)=...). For more info on this see
http://www.voip-info.org/wiki/index.php?page=Asterisk+func+realtime

Also there's a mysql command in asterisk-addons, but you have keep
track of connections - connect and disconnect in dialplan.

Or there's odbc module that creates permanent connection, and allows
you to declare SQL functions with replacable variables, but personally
i don't like having additional layer. For this you can search
mailinglist, it's been described numerous times.

Regards,
Atis

-- 
Atis Lezdins,
VoIP Project Manager / Developer,
atis at iq-labs.net
Skype: atis.lezdins
Cell Phone: +371 28806004
Cell Phone: +1 800 7300689
Work phone: +1 800 7502835

Would it be possible to modify the API calls that are
currently going to the AstDB code within Asterisk, and
put a translation layer to have them use the func_odbc
instead (or either one)?

I came across some old code of an odbc version of
app_db which I suppose is obsolete.

http://www.voip-info.org/wiki/view/Asterisk+app_dbodbc
http://downloads.netmonks.ca/app_dbodbc.c

At a lower level, for everything Asterisk does to its
AstDB, maybe there could be a system setting which
allows the user to say, ok, use DB, or, no, use
func_odbc (not at the dialplan level).




     
____________________________________________________________________________________
Never miss a thing.  Make Yahoo your home page. 
http://www.yahoo.com/r/hs