Tungsten Clustering - Key Topologies

Geo-Distributed, Multi-Site Tungsten Clustering Solutions

Geo-Distributed, Multi-Site Tungsten Clustering is simply a “cluster of clusters”, using the basic standalone cluster and extending the managed mesh to additional sites or regions. You may span across Cloud providers (multi-cloud), and can even integrate on-premises hardware with Cloud-based instances (hybrid-cloud).

MySQL Primary/DR Geo-Cluster

A “Cluster of Clusters” where one cluster contains the single active, writable primary. All other clusters and nodes are passive and read-only. Typically two or more clusters.

Primary Cluster: one (1) primary + two (2) failover/read replicas
DR Cluster: one (1) relay + two (2) failover/read replicas

In the Tungsten Composite Active/Passive Cluster topology (Active/Passive), there is a single writeable primary node across all sites, and all writes are directed to that primary. The Connectors are multi-site aware and will automatically react to a site failover. Replication flows in one direction only, from the current active primary cluster to the passive DR cluster(s).

This topology provides a highly-available local operations and an active failover site that is also available for reads. It is well-suited for customers who seek the highest level of HA, with the ability to operate applications on both sites, without application changes.

The Active/Passive Tungsten Clustering solution is for SaaS providers, e-commerce companies, financial services providers, gaming companies and telco providers who are seeking five-9s availability for their business-critical and mission-critical MySQL applications.

MySQL Active/Active Geo-Cluster

A “cluster of clusters” where all clusters contain a writable primary. Typically two or more clusters.

Primary Cluster: one (1) primary + two (2) failover/read replicas
Primary Cluster: one (1) primary + two (2) failover/read replicas

In the Tungsten Active/Active Cluster topology (Active/Active), there is one writeable primary node per cluster, and all writes are directed to that primary by the local Connectors. The Connectors are able to use any other site in the event of a local outage; both sites are write-able at all times, and each cluster replicates from all other member clusters.

This topology links highly-available clusters across sites to enable constant availability for updates in two locations separated by high-latency networks.

The Active/Active Tungsten Clustering solution is perfect for those business-critical and mission-critical MySQL applications that require lower latency for local updates while still needing to maintain completely geo-distributed data sets for Disaster Recovery needs. It is recommended for SaaS applications, credit card payment gateways, or online services that must always be available for business.

Single Site Tungsten Clustering Solutions

Standalone MySQL HA Cluster

Tungsten Clustering with one (1) primary + two (2) failover/read replicas

The Tungsten Clustering HA configuration is designed for sites that strive to ensure constant availability. The standalone cluster is the basic building block that provides easy high availability to your applications without requiring any changes. This topology ensures the ability to perform maintenance on any database server and still maintain an environment capable of HA failover at all times.

Tungsten Clustering is an ideal solution for SaaS providers with Pod Architecture. It provides an excellent HA solution with infinite scalability. Just by adding more clusters, SaaS providers can serve more customers.

MySQL HA Cluster with Read Scaling

Tungsten Clustering with one (1) primary + four (4) or more failover/read replicas

Tungsten Clustering HA with Read Scaling is ideal for sites that require HA and read-scaling for enhanced performance under peak loads. Tungsten Clustering enables the use of the replica nodes to support additional read traffic without impacting cluster performance. Media and consumer web sites should consider this option.

Tungsten Clustering with extra read replicas is for the business-critical MySQL applications with high read/write ratio.

Additional Information

The best practice is to have three (3) MySQL database nodes minimum per cluster.

Tungsten Clustering requires an odd number of MySQL database nodes to establish a voting quorum. A proper voting quorum is essential for proper cluster operation in the event of a network partition. In order to be able to avoid the existence of two active primaries in the same cluster (otherwise known as a split-brain scenario), there must be a majority of the voting nodes in one of the network partitions.

Once a majority is established, a new primary is selected from that majority group. In network partitions with a minority, any primary is shunned to prevent a split-brain.

Tungsten Clustering supports an “Active Witness” node, which is not a database node, but does run the Tungsten Manager, and is an active, voting member of the cluster. This allows for hardware savings as compared to a full database node. The cost for a Witness node is the same as for a full database node.

Interested in Tungsten Clustering? Get in Touch!

Please use the button below to contact us, you will receive a reply within 24 hours.