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.
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.
There may be slightly more data retained after deletion in the primary cluster, for replication purposes.
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 leaves or reduced resources, it can still be useful as a "spare" sort of cluster in a DR scenario.
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.
Last modified: June 22, 2022