My Review of MySQL High Availability

Originally submitted at O’Reilly

Server bottlenecks and failures are a fact of life in any database deployment, but they don’t have to bring everything to a halt. MySQL provides several features that can protect you from outages, whether you’re running directly on the hardware, on virtual machines, or in the cloud. This…

Good coverage of MySQL and replication

By sjmudd from Madrid, Spain on 11/24/2010
4out of 5

Pros: Easy to understand, Accurate, Well-written, Concise, Helpful examples

Best Uses: Intermediate, Expert

Describe Yourself: Sys Admin, Database Administrator

I work in quite a large site and found the book full of useful tips of things to do, and ways to do them in order to achieve the title’s goal of MySQL High Availability.

To be honest the book should really be called “MySQL and replication in large environments” but that does not sound so exciting.

There’s less information on performance tuning and more on working with a large replicated setup. That’s fine: it fits my needs and will certainly fit others too.

It’s also interesting to note how the authors solve many problems by writing wrapper routines around MySQL and the required replication procedures. That’s done in python which is fine but most of the routines I have written with shell scripts or perl. Again if you are looking at the technique the implementation language does not really matter. Oracle should really take note and come up with some standard routines to make more of these tasks doable the same way by everyone. That makes all DBA or sysadmins lives’ easier.

So the book was full of good tips and procedures and is certainly worth the read.


BlueBox GUI for FreeSWITCH looks very promising

(NOTE: If you’ve come here from my apologies. I’ve notified them to only follow my database related posts and hope they’ll not follow my full blog feed shortly.)

I recently came across a new site which offers a GUI configuration tool for FreeSWITCH.

Despite buying the FreeSWITCH 1.0.6 Book which is a very good read and playing a bit with the config files I’ve not found hand editing the native xml configuration files that intuitive.  This is probably because I don’t have enough spare time now to look at these things or participate in the freeswitch mailing list.

Anyway, I found BlueBox which seems to solve this nicely. The project seems quite new but as far as I can see the interface and usability is pretty good. This is basically similar to something like trixbox for Asterisk. Bluebox make things easy by providing a downloadable custom install image based on CentOS 5 and that gives you an empty PBX. While things are not yet quite working for me it does seem quite easy to add extensions (devices), trunks (gateways for calling outside) and then configure behaviour of voicemail, and for example whether you record incoming or outgoing calls. So this is nice, certainly nicer than doing this all by hand. However, it’s not quite working yet so I need to do further investigation to see why. Probably a mistake my end, a misunderstanding of the required input data or similar.

This project looks quite new and I have seen a couple of issues so far:

  • I attempted to install bluebox on vmware. Thinking this is just a PBX I only gave the vmware guest 512 MB of RAM. This was too little as I see that FreePBX uses 235 MB, Apache nearly 330 MB and MySQL (which stores the configuration) 240 MB. For a SOHO setup like mine that seems a lot.  Configuring the guest with 512MB does make the GUI a bit sluggish which is not helpful so I hope that bluebox will at least state the requirements more clearly and if possible figure out how to reduce the memory footprint (my current Asterisk setup uses 500MB with 80MB resident but the OS has plenty of memory spare).
  • Perhaps not surprisingly many PBX systems like this provide a default set of routes which look normal when used in your own country. The problem is the world is not as simple as this, or consistent with it’s numbering, so if you live somewhere else all these helpful initial routes are useless and you need to build your own. I’ve put in a ticket which is intended to address this for bluebox and give optional routes if based in Spain where I live.  Hopefully, the bluebox people will accept this and people who live in other countries can supply equivalent routes, thus making the initial configuration simpler for newbies like me. See BLUEBOX-221.
  • It’s possible to define more than one route to the same destination via different trunks. Currently it doesn’t seem possible to prioritise which of these should take preference though you can define that if a route fails to try another one. I’d like to see a way to prioritise the order in this case as one route may be less reliable but cheaper and so a good first choice option to try.

I’m sure these issues will get addressed one way or another and must admit to a very good first impression of Bluebox. I’m hoping to clear up my current mis-configurations shortly and thus be able to test behaviour and see how things go. Hopefully this will also allow me to look at the generated configuration files and see better how to configure FreeSWITCH in the future.
I’ll let you know how I get on.

Updated: 2010-11-13

Other thoughts which come to mind are:

  • The bad thing about GUIs is that debugging problems means the person reporting the problem needs to describe the problem very well, or better still provide screen shots of what is going on. Bluebox is going to have the same issue. I’d suggest that if possible some debug option is possible which will at least save the configuration and logging (excluding password information) so that people who are trying to help can see what is going on.  This certainly helped the MySQL support people who had to help me debugging several Merlin problems.
  • I believe the bluebox configuration is completely stored in the database. That’s good as it potentially allows more flexibility. One thing I notice from the current configuration is the configuration generation uses names like location_1, sipinterface_1, trunk_1, etc.  These names are logical from the point of view of the configuration generator, but not from the point of view of someone looking at their own code. So I’d suggest that for many of the configuration options like Trunks, SIP Interfaces, Locations etc that it’s possible to provide an “identifier type name” which if provided would substitute the less readable default tags. This perhaps requires a bit of work but would help someone trying to understand their configuration files.
  • The URL to adjust your location bluebox/index.php/locationmanager/edit/n provides fields for “Location name” and “Domain Name”. It might be clearer to and label this Domain Name/Realm which is what is shown in bluebox/index.php/locationmanager/index. See BLUBOX-224.