UNC01-INT - Real-World Database Availability Group (DAG) Design

Microsoft provides a great deal of content covering the theory around designing highly available and site resilient solutions, but there is very little discussion of how to apply that to “non-standard” customer scenarios. Not all customers have 50% of their users in one datacenter and 50% in a second datacenter, or one “hot datacenter” for all user access and one “warm datacenter” for site resilient scenarios. In this session, we apply the theory of DAG design and utilize the tools provided by Microsoft to design some real-world site resilient solutions. [TENA10]

Key points:
1. 250ms for acceptable latency for DAG
- This is important for log replication
- Stretch DAG isn’t meant to handle unreliable link
2. Where should we place fsw?
- If you want primary site to work in the event of outage, you want the FSW to be local
3. If for whatever reason the logs doesn’t play back on the passive nodes, you are better off deleting the copy
- you are better off reseeding it
4. when you take off nodes for 5 days, make sure count into storage for hosting that much logs
- unless, you cause some diversion the log, you shouldn’t have to reseed
- page patching, bad block – these are no longer an issue that requires a reseed
5. 2TB is recommended ceiling for .edb size in replicated environment
6. You can’t stretch DAG to cloud
7. In a odd # of dag you don’t have fsw
8. You can have mbx installed on with hub so you have extra voting members per data center – you don’t have to mount DB

**tomorrow’s dag session for SP1 – attend