[asterisk-users] 2000+ user Asterisk PBX

[Grey Man]

On Sun, Aug 3, 2008 at 6:19 PM, Steve Totaro
<stotaro at totarotechnologies.com> wrote:
> Curious why you stay with postgres then, and not go with MySQL if you
> know in advance it is a problem and will bite you sometime?

The other IT truism, it's not easy to change a production system. In
our case we have a lot of business logic that hits the database for
call credit checks, user account management, provisioning etc. etc.
Have we used any SQL in that code that would break if switched from
Postgresql to MySQL... probably not but we'd have to check and
validate...

> You way want to look at extconig.conf and ODBC or whatever database
> driver and even hook up to a MSSQL cluster.  While not inexpensive, it
> is is mission critical.  If you can monetize one hour of downtime and
> then figure the MTBF (including all the pieces) and how long ot
> trouble shoot and get it back up, maybe that is worth quite a bit of
> money.  If you can just say "sorry, we were upgrading" and the cost is
> only time, then that certainly dictates your direction.

We use ODBC and extconfig.conf already and you're correct that from
our Asterisk servers point of view we could switch to another database
backend easily.

There's no big reason that would stop us switching from Postgresql to
MySQL or MSSQL to gain better fault tolerance but there are lots of
little ones:

- We have 4 years of effort and expertise invested in configuring and
optimising the nuts and bolts of Postgresql and our underlying
hardware which would be a lot to throw away.

- Our database load is high enough that we wouldn't be able to just
throw up a stock standard server and get away with it anymore. We use
a dedicated fiber channel storage array hanging off a SunFire 4200 and
I get nervous enough whenever change is mentioned in its vicinity so
switching database products would be a big deal.

- Most of our Asterisk servers are still 1.2 (the transfer CDR bugs
prevent us from upgrading at this point) and if a 1.2 Asterisk server
loses it's realtime ODBC connection you have to restart it anyway so
even if your database fails over automatically you still lose the in
progress calls when you restart Asterisk (maybe this could be overcome
with some form of MySQL load balancer but then that's another thing
that could fail). Asterisk 1.4 has fixed that problem and will
automatically try and re-connect if it loses its ODBC connection
taking advantage of automatic database failover,

- An automatic fail over solution for Postgresql has always seemed
just around the corner (SLONY has been around for ages but just never
quite got there),

- Our current failover situation is not that bad and our DBA can fail
over to our secondary Postgresql databse at the flick of a switch i.e.
30 seconds post alert notification (we use the Postgresql archive log
shipping to keep our secondary db in sync with our primary so that
it's only ever a second or so behind). When coupled with the fact that
we'd have to restart our Asterisk 1.2 servers anyway we wouldn't gain
a tremendous amount by reducing those 30 seconds to say 1 second with
a MySQL master/salve mechanism.

Don't get me wrong I'd much prefer to have a situation where the
database and Asterisk servers could failover automatically and would
highly recommend anyone designing a system from scratch put that at
the top of their list!

Regards,

Greyman.