A family of Microsoft suites of integrated development tools for building applications for Windows, the web, mobile devices and many other platforms. Miscellaneous topics that do not fit into specific categories.
Azure DevOps Server (TFS) does not support keeping two independent server instances bi‑directionally synchronized so that users can alternately work on either “main” or “replica.”
Supported topologies for scale and high availability are:
- Multiple application tiers sharing a single data tier
- A single Azure DevOps deployment can be scaled out by adding more application‑tier servers that all point to the same SQL Server data tier.
- This is the supported way to handle thousands or tens of thousands of users and to provide redundancy at the application tier.
- In this model there is only one set of Azure DevOps databases (for example
TfsConfiguration,TfsDefaultCollection, and any additional collection databases), so no synchronization between separate instances is required.
- High availability using SQL Server Always On Availability Groups
- High availability is achieved at the SQL Server layer by placing the Azure DevOps databases in a SQL Server Always On Availability Group.
- The Azure DevOps databases that must be in the availability group include:
-
TfsConfiguration -
TfsDefaultCollection - Any additional project collection databases
-
- Application‑tier servers connect to the primary replica of the availability group. In case of failover, the AG promotes a secondary replica to primary, and the application tier is pointed to that primary.
- This provides a “replica” of the data, but it is managed by SQL Server, not by running two separate Azure DevOps Server instances that users switch between.
- Backup/restore for disaster recovery (not for alternating active use)
- Regular backups of all Azure DevOps databases (and, if used, Reporting Services and Analysis Services databases) are supported for disaster recovery.
- Backups must be synchronized (for example, using marked transactions) so that all databases can be restored to a consistent point in time.
- This mechanism is for recovery, not for keeping two active, writable Azure DevOps instances in sync for alternating monthly use.
Because of the tight coupling between the application tier, configuration database, collection databases, reporting/analysis components, and identity data, there is no supported method to:
- Run two separate Azure DevOps Server instances with separate data tiers, and
- Synchronize them nightly in both directions so that users can freely switch which instance they use.
To meet the requirement for a “main and replica,” use one of the supported patterns instead:
- Single Azure DevOps deployment with multiple application‑tier servers for scale.
- Single Azure DevOps deployment with its databases in a SQL Server Always On Availability Group for high availability and a replicated data tier.
Do not attempt to implement custom, bi‑directional synchronization between two independent Azure DevOps Server farms; this is unsupported and risks data corruption and inconsistency.
References: