On Sun, Aug 3, 2008 at 6:19 PM, Steve Totaro <[EMAIL PROTECTED]> 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. _______________________________________________ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- AstriCon 2008 - September 22 - 25 Phoenix, Arizona Register Now: http://www.astricon.net asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
