Cluster Topology

Primary and secondary clusters can have different topology.

There can be different leaf counts in the two clusters, however there must be enough space allocated in both the clusters to store all the data. The purpose of the secondary cluster may also affect the recommended topology.

For example, if the secondary cluster is used as:

• a backup copy to import data from in case of failure, it can have less leaves with the same memory.

• a backup copy to promote to primary cluster in case of failure, it should be identical to the primary cluster

• a read-only cluster to run analytical queries, it should have more leaves so there are more CPU cores, with less memory per leaf

The partition count in the database will be the same, but you can have different counts of partitions per leaf (for example, if there are different counts of leaf nodes between the clusters).

You do not need to have High Availability (HA) enabled in the cluster holding the secondary database even if it is enabled in the cluster holding the primary database.

The amount of disk and memory used for storage in the secondary cluster is about the same as that in the primary cluster. Basically, the data is stored in the same format in the secondary cluster as in the primary cluster; it is not compressed further than in the primary cluster.

There may be slightly more data retained after deletion in the primary cluster, for replication purposes. Once the data change is replicated to the secondary cluster and no more executing queries rely on it, this data is removed from the primary cluster. This can mean that the primary cluster temporarily needs more storage.

The closer the secondary cluster is to the primary cluster in terms of, leaf count, HA enablement, disk and memory allocations, the better the secondary cluster will be able to handle the query workload during a DR scenario (where the primary cluster experiences catastrophic failure and the entire workload is shifted to the secondary cluster until the primary can be repaired). If the secondary cluster has fewer leaf nodes or fewer resources than the primary cluster, then it may have reduced performance or kill queries for not having enough memory, when the entire workload is shifted to it.

If the secondary cluster has fewer leaves or reduced resources, it can still be useful as a "spare" sort of cluster in a DR scenario. It is useful as a completely up-to-date backup of the primary cluster (as opposed to nightly backups which lack the most recent data). It can also be used to run large, expensive analytical queries and avoid running those on the primary cluster.

Some general points to consider for DR topology:

• Run multiple nodes in one machine if there is NUMA.

• Co-located aggregators and leaf nodes can be used to take advantage of locality.

• Aggregators can have smaller resources than leaf nodes.

• For HA do not run a leaf node on the same host as the master aggregator.