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!

1 Answer 1


If you're going to take the asynchronous replicase offline for a few hours, it should be acceptable to suspend data movement first, perform the maintenance you need to do, and resume data movement when the secondary replicas are back online. I'd continue to monitor transaction log growth on the primary replica during that time. Though that's a fairly short time period to fill up a transaction log.

When you start talking about multiple days, I'd plan to remove the secondary nodes from the availability group entirely during that time. That is, unless you plan on monitoring the transaction log 24x7. Otherwise, there's too much that could go wrong. In theory, you could predict the log growth over 3-4 days. But who's to say there's not a random job that runs once a month, or once a week, that's going to run right in the middle of your 3-4 maintenance window, and it hits the log hard at 3am, when no one's watching. Just don't take the chance. It's too easy to add the nodes back to the availably group later.

As for quorum, we can't answer that without knowing your quorum configuration. How many production replicas do you have compared to DR? Where is the file share is located. Assuming DR has no voting rights, you should be fine.

  • Thanks for the reply. I'll check the usual hourly and daily log growth to get an idea if we should worry about disk space. I'd prefer not to remove the secondary nodes, and we'll have time and bandwidth for any high activity secondaries to catch up once they're back online. Is suspending data movement absolutely necessary, or can the secondaries just be powered down? If they're suspended, when they come back online, do they automatically resume? Thanks!
    – Bobogator
    Apr 19, 2022 at 15:12
  • @Bobogator You could suspend data movement, and it would catch back up when you resume data movement later. I have seen times where a resume fails. So be prepared for that. I’ve never suspend data movement for a prolonged period of time. There is no telling how long it might take for replicas to catch back up. With asysnc, they’ll show as synchronizing the moment you resume, but it’s not immediately clear if they’re 5 minutes behind or 5 days behind. How large are the databases in question? Apr 20, 2022 at 23:16

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.