When communication with your FreeSWITCH breaks abruptly, it is a common symptom you have what we call zombie calls. A zombie call seems to be listed when you do show channels or show calls command, and it seems to still be using system resources.
Just another beautiful day to have databases issues. This time, I have a beautiful MariaDB Galera Cluster running as a backend of a FreeSWITCH Cluster. It seems that operation does not take a single rest and it is keeping adding new extensions. New extensions mean more calls, which it can be translated to more databases queries and connections.
The issue here is not changing the max_connection value in the database configuration file. The issue, as I see, is that doing that will waste memory that could be used somewhere else. Therefore, the value needs to increased gradually; at some point, this will not be enough and more tunings, including database register cleaning might be done. For now, just let's configure an alert that will tell us when it is a good time to start thinking what to do.
So, if you are a lucky one of having a FusionPBX VoIP cluster and you are sort of paranoid about the availability of your service, you may think about the ultimate countermeasure to mitigate an unavailability risk. Your answer is the deployment of a DRP.
A Disaster Recovery Plan is more than just having an emergency server. But in this article, I will describe just the technical part of deploying this emergency server.
I always deploy my FusionPBX Clusters with a MariaDB Galera cluster on the back. Then, I will write about it.