FusionPBX with Mysql

I would advise you not to use mysql, the developer has stated, if he has not done it already, that going forward there will be features that are dependent upon postgres.
Are you sure about that? He only said he is not testing MySQL anymore is my understanding. I have it working nicely on MySQL.

Also, the default OS is Debian and Debian 9 now uses MariaDB (MySQL) by default. So there is a bit of a conflict there where the default OS is going in one direction and he is going in another.
 
Last edited:
Why would MySQL be preferable to PostgreSQL anyway? FusionPBX will install it all for you - and even take backups of that database? If you want to add some integrations, every language has PostgreSQL (be sure to integrate against custom views, not against the tables directly!)
 
Why would MySQL be preferable to PostgreSQL anyway? FusionPBX will install it all for you - and even take backups of that database? If you want to add some integrations, every language has PostgreSQL (be sure to integrate against custom views, not against the tables directly!)
FusionPBX doesn't install it for you. I guess I lot of people use the script. I prefer doing it all myself so that I am more in tune with what is going on. Installing it is not the problem. I just prefer working with MariaDB, and clustering MariaDB 10 is quite easy.
 
I am talking about all the things you have to do after you install it if you don't use the script
I have limited knowledge of BDR but a decent amount of experience with Galera. As I understand it the same kinds of schema modifications (specifically, primary key requirements) will be necessary whether you use BDR or Galera in order to prevent replication collisions.
 
I have limited knowledge of BDR but a decent amount of experience with Galera. As I understand it the same kinds of schema modifications (specifically, primary key requirements) will be necessary whether you use BDR or Galera in order to prevent replication collisions.
It's a mesh. So every node talks to every other node and treats them the same. Galera doesn't really work like that. Galera could probably scale a lot better but not an issue if you are only doing 2 or 3. I don't see anything in the BDR documentation about quorum. Galera needs 3 for proper operation because of quorom. BDR doesn't say and I spent quite a bit of time looking.

I would much prefer to use Galera myself. I think it's a big mistake to not support MariaDB. Debian 9 uses that by default. I think a lot of people are moving to MariaDB. From a development point of view, you will find more people familiar with MariaDB, myself included. That is an often overlooked consideration for open source.
 
Last edited:

DigitalDaz

Administrator
Staff member
I'm sure every database would be supported if the project had the resources to do it. The current Postgres/BDR method has been in use now in production since at least early 2015 and has served everyone well.

I know postgres brings other things to the table for example, autovacuuming, uuid, json and jsonb datatypes etc.
 
I'm sure every database would be supported if the project had the resources to do it. The current Postgres/BDR method has been in use now in production since at least early 2015 and has served everyone well.

I know postgres brings other things to the table for example, autovacuuming, uuid, json and jsonb datatypes etc.
Are you running BDR with only 2 nodes? I am trying to figure out if 2 nodes is considered adequate or if it risks a split brain situation typical of master-master setups. I could not find anything in the documentation about that.

Usually master-master needs at least 3 nodes to avoid the potiential for split brain.
 

DigitalDaz

Administrator
Staff member
Its sort of not an issue.

I only ever use one GUI to edit things, everything that gets done that isn't in the gui, is fine anyway.

Really the only database stuff that gets done at the PBX level is inserting CDRs and they have a UUID as the primary key.