Controlling bandwidth in a DAG reseed

Q: Is there a way to control bandwidth within a DAG (Database Availability Group) during a reseed process?

A: No.

However, that’s not the complete story. The question comes up when engineers need to reseed a database (DB). And while there is no native option to control bandwidth, there is a work around.

Scenario: One of the DAG nodes has failed, and you need to rebuild it. You install another Exchange Server as a new node and add it to the DAG and need to seed the DB’s. The problem arises if you have 500GB or larger DB's and don’t want to flood your network with unnecessary traffic. If you just add the DB’s to the server replica, it’ll flood the network until the DB’s are completely up to date.

Another situation comes up if you want to change the mount point paths of DB’s. This is not too uncommon if you didn’t initially follow the guidance of using mount points for DAG DB’s. Some customers use a drive letter for individual DB’s and then can run out of options if using too many DB’s. That’s another reason the Exchange team suggests using mount points. But now you have to move DB’s to a different path, how do you do that?

One approach is to remove all replicas, dismount the primary database, move its database path, remount it, and add replicas. Once again, the process of adding replicas floods the network with no control mechanisms. A better option would be to create a new database in the new path location, including replicas on other servers, and move users into the new database. You have no real down time in this approach, don’t risk losing any High Availability (HA) or Disaster Recovery (DR), and can control the speed/bandwidth that is used during the seeding process.

There you go, a genuine workaround to a situation that has limited built-in options.