FusionPBX supports native PostgreSQL's native logical mult-master replication. Whether you're setting up a 2-node or 3-node cluster, or additional nodes for more redundancy.
The FusionPBX project was an early adopter of BDR (Bi-Directional-Replication), and we taught many of you how to use it. 2nd Quadrant's BDR was released in 2016. Over time, around 80 to 90% of BDR was donated as open source and added to PostgreSQL. This new logical multi-master replication is based on that work. When this new logical multi-master replication was released in PostgreSQL 16, the FusionPBX team was one of the first in the open source PBX community to adopt it, learn it, and then we immediately started training people to use it. If you know how to do this newer replication, it's likely you learned directly or indirectly from the FusionPBX project.
This new replication is better than the original BDR in multiple ways. In BDR it would do a snapshot of the entire database and then copy it over to the new node. If the database were large, it could take a while before you saw any data on the new node. The newer native PostgreSQL logical multi-master replication replicates each table separately, and the replication begins immediately.
At first, with this new replication, it took time to realize how to fix all the problems clients were experiencing. However, we have done our time and gained the necessary experience to fix all the issues that our clients have faced up to this point. With the help of our client base, we have accelerated experience-based on real-world demand.
Why Choose a 3-Node Database Cluster?
While a 2-node cluster provides redundancy and failover capabilities, adding a node offers several significant advantages:
1. Fault Tolerance: In a 2-node setup, if one server fails or becomes unavailable, 1 server is left without any remaining redundancy. In a 3-node setup, even if one node fails, the other two nodes can continue to operate without interruption. This ensures that your system remains fully functional, minimizing downtime. Why have a 2-node cluster when you can have the additional peace of mind of a 3-node cluster?
2. Geographical Distribution: A 3-node cluster allows for more flexible geographical distribution of your database servers. You can place nodes in different locations to improve geographic redundancy, enhancing disaster recovery capabilities.
3. Larger Workload A 3-node or larger cluster can handle a larger workload.
The FusionPBX team set up a 3-node cluster for someone last week. It's not our first time, we have done it many times.
Additional 3rd party references as to why you consider more redundancy
- https://www.acronis.com/en/blog/posts/backup-rule/
- https://www.ipmcomputers.com/the-3-2-1-backup-rule-explained-and-why-its-still-relevant-in-2025/
- https://www.impossiblecloud.com/blog/the-golden-rules-of-backup-strategy-from-3-2-1-to-3-2-1-1-0
Even AWS has outages. Recent outage by Cloudflare a company considered by many to be one of the safest recently had a major outage. This further drove the point to those paying attention that more redundancy is a very good thing.
The FusionPBX project was an early adopter of BDR (Bi-Directional-Replication), and we taught many of you how to use it. 2nd Quadrant's BDR was released in 2016. Over time, around 80 to 90% of BDR was donated as open source and added to PostgreSQL. This new logical multi-master replication is based on that work. When this new logical multi-master replication was released in PostgreSQL 16, the FusionPBX team was one of the first in the open source PBX community to adopt it, learn it, and then we immediately started training people to use it. If you know how to do this newer replication, it's likely you learned directly or indirectly from the FusionPBX project.
This new replication is better than the original BDR in multiple ways. In BDR it would do a snapshot of the entire database and then copy it over to the new node. If the database were large, it could take a while before you saw any data on the new node. The newer native PostgreSQL logical multi-master replication replicates each table separately, and the replication begins immediately.
At first, with this new replication, it took time to realize how to fix all the problems clients were experiencing. However, we have done our time and gained the necessary experience to fix all the issues that our clients have faced up to this point. With the help of our client base, we have accelerated experience-based on real-world demand.
Why Choose a 3-Node Database Cluster?
While a 2-node cluster provides redundancy and failover capabilities, adding a node offers several significant advantages:
1. Fault Tolerance: In a 2-node setup, if one server fails or becomes unavailable, 1 server is left without any remaining redundancy. In a 3-node setup, even if one node fails, the other two nodes can continue to operate without interruption. This ensures that your system remains fully functional, minimizing downtime. Why have a 2-node cluster when you can have the additional peace of mind of a 3-node cluster?
2. Geographical Distribution: A 3-node cluster allows for more flexible geographical distribution of your database servers. You can place nodes in different locations to improve geographic redundancy, enhancing disaster recovery capabilities.
3. Larger Workload A 3-node or larger cluster can handle a larger workload.
The FusionPBX team set up a 3-node cluster for someone last week. It's not our first time, we have done it many times.
Additional 3rd party references as to why you consider more redundancy
- https://www.acronis.com/en/blog/posts/backup-rule/
- https://www.ipmcomputers.com/the-3-2-1-backup-rule-explained-and-why-its-still-relevant-in-2025/
- https://www.impossiblecloud.com/blog/the-golden-rules-of-backup-strategy-from-3-2-1-to-3-2-1-1-0
Even AWS has outages. Recent outage by Cloudflare a company considered by many to be one of the safest recently had a major outage. This further drove the point to those paying attention that more redundancy is a very good thing.
Last edited:
