Sunday, 17 May 2015

A design consideration: SQL Server AlwaysOn Availability Mode for TFS

There are a few bits of any Team Foundation Server deployment which are either taken for granted, or completely ignored. One of them is:

Why shall I choose a Synchronous-Commit Availability Mode for the TFS Data Tier using SQL Server AlwaysOn?

If you are running an AlwaysOn Availability Group, you should know that you have a choice on how to write your Transaction Log – hence your database integrity. My suggestion is to run Team Foundation Server’s data tier in a Synchronous-Commit Availability Mode.

The reason is very simple: TFS relies heavily on the Transaction Log, and it is the only way to guarantee a point-in-time recovery. Moreover, if you run AlwaysOn you cannot have any database in the Availability Group set without the Full recovery mode.

So you must use the Transaction Log, and it is critical for the Team Foundation Server recovery – using the Synchronous-Commit mode ensures that each Secondary Replica in your Availability Group has an updated copy of the Transaction Log, synchronised at the same time as the Primary Replica, for immediate failover and service continuity.

You will face a really minor increase in the RTO (a few seconds, generally) and a performance loss, but we are talking about something you won’t be able to realise in general usage, and you are ensuring your service has an excellent reliability.

1 comment:

  1. Totally agree. That's exactly the configuration we use on our main TFS instances.

    ReplyDelete