Question |
Answer |
Further reading |
How many replicas (Database Replication) should each of my primary databases have? |
- One replica per each primary database
- Multiple replicas are not typically worth the additional administrative complexity or resource provisioning
|
KB Articles:
|
Do my primary and replica clusters have to be the same spec?
|
- Slow replicas will throttle the performance of your primary cluster.
- Therefore, your replica should be provisioned to avoid primary throttling - which typically means a similar hardware specification
|
KB Articles:
Documentation:
|
What do I do about a lagging primary?
|
You can either:
- Speed up the replica by reducing traffic to the replica, or adding hardware resources to the replica - or both
- Pause replication - be aware you'll no longer have a synchronized DR copy until replication is re-enabled
|
KB Articles:
Documentation:
|
In terms of disaster recovery (DR) - how do I choose between backup/recovery or replication? |
- Database Replication
- Best if you need a more synchronized copy of your data
- Needs a bigger hardware footprint
- Can result in primary throttling if under-provisioned or under heavy load
- Backup/Restore
- Best if you are not sufficiently provisioned for a more synchronized DR copy, as seen with database replication
- Results in a more unsynchronized snapshot copy of your data
|
KB Articles:
Documentation:
|
Can I do multi-primary replication i.e., have primary databases on both the clusters on a pair of coupled clusters?
|
- Database replication is intended for disaster recovery (DR) & redundancy
- For DR purposes, the recommended configuration is a dedicated primary cluster for all primary databases and a dedicated DR cluster for all replicas of those primary databases
- Because of administrative complexity and compromised DR functionality, multi-primary DR configurations are not recommended
|
Documentation:
|
Should I replicate the auxiliary databases? |
-
Always replicate your Security database when setting up Database replication
-
Separate security databases on both primary and replica clusters are not recommended due to administrative complexity
-
Avoid replicating the App-Services database
|
Documentation:
|
Can my primary and replica both write to the same shared storage?
|
Avoid writing both primary and replica to the same shared storage since it results in a single-point failure architecture, thereby defeating the purpose of DR
|
KB Articles:
|
How many bootstrap hosts should my cluster have?
|
Only mark the hosts that hold your security forests (and its local disk failover copy) as bootstrap hosts to avoid too many unnecessary connections between primary & replica clusters.
|
Documentation
|
How do I upgrade replicated environments? |
Replica First. If Security DB is replicated then Replica cluster must be upgraded before Master.
|
Documentation
|
How do I divert traffic away from my primary to replica cluster? |
- Disable database replication for the database on the replica cluster.
- Make the replica cluster/database as the master.
- Rolling Back to the Non-Blocking Timestamp on the new master
|
Documentation
|