Skip to main content
Database Administrators

Return to Question

Bumped by Community user
Bumped by Community user
Bumped by Community user
Bumped by Community user
Bumped by Community user
added 33 characters in body
Source Link
Brendan McCaffrey
Brendan McCaffrey
  • 3.4k
  • 2
  • 7
  • 29

Our asynchasynchronous secondary nodesreplicas will have some extended downtime over the next few weeks...3 3-4 hours one night then 2-3 days a few weeks later. I know the primary replica logs will keep growing while the secondariessecondary replicas are down, and. I'll keep an eye on the Log drives to add disk space if they get close to filling up. 

Should I suspend data movement on each secondary dbdatabase before powering down the secondary vmsVMs, or will the vm being offline serve the same purpose? Any differences in the way the primary will function if the secondary is suspended vs. powered down without suspending? The

The AGs/clusters should stay online due to the primary + file share witness providing quorum, correct? 

Also, our apps connect to the primary's dnsDNS name (or an alias), not via the AG/cluster name. When the secondaries come back online, they should start catching up, right? Thanks!

Our asynch secondary nodes will have some extended downtime over the next few weeks...3-4 hours one night then 2-3 days a few weeks later. I know the primary logs will keep growing while the secondaries are down, and I'll keep an eye on the Log drives to add disk space if they get close to filling up. Should I suspend data movement on each secondary db before powering down the secondary vms, or will the vm being offline serve the same purpose? Any differences in the way the primary will function if the secondary is suspended vs. powered down without suspending? The AGs/clusters should stay online due to the primary + file share witness providing quorum, correct? Also, our apps connect to the primary's dns name (or an alias), not via the AG/cluster name. When the secondaries come back online, they should start catching up, right? Thanks!

Our asynchronous secondary replicas will have some extended downtime over the next few weeks. 3-4 hours one night then 2-3 days a few weeks later. I know the primary replica logs will keep growing while the secondary replicas are down. I'll keep an eye on the Log drives to add disk space if they get close to filling up. 

Should I suspend data movement on each secondary database before powering down the secondary VMs, or will the vm being offline serve the same purpose? Any differences in the way the primary will function if the secondary is suspended vs. powered down without suspending?

The AGs/clusters should stay online due to the primary + file share witness providing quorum, correct? 

Also, our apps connect to the primary's DNS name (or an alias), not via the AG/cluster name. When the secondaries come back online, they should start catching up, right? Thanks!

Source Link
Bobogator
Bobogator
  • 83
  • 1
  • 5

SQL Server availability group asynchronous secondary extended downtime...suspend necessary?

Our asynch secondary nodes will have some extended downtime over the next few weeks...3-4 hours one night then 2-3 days a few weeks later. I know the primary logs will keep growing while the secondaries are down, and I'll keep an eye on the Log drives to add disk space if they get close to filling up. Should I suspend data movement on each secondary db before powering down the secondary vms, or will the vm being offline serve the same purpose? Any differences in the way the primary will function if the secondary is suspended vs. powered down without suspending? The AGs/clusters should stay online due to the primary + file share witness providing quorum, correct? Also, our apps connect to the primary's dns name (or an alias), not via the AG/cluster name. When the secondaries come back online, they should start catching up, right? Thanks!