Clustering Concepts

Most databases implement fixed clusters that intermingle scalability with availability. This limits what a database can do and where it can be used. The need to scale data is independent from the need to make data highly available. These separate needs are best implemented as separate technologies that are designed to be combined in flexible ways.

Instead of a one-size-fits-all cluster architecture, the FairCom Database Engine allows you to create clusters to meet your exact needs for scalability and availability. It provides three technologies for this purpose:

Replication Manager provides a browser-based graphical user interface that makes creating clusters a simple point-and-click experience. The Replication and Failover Engines are built into the FairCom Database Engine, which means they are automatically installed and ready to replicate data to any FairCom server as well as detect failures and automatically fail over to designated servers.

The following features are key to creating a cluster that meets your needs for scalability and availability:

Synchronous Unidirectional Replication is needed for ACID-compliant mission-critical environments. It ensures data is replicated before returning a commit to the application. This eliminates data loss and out-of-sync data. All data is always consistent at a point in time.

Asynchronous Bidirectional Replication with Conflict Resolution is needed for eventually consistent mission-critical environments that allow the application to write anywhere for maximum local performance and local availability. The data is eventually (but quickly) replicated across the cluster. Conflicts are automatically detected, and the application is notified so it can appropriately resolve them.

Asynchronous Parallel Replication is needed for horizontal scalability within and across data centers. You can use it to create read-only servers that have point-in-time consistency or you can create eventually consistent read-write servers.

Selective Asynchronous Replication is needed for sharding data across servers. FairCom’s NAV APIs make it easy to remote control many databases at the same time. Your application can use any sharding algorithm to write and read data across shards. Selective replication can automatically use the same algorithm to ensure that data is replicated properly to the desired shards.

Parallel Replication uses multiple threads to replicate data in parallel while ensuring transaction order. This makes replication much faster than serial replication. It often executes replicated transactions on the target server faster than on the source server. You control the level of parallelism to match the capabilities of your CPU. You can add parallel processing to synchronous and asynchronous replication. In both cases, replication honors the order of dependent transactions to ensure full ACID compliance.

Serial Replication is desirable when increased performance is unnecessary, when CPU is needed elsewhere, or when ensuring transaction order in parallel replication is slower than simply using serial replication.

In the diagram above, Serial Replication starts falling behind at 4 concurrent connections. Parallel Replication keeps up with the source until it reaches the maximum threads assigned to replication. In the illustration above, replication was assigned 8 threads; thus, replication performance starts falling behind when 16 processes are updating data concurrently.

OS Clusters, Failure Notification, and Synchronous Replication - High Availability (HA) is the ability to remain available with minimum interruption to service during a system outage. You now combine synchronous replication, failure notification, and OS clusters to implement high availability without licensing and installing a complex clustered file system. Because the storage is not shared, the cluster has higher availability. This solution is supported on RedHat Enterprise 8 and Windows Server. It is a highly available, ACID-compliant cluster with automatic failover and no possibility of a split-brain scenario. This is an active-passive solution where the secondary servers are not available to process transactions until failover occurs.

Failover (BETA) with Synchronous Replication - Using Pacemaker or Windows HighAvailability Cluster, FairCom can detect server failures and automatically fail over to designated servers. Database servers replicate from a primary read-write server to one or more read-only servers. If the primary server fails, it automatically fails over to one of the read-only servers. It creates a highly available, ACID-compliant cluster with automatic failover that is partially active-active because read-only servers are available for read-intensive operations across servers, such as batch reporting, analytics, and machine learning. The cluster automatically and transparently directs write operations to the primary server and directs read operations to the read-only servers. The cluster detects failures and automatically fails over to an available server -- completely transparent to the application.

Failover (BETA) with Asynchronous Replication – This works the same as the previous scenario except that asynchronous replication allows the primary server to replicate data to many servers – including servers in the cloud and remote data centers. It has the downside that network latency introduces a slight risk of losing some data during a failover event. The cluster detects failures and automatically fails over to an available server -- completely transparent to the application.

The flexibility of this architecture makes it easy to: