A2Billing – MySQL Master / Slave and Asterisk load balancing – Part 3

In part1 and part2 of this post we look at setting up Master/Slave MySQL redundancy and also A2Billing load balancing.

In this last post we are going to look at what to do if we need to fail over to the Slave MySQL database we set up in part1. This requires 2 steps –

  • Tell the Slave MySQL is is now the Master
  • Point the Asterisk/A2Billing servers to the Slave (new Master) server

On – change MySQL from a Slave to a Master MySQL server and configure Asterisk/A2Billing to use it

Stop the Slave service running –

mysql -p

Edit /etc/a2billing.conf and tell a2billing to use the local MySQL database –


Edit /etc/asterisk/res_config_mysql.conf and edit the [mya2billing] settings –

dbhost = localhost

Restart MySQL and Asterisk –

service mysqld restart
service asterisk restart

On – Configure Asterisk and A2Billing to use the new MySQL server

Edit /etc/a2billing.conf and tell a2billing to use the local MySQL database –


Edit /etc/asterisk/res_config_mysql.conf and edit the [mya2billing] settings –

dbhost =

Restart Asterisk –

service asterisk restart

Now server2 and server3 should start to work again, using the MySQL database on server2. Server1 will no longer be serving calls obviously (so don’t send any to it – however you are doing that). If server1 comes back in to production it probably makes sense to set it up at the new Slave server, following the instructions in part1.

6 thoughts on “A2Billing – MySQL Master / Slave and Asterisk load balancing – Part 3

  1. Gip

    Definitely what I was looking for. I’am constinuously reading your blog and I’am sure to always find find great information.
    Thank you for sharing. Great job!

  2. Mitja

    It is an old post but it may help….

    What about this way:
    1. Set CARP/VRRP protocol between two BSD/linux boxes for loadbalancing/redundancy
    2. Set mysql master master replication
    3. setup VOIP related software

    CARP/VRRP and mysql master master replication should take care of everything and you have a full redundacy loadbalanced solution

  3. matt Post author

    Hi Mitja

    Thanks for taking the time to reply.

    I think using VRRP would imply that the 2 MySQL servers are on the same subnet? When using hosted servers the most common issue I’ve seen has been provider link issues (normally caused by DDOS attacks or the like) so ideally you would want your 2 MySQL servers in different DCs.

    Also while master/master replication is definitely better than master/slave there is more of a management overhead, and more likelihood of there being issues with the actual replication process. In general I’ve seen some HA solutions cause more issues than they solve (a very generic statement obviously!)

    Definitely though the best solution is putting in place any redundancy that can be tested, and the admin feels comfortable managing.

    Cheers, Matt

  4. Mitja

    Hi Matt,

    Yes, you are right, for VRRP you need L2 but in our case we managed to do it either way.
    Personally I wouldn’t be very excited to run a VOIP service outside our network. I am running a Wireless Service Provider. We have two locations for NOC, connected over wireless network and through internet with GRE tunneling and MPLS VPLS L2, so we can manage to be in the same L2 network. Our challenge was to build a redundant VOIP cluster with servers several kilometers apart. Normally it wouldn’t be so difficult but one of the requirements of our VOIP provider was, to lock all the VOIP traffic for our customers to one single IP. So our solution was:
    1. Two different internet providers in two different places
    2. BGP, so that the single “VOIP” IP could be reachable through both providers
    3. VOIP servers on both locations
    4. Everything connected in L2 with the help of MPLS (for BGP and VRRP)
    5. Database replication master master

    It looks complicated but it is the only solution I could find.

    Regards, Mitja

  5. matt Post author

    Definitely a good solution. I’ve seen something similar done using MPLS elsewhere. Obviously it a fairly specialised solution though. Hopefully in the future there will be an easy way to keep call and presence state across multiple Asterisk servers, with FreePBX taking advantage on that.

    Cheers, Matt

Comments are closed.