Does this appear to be primarily due to 4.4 using PGSQL v10, or doe sit appear to be something in 4.4 actually breaks the clustering? (I saw you mention something about possibly something in 'callcenter' breaking the clustering)
I suspect it is not. I took a peek at the BDR project (which does the PgSQL master-master replication) and BDR v1.0 currently only runs on PgSQL 9.4. The roadmap mentions BDR v2.0 which runs on PgSQL 9.6, and the future seems to be BDR v3.0 which should support PgSQL v10+, but I cannot (yet) determine the availability or stability of either v2.0 or v3.0
My test FusionPBX install (running 4.4) has PgSQL v10 installed. For a fail-over cluster, we are probably going to have to run 4.2 for now, *possibly* 4.3 (depending what version PgSQL FusionPBX installs). I think there was someone earlier in this thread who said they were able to upgrade their cluster nodes to 4.3 and it was still working.
Since this is something I am interested in, I am *probably* going to spin up a couple VMs on my laptop andf do some testing. Depending on whether or not FusionPBX 4.4 *must* run on PgSQL 10 or if it can run on 9.4 still, that could be the determining factor.
One thing I want to try is maybe running most of the commands in the scripts manually and try to figure out *what* doesn't work on 4.4. It *might* just be something relatively simple that can then be updated in the scripts to automate the process moving forward. Again, it will depend on whether or not FusionPBX *requires* PgSQL 10 or if it got installed because that just happens to be the latest-and-greatest version. I guess the part of the scripts that install FusionPBX will tell the tail
I just want to clarify why the script doesn't work.
Changes were made between versions that caused the existing script to fail, thats it, no biggie, the script could relatively easily be made to work with 4.4 on Postgres 9.4, in fact I have a couple of clusters running exactly this way.
The reason I haven't updated the script is that the idea was never to provide a full blown cluster to a bunch of leeches who wanted to take all and contribute nothing.
With a handful of exceptions, that is exactly what happened.
Anyone with reasonable skill and knowledge can fix the script or make it much better even.
Anyone who wants to try this on the older version it will work with, you do so at your peril. That version will be receiving no security updates so you are putting all your clients at risk.
OK, so FusionPBX 4.4 *will* run on PgSQL 9.4, then, which is good to know (meaning the PgSQL 10 that was on my test box was likely due to that version just being the latest and greatest available to Debian at the time). In that case, I am probably going to run the script on my two test systems I just spun up but make sure that it installs 4.2 and make sure everything works from there (and also familiarise myself with how it does what, etc.)
Once I have done that, I see two possible paths:
Upgrade the systems through the FusionPBX GUI to bring them up to 4.4 (and see if any thing breaks, and attempt to fix if so)
Start fresh, but do all the steps in the script manually to find out where it doesn't work, fix it, and (ideally) fix the script
It will probably be a bit of time to do that, maybe a couple weeks at least, but I am up for the challenge. Getting a working clustered system is worth it to replace our aged (single server) Elastix system
Just to update, I have had a chance to play around with this a bit. I setup a 2-node cluster and installed the 4.2 branch. After setting things up more or less how we have them on our current system and making sure all was working as expected, I ran through the steps of upgrading from 4.2 to 4.4 as outlined here .
I did the same testing I did earlier and everything seems to be working just fine. FusionPBX is indicating it is running 4.4.1. There are no errors in the Log Viewer. The ony thing was in Step 6 in the upgrade steps it said there would be blank duplicate entries in the "Email" section under "Advanced -> Default Settings" but I found none; just the settings I had previously in there.
I did the version upgrade steps on both PBXes.
So, to confirm, installing a cluster using the scripts (but forcing it to be v4.2) then following the steps to upgrade from version 4.2 to 4.4 *does* appear to work.
I haven't testing doing a straight-up install of 4.4 by running the commands in the scripts manually (so I can figure out what needs to be adjusted/fixed), but I *suspect* it is the part that installs the database, and making sure it is PgSQL 9.4 that gets installed and not an updated version. I am not sure when I will get a chance to do that (aiming for soon), but I just wanted to report back here on the results on my 4.2->4.4 cluster upgrade.
I hope this helps someone.
Oh, one other thing: after I finished the upgrade, I did reboot both my PBXes, and I ended up having to actually reboot my phone for it to re-register (I waited about 2 mins but it never seemed to retry). I probbaly didn't have to reboot the PBXes, but I usually like to do that after an upgrade anyway. I probably *should* have rebooted my primary PBX first, then my secondary when the first came back up; worst-case, the phone would have registered on PBX2 when PBX1 went down, then re-registered back on PBX1 when PBX2 went down. Lessons learned
I have one Cluster installed by following this procedure. But everytime I add a new extension, an Error related to memcached appears on fs_cli console. What could be done to solve this issue? Best Regards
I supressed some IP and credentials info on following logs
Thanks so much! Yeah it makes sense but this issue was happening when deleting the extension itself. I think i found the cause of it. I am not sure. I disabled ipv6 on both nodes and the memcached errors logs is not appearing anymore. Weird, isnt it?
I spent years working on this and teach how to do it in the FusionPBX Advanced Training. With this training you get the easy way to set this up and how to make two or more servers work together. This class is updated often as its refined more. This is the purpose of the Continuing Education training to review the improvements and retake the training as needed.
I run a relatively small business with business partners. Investment in the engine is absolutely on the cards and Ive been exploring the potential of reselling fusion and therefore would easily expect it to become a more corporate relationship with yourself. Weve had a rough time with a client you helped us with (Branding etc a year ago) and are now out the other side it swallowed nearly a year of our time as we also do IT support.
We have spent 6 months working with a another client who just wanted the basics and because you made Fusion so stable it just runs itself in AWS on 1 node . This pays for some support staff who can easily manage the basics of Fusion like setting up users and using all the apps.
We now have a new client who is much more substantial (Enterprise potential in many countries). This is going ahead and they will be onboarding hundreds if not thousands of business’s up to 100 users per Domain/ (They are using MICLOUD for above these numbers).
This is where the money will come from to get me on an admin course and invest in further development (I believe there is a developers course also i can send someone else on) Im more then happy to give back to Fusion once we are feeding our kids off it!
With that in mind a constant reminder of the courses on this site may be useful. To be honest ive gotton used the great community here that love yours and the contributers baby!
Do you know when the next Advanced course is or please add a thread to the forum. Also when a developer course will be sceduled.