In the spirit of giving back I would like to report some preliminary findings.
A2billing v2.2
Asterisk v13
CentOS v7
Mariadb v10.1 running as a Galera cluster
Add:
Code:
innodb_flush_log_at_trx_commit = 0
To /etc/my.cnf.d/server.cnf
Galera cluster running on Mariadb v10.1 seems to get the job done. It is relatively easy to setup. 3 A2billing servers all running as masters separated by about 30ms ping time from each other. You need to install or convert all your A2billing database tables from MyISAM to InnoDB. I have installed as InnoDB from scratch and tried converting a standard install already using MyISAM and it seems to work either way without a hitch
The one major problem I ran into was importing ratecards via the GUI on the cluster. It was impractically slow. No amount of Galera and InnoDB optimization makes any significant improvement. Maybe about 200-400 rows per minute is about as fast as it gets. Even on a LAN it is slow so it is a code issue due to INNODB and/or Galera cluster rather than because of the WAN speed.
Make sure to set "innodb_flush_log_at_trx_commit = 0" (or 2) otherwise it will be extremely slow. That takes care of one issue that you will see even if just running INNODB with no Galera cluster. The other change requires a code change to /admin/Public/CC_ratecard_import_analyze.php. The problem is that commits are done for every line in the rate card which apparently is a very slow operation on Galera. What I did was create a loop so that commits are only done every 1000 lines. It's actually quite easy with the Adodb abstraction layer that A2billing uses. Just add $DBHandle->StartTrans(); at the beginning of the loop and only use $DBHandle->CompleteTrans(); every 1000 lines. That increased the speed hundreds of times to where it was close to what it would be on a standalone database.
My A2billing servers are nothing special. VPS servers with 1GB RAM and 2 CPU cores. Just some basic MySQL optimization. I followed guidelines for optimizing Galera for WAN links and did some of the basic InnoDB optimizations. Chatter between the masters is not bandwidth intensive even under heavy load.